Есть несколько вопросов (вернее опросов) про dsl д...

# russian

[snrostov]

Есть несколько вопросов (вернее опросов) про dsl для ui (react, anko, tornadofx и т.д.).
Задаю их т.к. прямо сейчас нужно начинать большой проект с кучей ui кода, и при использовании подхода dsl в указанных выше либах есть сложности.
Есть штука с альтернативным подходом, но хочется понять насколько он лучше (и есть ли аналогичные проблемы у дргуих).

1. Всех ли устраивает добавление элементов в родительский компонент через неявный вызов функций-билдеров?

вариант 1:

verticalLayout {
        view {

как мне кажется было бы удобнее если бы эти методы назывались addVerticalLayout, или что то вроде:

вариант 2:

+VerticalLayout {
        +View {

В варинате 2, имхо, проще читать код, т.к. функции билдеров визуально сложно отличить от простых функций с лямбдой (forEach, map и да и if в конце концов).
В простом коде это не заментно, но когда начинается смесь из билдеров и функций лямбд, очень лего запутаться.

Кроме того добавление текста в kotlinx.html уже выглядит также как тут +"text"

[beholder]

Насколько понимаю, для варианта 1 можно просто сделать extenstion функции готовых компонентов. А для unaryPlus надо делать отдельный класс, куда этот оператор помещать, и этот класс в общем ничем другим кроме сборки заниматься не будет.

[beholder]

В TornadoFX unaryPlus для компонентов не используется совсем, там только если plusAssign

[snrostov]

Если у компонента есть список children, то унарный оператор + может добавлять в него. Его также можно объявить как экстеншн функцию

[beholder]

А в Swing и то и другое часто бесполезно, потому что как правило к вызову add() надо добавлять вторым аргументом constraints для компонента

[snrostov]

Если компоненты иммутабельные, то можно передавать прямо лямбду. Или билдер списка, да

[snrostov]

Насколько понимаю, для варианта 1 можно просто сделать extenstion функции готовых компонентов.

это да, но это придется делать для всех компонетов, в том числе для проектных. Я вот начал так писать, и очень быстро надоело объявлять и класс компонента и функцию которая добавляет его в родительский компонента

[snrostov]

А для реакта - вобще жесть имхо

[snrostov]

class HomeView : ReactDOMComponent<HomeView.Props, HomeView.State>() {
    companion object : ReactComponentSpec<HomeView, Props, State>

[beholder]

По этому кусочку кода ничего не понятно

[beholder]

Я, правда, react не знаю

[snrostov]

Для реакта JB сделали обертку в которой компоненты объаявляются вот таким вот образом

[snrostov]

это нужно написать для каждого нового компонента

[snrostov]

companion object, по сути, выполняет роль функции которая добавляет компонент в родительский компонент

[snrostov]

т.е. можно где то написать

div {
  HomeView {
   // ...
  }
}

[beholder]

В Swing/JavaFX можно определять plusAssign только для верхнего компонента в иерархии виджетов

[snrostov]

тут по сути про это и речь, я как раз за +. Но люди голосуют за функции билдеры

[beholder]

Мне бы не понравилось создавать класс который занимается только билдерством, а потом тут же выбрасывается

[snrostov]

если компонент не иммутабелен (есть mutable children), то билдер не нужен

[snrostov]

а если иммутабелен - то без него в любом случае никак...

[snrostov]

operator fun Component.unaryPlus() { this.children += this@unaryPlus }

[beholder]

В react иммутабельны?

[snrostov]

да. список передается в React.createElement, последними параметрами

[snrostov]

ну вернее не совсем так. сами компоненты mutable

[snrostov]

а props компонентов - immutable

[snrostov]

props (параметры компонента), вместе со списком дочерних элементов передаются в React.createElement, реакт копирует их и сохраняет. Далее вызывается рендер, и если элементы отличаются от того что сейчас в дереве, рендер идет внутрь переданных элементов, и т.д.

[beholder]

Мне кажется, универсальный DSL для "вообще любого" фреймворка не получится

[beholder]

Где-то удобнее одно, где-то другое

[beholder]

Если ориентируетесь на React, то затачиваете на него

[snrostov]

Да, про универсальность вопрос отдельный, нужно было разделить вопросы. Конкретно про реакт, с подходом JB жить сложновато, поэтому и родился вот этот альтернативный подход, про который собственно и опрос.

[beholder]

И потом задачи могут быть разные - написать DSL на уже готовый набор компонентов или же начать с нуля