Flutter: Считайте JSX-подобным React Native

Давно спрашивали:
https://github.com/flutter/flutter/issues/11609
Разработан функциональный прототип:
https://spark-heroku-dsx.herokuapp.com/index.html
Это показывает альтернативу и некоторые преимущества...

Текущая проблема с DSX связана с правильной интеграцией с инструментами Flutter, чтобы предоставить разработчику отличный опыт работы с отладчиком, автозаполнением и т. д., работающими с файлами .dsx.

Говорить пользователям, что они могут использовать DSX, но не могут использовать отладчик или пользоваться автозаполнением, для меня это не начало. Если кто-то хочет помочь, мне нужно найти способ добавить полную поддержку предварительной обработки (с исходной картой) в Dart Tools и подключаемый модуль VS Code Dart. Как только инструменты поддерживают этот DSX или любой другой язык транспиляции (любой язык, который является расширенным набором Dart, но компилирует все в Dart) просто сработает.

Если вы можете и хотите помочь, дайте мне знать.

Я не могу согласиться. В частности, используя IDE, такую ​​как Dart Code, вы получаете виртуальные закрывающие теги, которые значительно облегчают чтение. С Dart2, где вы можете опустить new , все станет еще лучше.

Также я считаю, что вам не рекомендуется строить слишком большие деревья виджетов, не разбивая их на более мелкие, более простые в обслуживании классы виджетов.

Я использую Android Studio. Я даже не вижу виртуального закрывающего тега. Несмотря на то, что у нас есть виртуальный закрывающий тег, он сложнее, чем HTML, который все ненавидят. Дарт — это просто язык программирования. Люди в Google не понимают важности упрощения.

Я не думаю, что хотел бы синтаксис, подобный JSX, но да, я использую IntelliJ, и нужно что-то сделать с инструментами, чтобы код пользовательского интерфейса было легче понять.

Также я считаю, что вам не рекомендуется строить слишком большие деревья виджетов, не разбивая их на более мелкие, более простые в обслуживании классы виджетов.

Я не вижу, чем это отличается от JSX ... по мере того, как дерево становится больше, вы можете разбить его на более мелкие поддеревья с обоими.

Я не думаю, что хотел бы синтаксис, подобный JSX, но да, я использую IntelliJ, и нужно что-то сделать с инструментами, чтобы код пользовательского интерфейса было легче понять.

и он должен легко читаться на всех платформах, а не только на Intellij; Я имею в виду, что это должно быть легко читать на Bitbucket при просмотре кода; и это также должно быть действительным при использовании любого редактора; Я имею в виду, что с этими «аннотациями комментариев» что произойдет, если кто-то, использующий «vi», наберет там другой комментарий?

Это дубликат закрытого #11609.
@сетладд ?

Извините, вы должны увидеть «виртуальные закрывающие теги» в IntelliJ и Android Studio.

cc @devoncarew , чтобы проверить, какая версия включила это, или если пользователю нужно подписаться?

Мы благодарим вас за ваши комментарии относительно синтаксиса, подобного JSX. Мы считаем, что язык, наши инструменты и плагины могут упростить редактирование кода пользовательского интерфейса.

Это дублирует # 11609, но я бы хотел, чтобы @devoncarew или @mit-mit добавили примечание о том, как включить «виртуальные закрывающие теги», если это возможно.

Спасибо!

@JonathanSum , к сожалению, закрывающие метки недоступны в Android Studio 3.0. Вам понадобится как минимум IntelliJ 2017.3 или Android Studio 3.1. Android Studio 3.1 в настоящее время находится на стадии релиз-кандидата, и завтра мы планируем выпустить плагин флаттера с его поддержкой.

Независимо от обсуждения синтаксиса, подобного JSX, мы хотим работать над тем, чтобы упростить написание кода пользовательского интерфейса в Dart, как в IntelliJ/Android Studio, так и в VS Code. Первоначально это работа с заключительной меткой, но также и недавнее представление Flutter Outline. Это показывает структуру вашего метода build() в представлении структуры и позволяет вам перемещаться по виджетам и более легко видеть их родительские/дочерние отношения. В настоящее время это доступно в IntelliJ — мы ожидаем, что сможем перенести его и в VS Code.

@zoechi - это может быть обман; но другая нить нагрелась и заблокировалась. Таким образом, они не могут внести свой вклад в этот разговор. Я не думаю, что вам следует закрывать эту ветку как дублирующую только потому, что вам не нравятся люди, просящие какую-то функцию. Вероятно, это должен быть новый поток ответов для новых людей, которые приходят и запрашивают поддержку JSX (или аналогичную функциональность).

@sethladd - Пожалуйста, не блокируйте эту тему; Я действительно думаю, что полезно, чтобы сообщество обсуждало плюсы и минусы альтернативных методов компоновки. Я бы участвовал в #11609, если бы он не был заблокирован.

Я родом из фона NativeScript. Я должен сказать, что это одна из областей, где мне кажется, что NativeScript значительно проще в использовании, чем Flutter. Я могу заставить довольно сложные экраны работать менее чем за 5 минут и легко и быстро повторять дизайн. Затем добавьте код, который запускает экран.

В NativeScript у нас фактически есть следующие файлы:

• screen.js / screen.ts (.ts транспилируется в .js, если вы предпочитаете машинописный текст). Это основная логика экрана, который вы показываете.
• screen.css (или screen.android.css и/или screen.ios.css ), который является гораздо более ограниченной версией CSS, но поддерживает такие вещи, как высота, ширина, цвет, фон и т. д. В большинстве случаев нужен только один файл css, но иногда, если вы делаете что-то странное, вы можете разделить свой css для Android и ios. Он имеет полную поддержку классов, элементов и идентификаторов, поэтому я могу сделать TextArea.Login #Password , и на самом деле он ограничится только этой конкретной цепочкой элементов.
• screen.xml (снова или screen.android.xml и/или screen.ios.xml ) — это макет экрана. Вы МОЖЕТЕ кодировать макет в JS, если хотите (в основном, как флаттер); но XML намного проще. Пример:

<Page onLoad="loadme">
    <ActionBar title="Blah"><NavigationButton click="back" title="Back"/></ActionBar>
    <StackLayout>
      <Label text="Hi" id="Hi" style="color: red"/>
     <Label text="{{name}}" class="name"></Label>
     <Button text="Click Me" tap="clicker"/>
    </StackLayout></Page>

Интересно то, что ActionBar является компонентом только для конкретной страницы (т.е. он специфичен только для страницы); так что в основном то, что происходит, - это страница синтаксического анализатора XML See; создает новый элемент страницы; затем создает компонент ActionBar, который затем запускает функцию builderChild в компоненте Page; компонент страницы переопределяет builderChild по умолчанию и проверяет, является ли дочерний элемент ActionBar; если это; затем он внутренне присваивает его соответствующей переменной; в противном случае остальное передается через parent/super, который затем автоматически назначает его «дочерним» или «дочерним» компонентам. Система сборки невероятно универсальна в том смысле, что каждый компонент может использовать либо родительскую функцию builderchild, либо переопределять ее, чтобы делать дополнительные элементы, такие как поддержка <Label>Hi</Label> , и автоматически назначать это значение Text. Это делает макет невероятно простым в использовании без какого-либо кода.

Поскольку большинство редакторов имеют хорошие возможности редактирования XML, он автоматически раскрашивается, а при правильном определении xsd intellij (& vscode) выполняет автоматическую проверку и ограниченную поддержку контекста.

Теперь технически все на самом деле является компонентом JavaScript; так что вы можете сделать все это вручную (например, что делает Flutter); но я считаю, что в NativeScript простота размещения экрана тривиальна. И вам не нужны JS или CSS при первом запуске; затем вы можете добавить CSS (обычно вы не жестко кодируете в макете свойства на основе css, но вы можете, если хотите).

Хорошая вещь об этом; Это позволяет веб-разработчикам сразу приступить к работе с очень небольшим (если вообще требуется) переобучением. Фактически; из-за его гибкого рендерера и того, что он основан на JS — NativeScript фактически поддерживает Angular и Vue — так что вы можете фактически разделить почти 95% базы кода между веб-сайтом и вашим мобильным приложением, если вы используете Angular или Vue. Поскольку он использует собственные компоненты ОС, такие как React Native (а не веб-просмотр, как Cordova); это действительно достойная кроссплатформенная система (имхо лучше, чем React Native). Тем не менее, я вижу некоторые сильные стороны Flutter, которые делают его хорошим дополнительным инструментом для мобильной разработки, поскольку в некоторых приложениях NativeScript хуже, а в некоторых он все еще намного лучше, и основываясь на ответах на мой вопросы от Яна; останется значительно лучшим инструментом в этих областях.

Лучше открыть эту заблокированную ветку и скопировать туда эти комментарии, чтобы у нас была история полных обсуждений.

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

@cbazza - я не согласен; но вы должны быть очень осторожны в будущем, чтобы не намекать на что-то о людях. Это только разжигает дискуссию, независимо от того, насколько идиотскими вы их считаете.

@zoechi - На самом деле я считаю, что любое обсуждение новой функции должно быть здесь. История должна вестись так, чтобы, когда Джон Доу придет через месяц и будет искать функцию XYZ, он сможет :+1: существующую функцию и/или внести свой вклад в нее.

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

Тема заблокирована, потому что команда Flutter не заинтересована в этом и просто хочет, чтобы люди перестали об этом говорить.

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

На самом деле, если NativeScript так хорош, зачем вообще возиться с Flutter вместо того, чтобы пытаться сделать Flutter NativeScript похожим.
Я исхожу из платформы на основе XML (Xamarin Forms) и вначале думал, что это может быть сложнее спроектировать в коде, но это не так.
Наоборот, очень легко разбить ваш дизайн на отдельные классы, которые легко поддерживать.

JSX проектирует в коде!!!

@сетладд

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

Хорошо, давайте поговорим о моем дизайне DSX, который можно посмотреть здесь:
https://spark-heroku-dsx.herokuapp.com/index.html

Он обеспечивает прямое сопоставление с текущим способом создания виджетов и в то же время предоставляет JSX-подобный вариант, очень легкий и знакомый разработчикам React. Чего-то не хватает в этом дизайне? Может ли этот дизайн генерировать все возможные виджеты в дикой природе?

Эмпирическое правило: если вы чувствуете, что одного восклицательного знака недостаточно, вам, вероятно, следует отойти от клавиатуры и сделать перерыв.

Я новичок во Flutter, имею лишь некоторый опыт работы с Android и Java, и я должен сказать, что нахожу то, что предлагает Flutter, намного лучше, чем то, что предлагается здесь. Я склонен считать XML уродливым и громоздким. Гораздо красивее иметь единственного заключительного персонажа, а не мореэто делает мой код в 5 раз длиннее, моя ненависть при редактировании Android XML и просто виртуальные закрывающие теги, которые поддерживают подавляющее большинство IDE, которые используют люди. Это невероятно полезно при проектировании более длинных конструкций. Аккуратная вложенность XML, на мой взгляд, не перевешивает остальные недостатки, особенно когда 'child:/children:' делает почти такую ​​же хорошую работу. Dart невероятно чистый, и именно поэтому он мне так нравится. Я был бы невероятно разочарован, если бы это было разрушено.

Я знаю, что React делает это так, но в прошлый раз, когда я проверял, в этом месте написано Flutter. То, что React делает это, не означает, что мы должны это делать — вы не единственные, кто прыгает сюда! Я полностью согласен со всеми замечаниями @escamoteur . Я не вижу смысла добавлять еще один язык, с которым люди должны работать при использовании Flutter. Мы уже используем Dart для программирования большей части этого, нам не нужно осваивать множество других вещей! Следует ценить последовательность и простоту.

Некоторые замечания из ваших DSX и сгенерированных фрагментов Dart:

1. Субъективно: я не вижу большого прироста читабельности. Многословие аналогично, если не чуть дольше. Плагин Dart IDE предоставляет автоматически закрывающие теги, которые отражают закрывающие теги декларативной разметки. Если JSX — это дизайн в коде, то я не понимаю, как виджеты в Dart — нет.

2. Несколько свойств в <vars>

@<vars>
var textStyle = {
    "textDirection": "TextDirection.ltr",
    "textAlign": "TextAlign.center",
    "overflow": "TextOverflow.ellipsis",
    "style": "new TextStyle(fontWeight: FontWeight.bold)"
};
</vars>@

Возможность определять глобальные стили, смешивая несколько свойств, — хорошая идея.
Однако, когда я оглядываюсь назад на свой скромный опыт флаттера, я не вижу, где бы я мог их использовать.

Для Text кажется, что большая часть того, что мне нужно для повторного использования, определена в TextStyle , а не в сочетании нескольких свойств. Возможно, вы найдете другой пример, кроме Text , где это не так.

Глядя на TextStyle , я считаю, что текущий immutable + copy() отлично подходит для повторного использования и создания в Dart:

class Style {
  static const TextStyle avenirNextMedium =
      const TextStyle(
         fontFamily: 'Avenir Next', 
         fontWeight: FontWeight.w500,
      );

  static TextStyle title =
      avenirNextMedium.copyWith(
        color: ColorKit.blue, 
        fontSize: 45.0,
      );
}

new Text(
  'Hello',
  style: Style.title,
),

new Text(
  'Hello2',
  style: Style.title.copyWith(
    color: ColorKit.red,
  ),
),

Я думаю, что для многоразового использования Container с одинаковым стилем создание пользовательского виджета без сохранения состояния работает лучше, чем внешний определенный <vars> . В большинстве случаев мне также нужны отступы, чернила, прослушиватель жестов или тень.

В любом из этих случаев мне нужно было бы составить Container с другим виджетом: Material , Padding , Center и т. д. Поэтому, если мне нужно создать В любом случае, настраиваемый многоразовый «контейнерный» виджет, я не вижу большой выгоды от внешнего стиля <vars> , который бы просто определял свойства одного виджета в моей иерархии многоразовых виджетов.

Я не вижу, чтобы Flutter «все является виджетом» хорошо работал со стилями «несколько свойств».

1. Не выделено в ваших текущих примерах DSX: как бы вы написали интерфейс с динамическими виджетами? Значение: как показывать или не показывать некоторые виджеты в зависимости от условия.

При разработке дизайна в Dart легко и удобно добавлять или не добавлять конкретный виджет в children .
Также очень удобно динамически оборачивать виджет другим. Это делает функцию build() беглой и легкой для понимания.

    var children = <Widget>[];
    if(a) {
      children.add(wa);
    }

    var wb = Text();
    if(b) {
      wb = Padding(child: wb);
    }

    children.add(wb);

@SirComputer1 предложение DSX является дополнением, текущий способ не меняется, поэтому, если вам это не нравится, не используйте его, продолжайте, как сегодня.

Вещь <var> была сделана только для демонстрации, потому что я не хотел анализировать полный Dart. Окончательное решение не будет включать <var> , но будет использовать любую переменную дротика. Кроме того, «@» был сделан только для демонстрации, чтобы упростить синтаксический анализ. Окончательное решение не будет включать его.

Не забывайте, что все остальное в файле — это ваш обычный код Dart, так что вы можете использовать его для всего остального.

    var children = <Widget>[];
    if(a) {
      children.add(wa);
    }

    // You can mix and match both
    var wb = <Text/>;
    if(b) {
      wb = Padding(child: wb);
    }

    // or
    var wb = Text();
    if(b) {
      wb = <Padding> {wb} </Padding>;
    }

    children.add(wb);

    children.add(
      <Center>
          {sayHello == true ?
             <Text ['Hello, world!']/>
          :
             <Text ['Good bye']/>
          }
      </Center>
    );

Давайте перестанем сравнивать DSX с нынешним образом, одно с другим не конкурирует. Некоторые люди предпочтут JSX, и эта тема для них. Я хочу знать, как я могу улучшить DSX, чтобы справляться с вещами, для которых он не работает.

@escamoteur - я не использую молоток в качестве отвертки. Я оцениваю различные технологии и использую подходящую для надлежащего варианта использования. Это не значит, что их нельзя изменить к лучшему на каждой из платформ. :ухмыляясь:

Например; интеграция сторонних плагинов. NativeScript действительно превосходит любую другую кросс-платформу. Ничто другое даже отдаленно не приближается к NativeScript; и сторонняя интеграция. У меня есть клиент, который спрашивает об использовании https://github.com/vipulasri/Timeline-View . Флаттер практически невозможен; NativeScript дает мне пару часов, и он будет работать так же, как и любой другой элемент управления NS, возможно, даже с полностью работающей привязкой данных. С другой стороны, у флаттера есть серьезные преимущества перед флагами NS...

Используйте подходящий инструмент для работы. :ухмыляясь:

Мне нравится макет экрана на основе XML; но я понимаю, почему люди этого не делают. Добавление возможности построения на основе XML НЕ означает отказ от существующего метода; это просто дополнение ; выбор. Для тех из вас, кто не удосужился прочитать, я могу сделать ту же цепочку вызовов в NS, что и во флаттере; но использование xml намного меньше печатает и мне легче читать. У каждого свои предпочтения...

На самом деле я думал о добавлении средства визуализации на основе XML во Flutter в качестве POC; но у меня не было свободного времени. Я просто хотел внести свой вклад в разговор и сказать, что хотел бы, чтобы это продвинулось вперед; но на самом деле я не ожидаю, что основная команда будет работать над этим. Я думаю, что формат NS XML можно было бы использовать в качестве проектов сообщества, где те из нас, кому это небезразлично (то есть, возможно, я :ухмыляясь:), были бы готовы поработать над ними. Тем не менее, меня больше всего беспокоит @sethladd , если я потрачу много времени на патч; будет ли она отклонена, потому что кто-то из основной команды категорически против этой возможности. Это то, что я хотел бы зафиксировать в первую очередь, прежде чем тратить время на это...

@NathanaelA Фантастическая перспектива !!!!!!! и посмотрите, я использовал много восклицательных знаков ;-) Вы буквально попали в точку.

Да, я могу сделать DSX, но мне нужен способ интегрировать его в текущую систему сборки Flutter, поэтому мне нужно обязательство со стороны текущей команды Flutter, прежде чем двигаться дальше. Интеграция с IDE практически тривиальна в VS Code, но не так много в Intellij (если только у Google нет доступа к поддержке Intellij JSX).

@zoech , нет! Я думаю, что это проблема. Я помню, как разрабатывал приложение для Android с нативной Java и XML. Мы по-прежнему используем XML для языковой части пользовательского интерфейса. Я думаю, что использование Dart для логики и пользовательского интерфейса довольно странно, и эта проблема очевидна. кроме того, я просто надеюсь, что Google добавит идею пользовательского интерфейса React во флаттер. Пользовательский интерфейс React очень мощный и лаконичный.

@JonathanSum Я видел много комментариев по этому поводу.
Для меня это по-прежнему выглядит так, как будто люди хотят чего-то, потому что они не хотят менять свои привычки, а не потому, что это выгодно для платформы.

Кому-то нравится jsx, кому-то нет. Почему бы не поддержать два способа реализации пользовательского интерфейса. Вы можете написать jsx-подобный синтаксис, и он, наконец, будет соответствовать нативному синтаксису, почему бы не поддерживать?

@yuu2lee4 https://github.com/flutter/flutter/issues/11609#issuecomment -364811331

@зоэчи

Для меня это все еще выглядит как то, что люди хотят, потому что они не хотят менять свои привычки.

Это справедливое замечание, но не было бы лучше, если бы Flutter стал средством реализации и устранил как можно больше трений для людей (за пределами Google), чтобы принять Flutter? Такое сторожевое поведение не завоевывает сердца и умы разработчиков.

@yuu2lee4

Кому-то нравится jsx, кому-то нет. Почему бы не поддержать два способа реализации пользовательского интерфейса. Вы можете написать jsx-подобный синтаксис, и он, наконец, будет соответствовать нативному синтаксису, почему бы не поддерживать?

Отличный вопрос. Учитывая, что я делаю всю работу над DSX, который похож на JSX, и @Hixie лично прислал мне электронное письмо, взволнованный прогрессом, я не понимаю, почему бы не поддержать его, я не вижу, почему бы не протянуть руку и не сказать 'Что я могу сделать, чтобы помочь вам? Что мешает вам сделать это?»

честно говоря, я начинаю думать, что этот заголовок в том же направлении, что и предыдущий... что не помогло бы...

@cbazza

@Hixie лично прислал мне электронное письмо, взволнованный прогрессом..

Так почему бы вам не продолжить, и другие, кто может помочь, тоже должны присоединиться и помочь? Если мы не хотим, чтобы это всплыло, как в другой ветке... Я думаю, нам следует обсудить, что такое блоки, как нам это сделать, как заставить это работать и разместить их там... и Я также думаю, что команда флаттера и дротика каким-то образом начала работу над уменьшением многословности написания пользовательского интерфейса...
Возможно, команда не сможет присоединиться сейчас, но я считаю, что это достойное дело, хотя я считаю, что это так, хотя для меня это нормально, какой бы подход ни подходил ... в какой-то момент они наверстают упущенное ... так что @cbazza давайте продолжим то, что вы делаете, и вытащите его... как этот парень http://mutisya.com/ в первые дни, хотя я не знаю его состояния... Я также знаю, что @NathanaelA может помочь, потому что он внес свой вклад действительно удивительные вещи и инструменты для Nativescript... Давайте выпустим их, чтобы предоставить большему количеству разработчиков больше возможностей...

@МайклСова
Причина не тратить на это больше времени, как сказал @NathanaelA :

Тем не менее, меня больше всего беспокоит @sethladd , если я потрачу много времени на патч; будет ли она отклонена, потому что кто-то из основной команды категорически против этой возможности. Это то, что я хотел бы зафиксировать в первую очередь, прежде чем тратить время на это...

Хорошо, вот что у меня есть:
(a) Препроцессор, который принимает файлы *.dsx и выводит файлы *.dart.

Вот что мне нужно:
(1) Кто-то, кто позаботится об интеграции «VS Code». Из моего расследования это выглядит просто.
(2) Кто-то, кто придумает, как добавить возможности препроцессора в систему сборки Flutter, чтобы отладка работала правильно. Я имею в виду, что пошаговое выполнение кода будет выполняться в файлах *.dsx через что-то вроде исходной карты и т. д.

После того, как 2 вышеуказанных пункта будут выполнены, у нас будет первоначальная сквозная система, чтобы сдвинуться с мертвой точки. Есть берущие?

Итак, как вы можете видеть выше, (1) и (2) требуют изменений в коде Flutter, которые команда Flutter может отклонить, поэтому без поддержки/обязательств эта функция застревает.

@cbazza отлично, так что давайте пригласим сюда одного из членов команды флаттера, чтобы он сообщил нам, готовы ли они взять на себя раз и два... так кого мы можем здесь найти, чтобы помочь нам прогрессировать...?

Для (2) я думаю, что лучше всего связаться с командой Dart, возможно, через [email protected] или их систему отслеживания проблем? Я считаю, что одной из целей Dart 2 было создать инфраструктуру для большего количества экспериментов с языком и позволить сообществу создавать такие эксперименты, как DSX. Возможно, @anders-sandholm @mit-mit или @mraleph укажут вам правильное направление.

@sethladd Спасибо за быстрый ответ, не могли бы вы также скопировать консультантов и, возможно,
dart team и в эту ветку
@cbazza , не могли бы вы вмешаться, чтобы начать этот дискурс с указанным консультантом.
что касается интеграции «VS Code», я уверен, что как только мы получим 2, возможно, @DanTup может быть заинтересован в том, чтобы помочь

Просто некоторые мысли

Хорошо, вот что у меня есть:
(a) Препроцессор, который принимает файлы *.dsx и выводит файлы *.dart.

Это, вероятно, все, что вам нужно для запуска, это и файловый наблюдатель для перестроения изменений — см. FileSystemEntity . Проблема в том, что эта грамматика .dx является надмножеством дартланга, поэтому вам также придется анализировать весь Дарт. Это будет сложно, потому что в отличие от JavaScript, < и > используются в большем количестве мест. Я думаю, парсер Dart уже написан в Dart и где-то внутри репозитория sdk, но я не знаю, где

1. Для интеграции vscode и Intellij вам нужна не система сборки флаттера, а анализатор дротика. Я думаю, вы можете создать для этого плагин, который будет использовать dx, транспилировать его в dart, а затем отображать результаты обратно в исходный файл. Вот как работает плагин анализатора angular , предоставляя такие вещи, как автозаполнение html-файлов.

2. Вам нужен build runner , это гораздо более сложный пакет для выполнения a .

@МайклСова
Отлично, так что, я думаю, вы берете на себя (1) и (2), чтобы я мог сосредоточиться на транспайлере?

@jonahwilliams
Я знаю, что полный анализ дротика будет сложным и не очень необходимым прямо сейчас, потому что я всегда могу использовать свои маркеры для первого выпуска (https://spark-heroku-dsx.herokuapp.com/index.html)

Но одно можно сказать наверняка: нам нужно, чтобы IDE и отладчик работали должным образом, иначе люди не будут использовать DSX, потому что компромисс слишком велик. Я имею в виду «используйте DSX и забудьте о символьной отладке», не очень привлекательное предложение. Это также причина, по которой я хочу, чтобы хотя бы одна IDE поддерживалась, а VS Code был бы таким же простым, как пирог (поскольку он уже поддерживает JSX в своих json-файлах определения синтаксиса Typescript и Javascript)

re: IDE и отладчик, предположительно, реализуя эту функцию в инфраструктуре Dart 2 и «общем интерфейсе», вы сможете позволить более высоким уровням стека знать о DSX. Я рекомендую работать с командой Dart и научиться исследовать различные части Common Front End и его API.

@MichaelSowah Я сделал копию людей из Dart в https://github.com/flutter/flutter/issues/15922#issuecomment -376960770

@NathanaelA , не могли бы вы присоединиться к (1) и (2), так как теперь у нас явно есть поддержка со стороны команды

Не уверен; в данный момент -- я завален несколькими клиентскими проектами. Но я хотел бы изучить, как подключиться к конвейеру компиляции и, возможно, создать исходные карты. (т.е. 2) Но может пройти пара недель, прежде чем я смогу это сделать.

@NathanaelA Нет никакой спешки или чего-то еще, так что все хорошо :-)

Если DSX — это просто Dart + Virtual closing tag , то реальной выгоды нет. Одним из преимуществ dart является то, что мы можем использовать функции и переменные для создания части виджета и повышения удобочитаемости.

Кроме того, с DSX и препроцессором мы потеряем возможность горячей перезагрузки за доли секунды, верно @cbazza ?

Нет, DSX похож на JSX и полностью отличается от закрывающего тега Dart + Virtual, что вы можете сделать сегодня с вашим деревом виджетов Dart и IDE.

DSX описан здесь:
https://spark-heroku-dsx.herokuapp.com/index.html

DSX — это Dart, поэтому все преимущества Dart, которые вы описываете, присутствуют. Люди, знакомые с JSX, сразу поймут и полюбит его.

Нет, вы ничего не потеряете, ничего не изменится для обычного файла *.dart, который вы создаете, у вас все еще есть горячая перезагрузка доли секунды.
Теперь, если у вас есть файл *.dsx, он сначала будет транспилирован в *.dart, и этот процесс быстрее, чем я могу моргнуть !!! Так что это будет незаметно для пользователей DSX.

Прежде чем это снова будет закрыто, позвольте мне сначала закончить то, что я хочу сказать.
Текущий пользовательский интерфейс флаттерной части является проблемой, и я не пытаюсь продать идею React.
Поскольку структуру пользовательского интерфейса флаттера очень сложно представить в уме с помощью этих скобок, нам действительно нужно что-то улучшить. Я настоятельно рекомендую использовать React Native или все это, например React. React не только упрощает чтение, но и разделяет огромный код пользовательского интерфейса на разные группы. В результате я могу быстрее управлять огромным сложным кодом пользовательского интерфейса и легко его читать. С другой стороны, при большом количестве деревьев со скобками только во флаттере я не знаю, как их читать.

@JonathanSum вы пробовали последнюю версию Android Studio (3.1) с закрывающими ярлыками?

@14n Да, я вижу эти виртуальные закрывающие теги и комментарии.

Большое XML-подобное дерево виджетов может быть таким же трудным для чтения, как и любая другая крупная вещь, будь то Dart, JSON, YAML или JSX. Не похоже, что сам JSX решает проблему читабельности.

У меня не было проблем с чтением деревьев виджетов разумного размера с текущим синтаксисом. Кроме того, Flutter продвигает композицию, поэтому, когда определенный виджет становится слишком большим, его легко разделить на несколько меньших виджетов.

Субъективное мнение о предлагаемом формате DSX:

1. Визуально никакой реальной пользы, и опять же - чтение большого XML-дерева может быть столь же болезненным, поэтому не похоже, что это решает проблему. Продвижение методов чистого кода, например, на самом деле решит проблемы с читабельностью, но эти методы могут быть применены к (почти) любому синтаксису.
2. Требуется изучение другого DSL/синтаксиса. Мне очень-очень-очень нравится, что мне нужно знать только один синтаксис — Dart — чтобы делать все — верстку, стили, анимацию, логику. Это гораздо удобнее как для новичков, так и для опытных разработчиков по сравнению с тем, что произошло с Web с html/js/jsx/ts/coffee/css/sass/scss. На самом деле, я даже считаю это большим преимуществом Flutter по сравнению с другими платформами.

Тем не менее, я считаю, что Dart можно улучшить, чтобы сделать его более выразительным при использовании для описания пользовательских интерфейсов, хотя я бы предпочел, чтобы он был скорее расширением существующего синтаксиса Dart, а не полностью новым DSL.

Пожалуйста, перестаньте пытаться сделать Flutter «горячей новинкой». Это горячая новинка сама по себе, пусть исследует новые парадигмы.

@naiveaiguy Я думаю, это горячо. Это делает меня очень продуктивным и позволяет мне делиться кодом с браузерными и серверными приложениями.
Мне не нужна шумиха на одно лето. Мне нужно что-то, что позволит мне выполнять свою работу.
Это именно то, что делают Flutter и Dart.

Мои мысли об этом отражают то, что сказал @pulyaevskiy в https://github.com/flutter/flutter/issues/15922#issuecomment -377666972. Все примеры, которые я видел, которые не очень читабельны, обычно можно привести в порядок в существующем коде, и я думаю, что в Dart могут быть внесены более мелкие изменения (аналогично удалению new/const), которые могли бы улучшить его еще больше. . Поддержка совершенно другого набора файлов с совершенно другим синтаксисом и совершенно новым набором кода инструментов кажется высокой ценой за то, что я считаю относительно небольшим выигрышем (FWIW, я также предпочитаю React без JSX).

Я не знаю, полностью ли это применимо здесь, так как предлагаемый dsx также позволяет использовать обычный код Dart, но каждый раз, когда я слышу, как кто-то говорит о новом синтаксисе, я вспоминаю этот замечательный пост Gilad A DOMain of Shadows . Эти вещи всегда сложнее, чем люди думают. Это не так просто, как просто транспилировать код, потому что люди ожидают ошибок в реальном времени, завершения кода, рефакторинга, всплывающих подсказок и т. д. — это большая задача.

Вместо работающего транспилятора мне было бы более интересно увидеть трехстороннее сравнение между некоторым кодом, который считается трудным для чтения, как он будет выглядеть в этом предлагаемом синтаксисе и как он будет выглядеть, если вы можете внести какие-либо изменения в существующий синтаксис Dart без замены всех скобок. Например, что мне нравится в React, так это то, что дочерние элементы передаются как varargs в качестве последнего параметра — я думаю, что child и children добавляют много шума во Flutter — возможно, здесь есть место для улучшения . Также ведутся дискуссии о том, может ли помочь изменение форматирования или выделение имен классов виджетов . Похоже, рефакторинг Extract Widget находится на пути, чтобы легко разбить большие методы сборки. И, конечно же, в IntelliJ есть представление Flutter Outline, которое позволяет вам видеть код в виде дерева, а выбор синхронизируется с позицией курсора в редакторе (и я действительно надеюсь получить что-то подобное в VS Code, хотя он заблокирован). некоторыми функциями VS Code, подобными этой, так что не стесняйтесь 👍!).

@пуляевский
Я понимаю, о чем вы говорите, но экспериментировать — это хорошо, это путь к эволюции. Даже если мои эксперименты с DSX потерпят неудачу, я надеюсь, что другие экспериментируют со многими другими вещами и объединят лучшие идеи для создания потрясающих технологий.

@сетладд
Спасибо за наводки.
Хотелось бы получить ответ от @anders-sandholm @mit-mit или @mraleph на
как работать с инфраструктурой Dart 2 и «общим интерфейсом».
Я посмотрю на это с @NathanaelA.

@ДанТуп

Эти вещи всегда сложнее, чем люди думают. Это не так просто, как просто транспилировать код, потому что люди ожидают ошибок в реальном времени, завершения кода, рефакторинга, всплывающих подсказок и т. д. — это большая задача.

Да вы правы. Мой комментарий «тривиальный, простой как пирог» относился только к тому, чтобы заставить редактор распознавать синтаксис .dsx. Я заглянул в Intellij, и для этого им требуется полный анализатор языка (так что это сложно), тогда как VS Code было намного проще с файлами синтаксиса, и я также заметил, что файлы синтаксиса Typescript/Javascript уже поддерживают JSX (а DSX имеет только незначительные изменения по сравнению с JSX).

Мы обязательно обратимся к вам за помощью/направлением, чтобы начать наши эксперименты.

В итоге у меня есть:
(a) Препроцессор, который принимает файлы *.dsx и выводит файлы *.dart.
https://spark-heroku-dsx.herokuapp.com/index.html

Мне нужна помощь с:
(1) Кто-то, кто позаботится об интеграции «VS Code».
(2) Кто-то, кто придумает, как добавить возможности препроцессора в систему сборки Flutter, чтобы отладка работала правильно. Я имею в виду, что пошаговое выполнение кода будет выполняться в файлах *.dsx через что-то вроде исходной карты и т. д.

@NathanaelA поможет с (2).

Так что я все еще ищу людей, чтобы помочь с (1)
Есть берущие? @birkir @yuriy-manifold @tehfailsafe @alexkrolick @sanketsahusoft

@DanTup - я не профессионал в JSX, но я могу говорить о формате NativeScript XML. Я могу сделать:

Любое свойство, которое поддерживает класс StackLayout, может быть добавлено в XML. Так что это отношения один к одному; что устраняет массу лишнего мусора: Итак, давайте посмотрим на демонстрацию Flutter:
https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/gallery/home.dart#L39 -L63

<AnimationBuilder animation="{{animation}}">
   <Stack>
      <BackgroundLayer top="{{-layer.parallaxTween.evaluate(animation)}}" left=0.0 right=0.0 bottom=0.0>
          <Image src="{{layer.assetName}}" package="{{layer.assetPackage}} fit="cover" height="{{maxHeight}"}/>
      </BackgroundLayer>
   </Stack>
</AnimationBuilder>

Я считаю, что это легче читать и понимать, если я правильно преобразовал его. :ухмыляясь:

@NathanaelA Что произойдет, если вам нужно сделать что-то более динамичное, например, позвонить map ? Вот код из того же файла:

  Widget build(BuildContext context) {
    return new AnimatedBuilder(
      animation: animation,
      builder: (BuildContext context, Widget child) {
        return new Stack(
          children: _kBackgroundLayers.map((_BackgroundLayer layer) {
            return new Positioned(
              top: -layer.parallaxTween.evaluate(animation),
              left: 0.0,
              right: 0.0,
              bottom: 0.0,
              child: new Image.asset(
                layer.assetName,
                package: layer.assetPackage,
                fit: BoxFit.cover,
                height: _kFlexibleSpaceMaxHeight
              )
            );
          }).toList()
        );
      }
    );
  }

Как будет выглядеть children: _kBackgroundLayers.map(...) в этом синтаксисе?

JSX/DSX определяет только преобразование тега как:

В:
<A property="a"/>
Вне:
new A(property: a)

В:

<A property="a">
  <B/>
  <C/>
</A>

Вне:

new A(property: a, 
children: <Widget>[
   new B(), 
   new C()
])

и вы можете использовать {} для размещения любого действительного кода Dart, например оценки переменных и анонимных функций и т. д. {} можно разместить в 3 местах. В приведенном ниже примере показано, как {} используется в 2 местах (атрибуты тега и как дочерние элементы), а 3-е место — с оператором расширения.

  Widget build(BuildContext context) {
    return <AnimatedBuilder
      animation={animation}
      builder={(BuildContext context, Widget child) {
        return <Stack> {
          _kBackgroundLayers.map((_BackgroundLayer layer) {
            return <Positioned
              top={-layer.parallaxTween.evaluate(animation)}
              left={0.0}
              right={0.0}
              bottom={0.0}>
              <Image.asset [layer.assetName]
                package={layer.assetPackage}
                fit={BoxFit.cover}
                height={_kFlexibleSpaceMaxHeight}
              />
            </Positioned>;
          }).toList()
        } </Stack>;
      }}
    />;
  }

Поместите приведенный выше код в файл Javascript и просмотрите его с помощью VS Code/Intellij. Обратите внимание на +/- (слева от строки), которые вы можете использовать, чтобы открывать и сворачивать узлы XML, чтобы сделать дерево меньше/больше.

Почему мы не можем просто признать проблему и перейти на React Native? Мы так поступим или нет?

@JonathanSum извините, когда вас направляют сюда, но как вы думаете, кем вы являетесь? Нет общей проблемы, просто то, что вам не нравится.
Вы хоть одно приложение написали с помощью Flutter?
Приведенные выше примеры смешивания Dart с XML выглядят намного хуже, чем просто Dart. Здесь нечего выигрывать.
Я пришел из Xamarin Forms, который использует xaml, и мне это очень понравилось. Но вместо того, чтобы жаловаться, почему Flutter не поддерживает Xaml, я сразу же погрузился в него и начал адаптироваться и учиться.
Смиритесь с этим, если вы хотите работать как в React, тогда используйте Reactive вместо того, чтобы всех здесь раздражать.

Вот тот же блок кода, что и выше, но в чистом Dart и рефакторинге, чтобы избежать глубокой вложенности.
Любопытно, какие части фрагмента ниже трудно прочитать и/или понять?

Widget build(BuildContext context) =>
    AnimatedBuilder(animation: animation, builder: _buildChild);

_buildChild(BuildContext context, Widget child) {
  return Stack(
    children: _kBackgroundLayers.map((_BackgroundLayer layer) {
      final image = Image.asset(layer.assetName,
          package: layer.assetPackage,
          fit: BoxFit.cover,
          height: _kFlexibleSpaceMaxHeight);
      return Positioned(
          top: -layer.parallaxTween.evaluate(animation),
          left: 0.0,
          right: 0.0,
          bottom: 0.0,
          child: image);
    }).toList(),
  );
}

На самом деле, лично я бы приблизил его к чему-то вроде этого:

Widget build(BuildContext context) => AnimatedBuilder(
      animation: animation,
      builder: _buildChild,
    );

_buildChild(BuildContext context, Widget child) {
  return Stack(
    children: _kBackgroundLayers.map(_imageForLayer).toList(),
  );
}

_imageForLayer(_BackgroundLayer layer) {
  final top = -layer.parallaxTween.evaluate(animation);
  final image = Image.asset(
    layer.assetName,
    package: layer.assetPackage,
    fit: BoxFit.cover,
    height: _kFlexibleSpaceMaxHeight,
  );
  return PositionedImage(top: top, image: image);
}

class PositionedImage extends StatelessWidget {
  PositionedImage({this.top, this.image});
  final double top;
  final Image image;

  <strong i="10">@override</strong>
  Widget build(BuildContext context) =>
      Positioned(top: top, left: 0.0, right: 0.0, bottom: 0.0, child: image);
}

Опять же, кажется, что мы смешиваем здесь две разные проблемы:

1. Нелюбовь к синтаксису Dart и потребность в синтаксисе, подобном XML/JSX.
2. Читабельность кода Flutter.

Есть ли здесь люди, которые верят, что внедрение JSX улучшит читабельность? По-прежнему можно было бы создавать глубоко вложенные деревья в коде, и разработчикам все равно нужно было бы выполнить те же шаги, которые я только что выполнил с версией Dart, чтобы сделать вещи читабельными.

Но то, что он определенно добавит, — это дополнительный шаг сборки/переноса с исходными картами и прочим, а также много работы по поддержке этой инфраструктуры в IDE и Dart SDK (анализатор, отладчик и т. д.).

@JonathanSum @escamoteur Мы не высказываемся агрессивно по этому проекту. Пожалуйста, оставайтесь коллегиальными. Спасибо. Недавняя дискуссия была дружеской и продуктивной, поэтому спасибо всем, кто принял в ней участие!

В целом, мне кажется, что добавление DSX приведет к фрагментации экосистемы Flutter на самых ранних этапах, при этом будет проделана большая работа, чтобы попытаться сохранить полноту функций обоих синтаксисов, на самом деле в большинстве случаев это не значительно улучшит читабельность и привлечет тех разработчиков, которые привлекаются к проектам исключительно из-за схожего синтаксиса и/или парадигмы горячей новинки.

@Hixie извините, что я вышел из себя, но я думаю, что Flutter и так находится на хорошем пути, и у разработчиков Flutter достаточно, чтобы обойтись без таких требований

@escmoteur - Я думаю, именно поэтому я специально сказал «усилия сообщества». Я не думаю, что это должно привлекать основную команду флаттера, помимо того, что они готовы принять патчи... Что Сет, похоже, сказал, что мы можем продолжить. Если вы не заинтересованы в этой функции; тогда не пользуйся... :grinning:

@escamoteur , я прошу прощения за то, что я сказал.
Я создал несколько флаттер-приложений из руководств. Все, что я думаю о флаттере, это то, что все является объектом, а не виджетом. Это похоже на огромный кусок сложных кодов объектно-ориентированного программирования, склеенных беспорядочно.

Я думаю, что самое главное — создать фреймворк, который легко читать и которым легко управлять, и он не должен быть чертовски сложным. Самое главное, я думаю, что способ сборки React-Native соответствует тому, что люди создают естественным образом. С другой стороны, флаттер должен соединять виджет с состоянием с виджетом без состояния и... Более того, большинство UI-фреймворков, которые мы используем в эти годы, ориентированы на этот способ React в качестве стандарта, и я думаю, что флаттер должен сосредоточиться на этом больше. а не горячая перезагрузка (когда я пытаюсь добавить новые новые классы, консоль говорит мне перезапустить все вместо горячей перезагрузки). Я действительно думаю, что это вопрос, а не комментарий или требование.
naiveaiguy сказал:

Пожалуйста, перестаньте пытаться сделать Flutter «горячей новинкой». Это горячая новинка сама по себе, пусть исследует новые парадигмы.

Вы можете пойти проверить их.
https://facebook.github.io/react-native/
Мысли в Реакции:
https://reactjs.org/docs/design-principles.html
Флаттер:
https://flutter.io/tutorials/animation/

Посмотрите на React-Native, он даже помещает управление состоянием выше, а части пользовательского интерфейса — ниже. Это искусство и естественное поведение человека. Вот почему кривая обучения и время управления являются низкими. Поэтому, пожалуйста, не сравнивайте XML или даже Xamarin с React Native. Более того, фаттер — это просто хаос и беспорядок. Состояние без состояния подключается к состоянию с состоянием, а состояние создания соединяет все в состоянии без состояния. С React-Native вы рисуете красивую картинку карандашом. С флаттером это похоже на падение воды на бумагу и разделение воды на разные части. Но я думаю, что мы все еще находимся в первых днях флаттера. У React-Native своя философия и цели, а флаттер — это просто серьезный проект, иначе со мной все не согласны.

@JonathanSum

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

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

Я думаю, что самое главное — создать фреймворк, который легко читать и которым легко управлять, и он не должен быть чертовски сложным.

Это тавтология. Очевидно, что все хотят этого, но люди по-разному подходят к проблеме. Парадигма Флаттера — одна из них.

Самое главное, я думаю, что способ сборки React-Native соответствует тому, что люди создают естественным образом.

Я не думаю, что что-то столь незначительное, как синтаксис для создания пользовательского интерфейса, влияет на то, насколько проста в использовании платформа в целом.

С другой стороны, флаттеру необходимо подключить виджет с состоянием к виджету без состояния и...

Похоже, вы принципиально не согласны с тем, как Flutter подходит к приложениям. Почему вы его используете? Более того, это не совсем верное замечание. Вы не выражаете что-то, что вы считаете неправильным, вы просто говорите: «Я думаю, что связи между виджетами без состояния и виджетами с состоянием неверны и сложны каким-то неясным образом, который я не буду объяснять».

Более того, большинство фреймворков пользовательского интерфейса, которые мы используем в эти годы, ориентированы на этот способ React как на стандарт.

Аргумент к народу.

и я думаю, что флаттер должен сосредоточиться на этом больше, чем на горячей перезагрузке (когда я пытаюсь добавить новые новые классы, консоль говорит мне перезапустить все вместо горячей перезагрузки)

Да, потому что горячая перезагрузка — это не очень простая функция, как это сделал Flutter. Я бы сказал, что цикл разработки, которого удалось достичь Flutter, даже в 30-40% изменений кода, действительно впечатляет, и его можно было бы замедлить только за счет слоев транспиляции.

Однако фаттер — это просто хаос и беспорядок.

Здесь вы ясно дали понять, что вам просто не нравится подход Flutter. Не используйте его тогда. И если вы думаете, что каким-то волшебным образом изменение синтаксиса пользовательского интерфейса сделает Flutter не «хаосом и беспорядком», тогда вам нужно предоставить четкие доказательства того, что это работает в тех же самых настройках и ограничениях, с которыми работает Flutter.

Вот почему кривая обучения и время управления им низкие. Пожалуйста, не сравнивайте XML или даже Xamarin с React Native.

Достаточно справедливо — тогда используйте React Native. Разработчики отлично справляются со своей парадигмой.

Безгражданники подключаются к апатридам и создают состояния в апатридах.

Какой? Нет. Это просто неправильно - что вы здесь имеете в виду?

С React-Native вы рисуете картинку карандашом. С трепетом это похоже на каплю воды на бумагу и разделение воды на разные части.

Откровенно говоря, эта аналогия не имеет для меня особого смысла. Я мог бы легко просто высказать обратное мнение, и мы вернулись бы к тому, с чего начали.

Вы ведете себя так, как будто это самоочевидно («давайте посмотрим правде в глаза»), а мы просто претенциозны и/или невыносимы, говоря, что команде Flutter не следует с этим сталкиваться. Это нехорошее отношение, если вы хотите, чтобы другие люди относились к вам серьезно.

Дополнительный момент: пожалуйста, не делайте вид, что это то, что сторонние разработчики могут сделать без какого-либо участия или работы со стороны основной команды Flutter. Команде Flutter придется проделать много дополнительной работы с IDE и плагинами для редакторов, пропагандой и решением проблем GitHub, если такая функция будет удовлетворительно реализована как гармоничная часть Flutter.

@naiveaiguy
Хорошо, я думаю, вы правы. Я просто случайный человек, сравнивающий всех здесь и человека, которому нравится React. У Flutter свой путь, и у React тоже. Я сожалею о своем отношении, и я был не мил.

@JonathanSum Я думаю, вам просто нужно больше времени, чтобы действительно понять, как создаются приложения Flutter. Справедливости ради, не так много документов по архитектуре, как правильно использовать унаследованные виджеты и как подключить вашу модель представления к виджетам.

Я хотел бы знать, почему вас вообще интересует Flutter? Для меня React не годится из-за JS

Так много комментариев, так мало времени, возможно, я должен сосредоточиться...

@escamoteur , что именно вы имеете в виду под:

Для меня React не годится из-за JS

ES6/7 или Typescript настолько близки к Dart/Kotlin/Swift, что я с удовольствием станцую с любой из этих дам :)

Что меня привлекает во Flutter, так это поддержка графики и анимации. Прямая векторная графика Skia построена поверх OpenGL для сверхбыстрого UX со скоростью 60 кадров в секунду, чтобы легко реализовать такие вещи, как то, что вы видите на:
https://uimovement.com/
Я занимаюсь пользовательским UX, и Flutter позволяет это. Я внедрял UX на протяжении десятилетий, и мне очень нравится создавать его с помощью декларативных/реактивных методов, и Flutter поддерживает это.

@пуляевский

Опять же, кажется, что мы смешиваем здесь две разные проблемы:

• Нелюбовь к синтаксису Dart и потребность в синтаксисе, подобном XML/JSX.
• Читабельность кода Flutter.

Правильно, этот билет здесь (и предыдущий) просто требует возможностей, подобных JSX. Есть и другие билеты на улучшения языка Dart, чтобы уменьшить многословие текущего кода построения пользовательского интерфейса.

Есть ли здесь люди, которые верят, что внедрение JSX улучшит читабельность?

Может для них, каждому свое.

Да, приведенный вами пример уменьшает дерево, но, разбивая его на части и перемещая части в другое место, становится еще труднее увидеть всю структуру в коде. Я бы предпочел сохранить всю структуру в одном месте и вынести из дерева некоторые связанные свойства (именованные параметры) и использовать оператор расширения DSX, чтобы ввести их. Просто мое предпочтение.

Но то, что он определенно добавит, — это дополнительный шаг сборки/переноса с исходными картами и прочим, а также много работы по поддержке этой инфраструктуры в IDE и Dart SDK (анализатор, отладчик и т. д.).

Мы занимаемся этим, и @sethladd заявил, что I believe one of the goals of Dart 2 was to create an infrastructure for more experimentation with the language and let the community create experiments like DSX.

@naiveaiguy

Я бы сказал, что цикл разработки, которого удалось достичь Flutter, даже в 30-40% изменений кода, действительно впечатляет, и его можно было бы замедлить только за счет слоев транспиляции.

Да, мне очень нравится горячая загрузка, хотя она не всегда работает. Я обязательно возьму это, но ваш комментарий о замедлении транспиляции безоснователен. Если вы не используете DSX, это ничего не добавит к вашему времени компиляции. Если вы используете DSX, транспайлер работает настолько быстро, что вы его даже не заметите.

Дополнительный момент: пожалуйста, не делайте вид, что это то, что сторонние разработчики могут сделать без какого-либо участия или работы со стороны основной команды Flutter. Команде Flutter придется проделать много дополнительной работы с IDE и плагинами для редакторов, пропагандой и решением проблем GitHub, если такая функция будет удовлетворительно реализована как гармоничная часть Flutter.

Не совсем. Мы это делаем и просим только не блокироваться. Мы просим руководства, чтобы указать нам правильное направление. Я не буду делать все это один, так что теперь нас двое (спасибо, @NathanaelA), и мы ищем еще людей (как минимум еще 1), если они хотят помочь.

Приветствую всех! Прежде всего, я хотел бы отметить, что нет особого смысла продолжать дискуссию по этому вопросу взад и вперед - он будет большим и трудно уследимым из-за линейной структуры. Ваши аргументы будут потеряны и перефразированы снова и снова. Давайте сведем это к чистым числам:

• Если вы ЗА эту функцию - ставьте палец вверх самому первому комментарию по этому вопросу.
• Если вы ПРОТИВ этой функции - ставьте палец вниз самому первому комментарию по этому вопросу.

Далее я хотел бы уточнить заявление @sethladd , оно должно читаться как _"одной из целей Dart 2 было создание инфраструктуры для дальнейших экспериментов с языком для команды Dart "_.

Даже в Dart 2 мы не предоставляем никаких API-интерфейсов, позволяющих легко изменить синтаксис языка Dart без перестройки Dart SDK (или артефактов движка Flutter). Dart 2 предоставляет инфраструктуру _common front-end_ (CFE) (расположенную в pkg/front_end в исходных кодах Dart SDK), которая представляет собой синтаксический анализатор для языка Dart, написанный на Dart. Для чисто синтаксических изменений языка сахара, таких как DSX, вы должны иметь возможность просто редактировать код CFE, создавать Dart SDK (или движок Flutter) и иметь все инструменты (кроме кода подсветки синтаксиса, встроенного в соответствующие плагины IDE), чтобы подобрать ваше новое расширение синтаксиса. Обратите внимание, что в настоящее время только VM и dart2js фактически используют CFE, далее планируется переход анализатора. Как видите, здесь есть определенный барьер для входа.

Здесь важно подчеркнуть, что, поскольку нет API для расширения синтаксиса Dart, вам придется работать с языковой командой Dart, чтобы расширить язык. В настоящее время для этого нет формализованного процесса, однако для включения такой функции, как DSX, в Dart потребуется много доказательств и мотивации. (/fyi @leafpetersen @lrhn — поправьте меня, если я ошибаюсь)

Вот мои рекомендации сторонникам DSX-подобного решения:

• Прежде всего, вам действительно нужно изложить свое предложение в письменной форме и перенести обсуждение в место, которое способствует нелинейному обсуждению. Когда вы предлагаете языковые изменения, вам нужно иметь подробное описание того, что вы пытаетесь решить, и как это решается с использованием предложенных вами расширений синтаксиса. В противном случае невозможно оценить затраты и выгоды предлагаемого изменения. Затем вам нужен способ вести нелинейные обсуждения различных частей предложения, например

  • если вы поместите свое предложение в Google Doc, то люди смогут использовать встроенные комментарии для обсуждения различных компонентов вашего предложения;
  • в качестве альтернативы вы можете создать репозиторий GitHub с уцененным описанием вашего предложения и использовать проблему GitHub и PR для уточнения и обсуждения вашего предложения.

  Заметьте, я не говорю, что вам нужно придумать _формальную спецификацию_ для вашего изменения, которая по уровню уточнения была бы сравнима со спецификацией языка Dart. Вместо этого вам нужно иметь обширные примеры того, как работает предлагаемое изменение и какие преимущества оно дает.



• Далее, если вы можете, вы должны попытаться реализовать. Барьер здесь высок даже с инфраструктурой ДОВСЕ — но гораздо ниже, чем был раньше.

@mraleph Я думаю, что аргументы по поводу интеграции в Dart были больше связаны с хуками для запуска генерации кода или подобным, а не с изменением языка.
Я понятия не имею, что что-то подобное необходимо.
Я думаю, что в основном это может быть реализовано как Angular с его плагином Analyzer, только DSX вместо HTML.

@мралеф

Большое спасибо за разъяснения.
На самом деле мы не хотим модифицировать язык Dart, нам нужна возможность предварительной обработки, чтобы преобразовать наш экспериментальный DSX в Dart.
Кстати, вы можете попробовать это онлайн по адресу:
https://spark-heroku-dsx.herokuapp.com/index.html

Дело в том, что когда Dart только вышел, его можно было преобразовать в Javascript, а с помощью исходных карт можно было просто подключиться к экосистеме Javascript (несколько других языков сделали то же самое: Coffeescript, Typescript и т. д.). То, что мы ищем, похоже на это для Dart/Flutter. Мы ищем общую возможность предварительной обработки, которая позволила бы построить любой другой язык транспиляции поверх Dart/Flutter.

Что касается голосования, то в предыдущем билете есть несколько номеров:
https://github.com/flutter/flutter/issues/11609

@cbazza

На самом деле мы не хотим модифицировать язык Dart, нам нужна возможность предварительной обработки, чтобы преобразовать наш экспериментальный DSX в Dart.

Я говорил с точки зрения, что файлы *.dsx на самом деле являются файлами Dart, в которых вы можете использовать дополнительный синтаксис. И, как я уже сказал, в настоящее время нет API или точек расширения, которые облегчают создание таких расширений синтаксиса таким образом, который позволяет этим расширениям синтаксиса прозрачно взаимодействовать со всеми инструментами в экосистеме Dart. Кроме того, я не думаю, что есть какие-либо немедленные планы по разработке и предоставлению таких API или точек расширения, поэтому на сегодняшний день вам лучше всего сделать форк Dart SDK и встроить поддержку DSX в CFE.

Я также рекомендую думать о крайних случаях, а не о простых случаях. Например, представьте, что вы редактируете файл DSX. В этом случае вы, скорее всего, захотите увидеть завершение в реальном времени наполовину законченного кода, например, имена конструкторов и имена атрибутов. Как это будет работать с сопоставлением источников? Такие вещи составляют опыт разработчика.

@mraleph Еще раз спасибо.

Мы, безусловно, стремимся предоставить отличный пользовательский интерфейс для пользователей DSX, это точно.

Некоторым людям нравится XML-подобный синтаксис, некоторые люди ненавидят его. Возможно, добавление jsx-подобного синтаксиса слишком излишне. Меня больше всего беспокоит читабельность Flutter. в основном о скобках с глубоким вложением, child , children , шумах с запятой и т. д.)
Репост кода примера [1] здесь,

// Comparing Flutter to what it might look like in Kotlin
class TutorialHome : StatelessWidget {
    override
    fun build(context: BuildContext) = scaffold {
        appBar = appBar {
            leading = iconButton {
                iconImage = Icon(Icons.menu)
                tooltip = "Navigation menu"
                onPressed = null
            } 
            titleText = "Example title"
            actions = [ // based on https://twitter.com/abreslav/status/867714627060322305
              iconButton { 
                iconImage = Icon(Icons.search)
                tooltip = "Search"
                onPressed = null  
              }
            ]
        }
        body = center {
            // Remember: This is a fully functional programming environment. You can execute any 
           //  code you can think of.
            child = Text("Hello ${MyApp.users.me.fullName.split(" ").first}!")
        }
        floatingActionButton = fab {
            tooltip = "Add"
            childImage = Icon(Icons.add)
            onPressed = null
        }
    }
}

Версия Dart 2 с new и необязательной точкой с запятой (код от @sethladd)[2],

class TutorialHome extends StatelessWidget {
  <strong i="13">@override</strong>
  Widget build(BuildContext context) => Scaffold(// implicit new!, also matching your Kotlin here
      appBar: AppBar(
        leading: IconButton(
          icon: Icon(Icons.menu)
          tooltip: 'Navigation menu'
          onPressed: null
        )
        title: Text('Example title')
        actions: [ // Dart + strong mode will infer the contents of the list
          IconButton(
            icon: Icon(Icons.search)
            tooltip: 'Search'
            onPressed: null
          )
        ]
      )
      // body is the majority of the screen.
      body: Center(
        child: Text('Hello, world!')
      )
      floatingActionButton: FloatingActionButton(
        tooltip: 'Add' // used by assistive technologies
        child: Icon(Icons.add)
        onPressed: null
      )
   )
}

IMO, версия kotlin чистая и выглядит лучше. Версия Dart 2 очень близка и все еще имеет возможности для улучшения (если Dart поддерживает методы расширения?). Поэтому я думаю, что улучшение синтаксиса Dart для уменьшения многословия — правильное направление.

[1] https://gist.github.com/asarazan/b3c23bef49cf9a61f5a1a19de746f1b0
[2] https://gist.github.com/sethladd/7397a067deb43b6052032195fcb26d94

С другой стороны, мне нравится способность JSX к составлению.

Работать с компонентами (виджетами) очень просто и доступно, перемещать их вверх и вниз по дереву в редакторе можно с помощью сочетания клавиш (Alt+UP / Alt+DOWN). Это особенно актуально при перемещении вещей в контейнер, строку, столбец и т. д. и из него.

Но это не то, что DSX может решить самостоятельно. Сами виджеты должны быть
более ограничено именованием свойств, чтобы это работало. В React это свойство называется children и является основным принципом в JSX. Flutter позволяет гибко именовать детей (дети, дети, тело и т. д.).

Вот отличное обсуждение плюсов и минусов: https://github.com/jsforum/jsforum/issues/1

Дартс	DSX

Источник: https://github.com/flutter/flutter/blob/master/examples/platform_view/lib/main.dart

Я должен признать, что образец DSX выглядит привлекательно. Но я боюсь, как только вы смешаете его с Dart Code, например, при использовании любого виджета-конструктора он будет выглядеть очень уродливо.

@birkir DSX должен иметь возможность поддерживать что-то вроде шаблона реквизита рендеринга для нескольких/не children дочерних слотов. Если он может принимать функции или ссылки на классы в качестве реквизита (что, вероятно, будет автоматически), он будет работать из коробки.

Что касается реализации инструментов, инструменты Javascript долгое время поддерживали нестандартный синтаксис и языковые расширения (Flowtype/Typescript/Babel), поэтому многие инструменты для JSX использовали существующие транспиляторы. Afaik Dart не сталкивался с таким уровнем фрагментации, поэтому инструментов еще не существует. Но сейчас самое время начать его строить 😄

ИМХО, json-подобный синтаксис намного лучше, чем ~xml-подобный~ синтаксис!

container {
  padding: EdgeInsets.symmetric { vertical: 16.0  }
}

@jaychang0917
Я не думаю, что JSX можно сравнить с XML. Я думаю, что JSX и XML - это две разные вещи, как сверхзвуковой самолет и пропеллерный самолет.

С JSX вы можете делать следующее:

<supersonicAircarft 
          aircarft={{"F-22"}} 
          speed={{"mach2"}} 
          style={{"you can style it whatever you want as simple as css"}}
/>

или

<Image
          source={{uri: 'https://i.chzbgr.com/full/7345954048/h7E2C65F9/'}}
          style={{width: 320, height:180}}
        />

С помощью JSX мы можем даже разбить все по частям, как указано выше, или вы можете сгруппировать большую часть пользовательского интерфейса в один тег <>, чтобы поместить эту большую часть пользовательского интерфейса в любое место.

Вот почему React заменяет HTML и XML и использует JSX для создания приложений для iPhone или веб-приложений, или люди говорят, что JSX — это просто более крутая версия HTML.

• Я не люблю и XML, и HTML, и люблю JSX.

• Я думаю, что самое главное не в производительности, как iPhone против настольного компьютера.

• Самое главное, что его легко использовать как iPhone, так и настольный компьютер.

Например:

import React, { Component } from 'react';
import { Image, ScrollView, Text } from 'react-native';

class AwkwardScrollingImageWithText extends Component {
  render() {
    return (
      <ScrollView>
        <Image
          source={{uri: 'https://i.chzbgr.com/full/7345954048/h7E2C65F9/'}}
          style={{width: 320, height:180}}
        />
        <Text>
                        JSX is the philosophy, everything is a component. Simple is Complicate because you can 
                        form everything to your own perfect shape. 
        </Text>
      </ScrollView>
    );
  }
}

или напишите

< AwkwardScrollingImage/>

писать-один раз-бежит-везде

import { AwkwardScrollingImage } from './your-native-code';
class SomethingFast extends Component {
  render() {
    return (
      <View>
          <AwkwardScrollingImage/>
        <Text>
            JSX is the philosophy, everything is a component. Simple is Complicate because you can form everything to your own perfect shape. Everything is a widget or component.
        </Text>
      </View>
    );
  }
}

~ Flutter использует язык программирования для создания пользовательского интерфейса. ~

Ссылка:

Флаттер:
https://flutter.io/tutorials/layout/
React Native для сборки Android, Iphone и даже рабочего стола:
https://facebook.github.io/react-native/

@биркир
Ооо, это так здорово выглядит!!! только мясо и никаких костей :)
Представьте, что вы используете с ним https://builderx.io/ (взгляните на второе анимированное изображение — двухстороннее построение пользовательского интерфейса, подобное использованию Flex :)

@escamoteur
со встроенными компоновщиками это выглядело бы так же беспорядочно, как и с текущим способом; образцы были предоставлены выше:
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

в любом случае, я думаю, что текущий путь ясен и последователен. Смешивание некоторого кода дротика и тега < в файле дротика заставляет меня чувствовать, что код неудобен и неясен. С точки зрения разработчика Android это выглядит как написание кода java/kotlin в XML-файле макета :)

ТОЛЬКО МОИ ДВА ЦЕНТА

@JonathanSum эм...

Итак, каких преимуществ использования JSX не может дать текущий способ флаттера? Я не вижу никаких аргументов, которые вы назвали сильными.

JSX не похож на XML. JSX проще и мощнее, чем этот XML.

Кстати, JSX похож на xml , если мне не врет команда facebook :)

@jaychang0917
JSX — это не XML, потому что JSX проще и мощнее, чем этот XML (я говорю, что JSX не похож на XML).

Если вы говорите, что нет веских аргументов, позвольте задать вам вопрос.
Позвольте мне просто закончить свой разговор здесь. Если людям нужен JSX или DSX, в будущем будет аналогичный.

• Ссылка:
  https://facebook.github.io/jsx/
  This specification does not attempt to comply with any XML or HTML specification. JSX is designed as an ECMAScript feature and the similarity to XML is only for familiarity.

Хотя я скучаю по настоящим закрывающим тегам из XML :)
Идея: Автоматически генерируемые закрывающие теги

Kotlin решил бы и это. Только посмотрите, какие классные Kotlin-react и Anko

Kotlin-react не так уж и хорош, KSX был бы лучше :)

import React from 'react';

export function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}

package hello

import react.*
import react.dom.*

fun RBuilder.hello(name: String) {
    h1 {
        +"Hello, $name"
    }
}

package hello

import react.*
import react.dom.*

fun RBuilder.hello(name: String) {
   <h1>Hello, {name}</h1>
}

Теги просто не нужны :)

Находясь в лагере JSX/DSX/KSX, я определенно считаю, что теги принадлежат коду :)

@saied89
Вы хотите использовать тег для вложения элемента в другой элемент, как в HTML? Или вы хотите ввести слово «дети», «ребенок» или [ ]? Кроме того, JSX предоставляет такие возможности, как повторное использование сотен кодов пользовательского интерфейса путем ввода только одного тега.

Возможно, еще одним аспектом является форматирование по умолчанию, которое делает dart format . ИМХО читать тяжело, особенно с ведущим ребенком: /children.

Я бы действительно предпочел какое-то форматирование, которое подчеркивает древовидную структуру, что-то вроде этого:

 Widget build(BuildContext context) {
    return new Scaffold(
      appBar: new AppBar(title: new Text("WeatherDemo")),
      resizeToAvoidBottomPadding: false,
      body: 
        new Column(children: <Widget>
        [
          new Padding(
            padding: const EdgeInsets.all(16.0),
            child: 
            new TextField(
                    key: AppKeys.textField,
                    autocorrect: false,
                    controller: _controller,
                    decoration: new InputDecoration(hintText: "Filter cities",),
                    style:  TextStyle(fontSize: 20.0,),
                    onChanged: ModelProvider.of(context).textChangedCommand,
                    ),
          ),
          new Expanded(
                child: 
                new RxLoader<List<WeatherEntry>>(
                        key: AppKeys.loadingSpinner,
                        radius: 25.0,
                        commandResults: ModelProvider.of(context).updateWeatherCommand,
                        dataBuilder: (context, data) => new WeatherListView(data ,key: AppKeys.weatherList),
                        ),
          ),
          new Padding(
            padding: const EdgeInsets.all(8.0),
            child: 
            new Row(children: <Widget>
            [
                new Expanded(
                    child: 
                    // This might be solved with a Streambuilder to but it should show `WidgetSelector`
                    new WidgetSelector(
                            buildEvents: ModelProvider.of(context).updateWeatherCommand.canExecute,   //We access our ViewModel through the inherited Widget
                            onTrue:  new RaisedButton(    
                                            key: AppKeys.updateButtonEnabled,                           
                                            child: new Text("Update"), 
                                            onPressed: ModelProvider.of(context).updateWeatherCommand,
                                            ),
                            onFalse:  new RaisedButton(                               
                                            key: AppKeys.updateButtonDisabled,                           
                                            child: new Text("Please Wait"), 
                                            onPressed: null,
                                            ),

                        ),
                ),
                new StateFullSwitch(
                        state: true,
                        onChanged: ModelProvider.of(context).switchChangedCommand,
                   )
              ],
            ),
          ),
        ],
      ),
    );
  }

Возможно, это не идеальное решение, но оно должно показать направление.
@sethladd есть шанс сделать что-то в этом направлении?

Прежде всего, я рад, что это не становится таким горячим, как его родственная проблема : smile:.

Если бы меня попросили выбрать любой из двух синтаксисов, я бы склонился в сторону Dart. Это основано на нескольких фактах:

• Я предпочитаю переключаться между как можно меньшим количеством контекстов. Нравится вам это или нет, переход между синтаксисами — это способ сделать это. Этому может помочь инструментальная поддержка, но это приводит к следующему пункту.
• Я предпочитаю, чтобы команда разработчиков посвящала время другим проблемам, которые мешают нам кодировать определенные функции и/или мешают людям прыгать во Flutter. Я думаю, что отсутствие JSX-подобного синтаксиса не должно быть причиной того, что компания/разработчик/кто бы то ни был отвергает Flutter.
• Мы выиграем от каждого обновления Dart. Это особенно верно для Dart, поскольку Flutter является одним из его основных клиентов и является фреймворком пользовательского интерфейса. См., например, изменения new/const .
• Я высоко ценю безопасность типов. Не говоря о том, что JSX-подобный синтаксис не может быть типобезопасным, я не верю, что усилия по его реализации стоят своего дохода.

Помимо этого, я на самом деле предпочитаю синтаксис, подобный Kotlin. Особенно, если указанный синтаксис переносит некоторые функции Kotlin в Dart : innovate:.

@emalamela ,

Вот в чем дело, нет переключения контекста, как вы его называете, просто спросите любого опытного разработчика React. Кроме того, это разделение синтаксиса на самом деле является отличной функцией, потому что, когда вы смотрите на код, вы можете легко увидеть, что является декларативным, а что императивным.

Я думаю, что отсутствие JSX-подобного синтаксиса не должно быть причиной того, что компания/разработчик/кто бы то ни был отвергает Flutter.

Но, к сожалению, это будет для многих разработчиков React.

Мы выиграем от каждого обновления Dart.

Я не понимаю, как DSX также не выигрывает от обновлений Dart, поскольку это надмножество Dart.

Я высоко ценю безопасность типов. Не говоря о том, что JSX-подобный синтаксис не может быть типобезопасным, я не верю, что усилия по его реализации стоят своего дохода.

Усилия по обеспечению безопасности типов в DSX равны нулю, потому что DSX — это всего лишь крошечный слой синтаксического сахара поверх Dart, поэтому он использует систему типов Dart точно так же, как использует управляющие операторы Dart и т. д.
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

Спасибо за ваш вклад @cbazza !

Вот в чем дело, нет переключения контекста, как вы его называете, просто спросите любого опытного разработчика React.

Я не опытный разработчик React, поэтому для меня это переключение контекста. Так же, как и в Android, вам нужно прыгать с Java/Kotlin на XML, хотя скачок там больше. Одни языки, одни и те же инструменты, меньше накладных расходов.

Кроме того, это разделение синтаксиса на самом деле является отличной функцией, потому что, когда вы смотрите на код, вы можете легко увидеть, что является декларативным, а что императивным.

То, что есть сейчас, на мой взгляд, довольно декларативно.

Я не понимаю, как DSX также не выигрывает от обновлений Dart, поскольку это надмножество Dart.
Усилия по обеспечению безопасности типов в DSX равны нулю, потому что DSX — это всего лишь крошечный слой синтаксического сахара поверх Dart, поэтому он использует систему типов Dart точно так же, как использует управляющие операторы Dart и т. д.

Честные баллы. Но DSX по-прежнему нужно поддерживать и улучшать, что по-прежнему требует усилий, которые я хотел бы видеть сосредоточенными на других, более важных/отсутствующих аспектах экосистемы.

Еще один аспект обсуждения, с которым я не согласен, — это постоянное сравнение с React. Я понимаю его актуальность, но я не хочу, чтобы Flutter был копией React без моста JS и изменения имени компонентов на виджеты. Если то же самое, то зачем менять? Это не означает, что Flutter должен стараться быть как можно дальше от React. У флаттера должна быть своя индивидуальность. Я предпочитаю, чтобы культура предоставления решений во Flutter была проактивной, а не реактивной. Мы должны использовать React только как контрастную точку, а не как ориентир.

Насколько я понимаю, если какой-либо разработчик решил не разрабатывать во Flutter из-за отсутствия поддержки DSX/JSX, то этот человек вообще не хотел присоединяться к Flutter.

Еще один аспект обсуждения, с которым я не согласен, — это постоянное сравнение с React. Я понимаю его актуальность, но я не хочу, чтобы Flutter был копией React без моста JS и изменения имени компонентов на виджеты. Если то же самое, то зачем менять?

Потому что у React есть пробелы, которые Flutter может заполнить, а затем вы создаете что-то, что лучше, чем React, потому что он исправляет недостатки React с производительностью Dart и графикой с ускорением GPU, сохраняя при этом лучшие части React, а также его знакомство.

Насколько я понимаю, если какой-либо разработчик решил не разрабатывать во Flutter из-за отсутствия поддержки DSX/JSX, то этот человек вообще не хотел присоединяться к Flutter.

Это не имеет значения, конечным результатом является то, что если мобильные разработчики, использующие кроссплатформенные инструменты, не присоединятся к Flutter, Flutter потерпит неудачу на рынке. Поэтому Flutter необходимо привлекать разработчиков React Native для своего выживания.

Говоря об эволюции, это не «выживание наиболее приспособленных», а «выживание наиболее приспособленных». Адаптируйся или погибнешь.

@cbazza

Это не имеет значения, конечным результатом является то, что если мобильные разработчики, использующие кроссплатформенные инструменты, не присоединятся к Flutter, Flutter потерпит неудачу на рынке.

Какой? Зачем это нужно? Flutter может сформировать свою собственную нишу, пока находится в стадии бета-тестирования (что он и сделал очень успешно), а затем органично расти без необходимости привлекать мотыльков с внешне похожими характеристиками. Кроме того, что вы подразумеваете под "неудачным"? Flutter не обязательно должен быть популярным, чтобы добиться успеха.

@naiveaiguy
Послушайте, я знаю, что вы заминусовали ответы cbazza.
Но не могли бы вы потратить 15 секунд, чтобы посмотреть на это, прежде чем минусовать мой ответ?

Прежде чем думать о DSX.
Просто взгляните ниже, это всего лишь JSX.

После того, как вы создали навигационную панель и тело, вы можете просто импортировать навигационный штрих-код из своего навигационного штрих-кода.

import XXXXX, { Component } from 'XXXXX';
import { Text, View } from 'XXXXX-native';
import navbar from "your code1"
import body from "your code2"

class SomethingFast extends Component {
  render() {
    return (
      <View>
        <navbar
            style={{width: 360, height:90}}
         />
        <Image
          source={{uri: 'https://google.com/dsx.jpg/'}}
          style={{width: 320, height:180}}
        />
        <body/>
        <Text>
          Look at <strong i="11">@escamoteur</strong> s code from above.
           Can you export part of UI code to another place,
           separate it into different modules, and read everything in few seconds or less?
        </Text>
      </View>
    );
  }
}

       I think cbazza is right.
       If flutter uses DSX or whatever that is JSX,
       it is a perfect UI framework.

       So, could we have something
       similar or better in the future?
       Or do you really think that the
       current is fine?

Возможно, кто-то ненавидит JSX, потому что он от Facebook, но на самом деле это от небольшой японской игровой компании.

Создав приложения с React Native и Flutter, я чувствую, что в текущем состоянии JSX легче читать и настраивать, чем чисто вложенные классы Dart.
Однако, как упоминалось ранее, у Facebook была причина использовать JSX из-за того, как написан JavaScript (например, нет именованных параметров конструктора), чего нельзя сказать о Dart. Кроме того, добавленная безопасность типов Dart действительно хороша!
Так что, если Flutter в конечном итоге будет придерживаться чистого синтаксиса Dart, я надеюсь увидеть улучшения с подсветкой синтаксиса и автоматическим форматированием. Новые комментарии закрывающего тега уже являются большим улучшением, но этого недостаточно для достижения производительности JSX.

@JonathanSum Вы объясняете идею многократно используемых компонентов. Вам не нужен JSX для создания повторно используемых компонентов. Я думаю, что можно было бы сделать что-то лучше, изменив синтаксис Dart, но DSX вообще не лучший способ сделать это.

@hartmannj Мы всегда ищем улучшения синтаксиса Dart, средства выделения и форматирования, которые помогут повысить производительность. Для любых конкретных идей или предложений по таким улучшениям, о которых вы или другие могли подумать, мне было бы очень любопытно узнать больше.

ИМХО, устранение необходимости использовать new/const уже очень помогло. У меня есть реальные трудности в том, как формат дротика форматирует деревья. он недостаточно подчеркивает древовидную структуру ИМХО по сравнению с:

    return Scaffold(
      appBar: AppBar(title: Text("WeatherDemo")),
      resizeToAvoidBottomPadding: false,
      body: 
        Column(children: <Widget>
        [
          Padding(
            padding: const EdgeInsets.all(16.0),
            child: 
            TextField(
                    key: AppKeys.textField,
                    autocorrect: false,
                    controller: _controller,
                    decoration: InputDecoration(hintText: "Filter cities",),
                    style:  TextStyle(fontSize: 20.0,),
                    onChanged: ModelProvider.of(context).textChangedCommand,
                    ),
          ),

https://reactjs.org/docs/introduction-jsx.html

React не требует использования JSX, но большинство людей считают его полезным в качестве наглядного пособия при работе с пользовательским интерфейсом внутри кода JavaScript. Это также позволяет React отображать более полезные сообщения об ошибках и предупреждения.

Когда так много разработчиков стремятся использовать JSX-подобный подход для создания пользовательского интерфейса, это означает, что способ необходим, и его нельзя игнорировать.

@woodstream Люди, которые хотят использовать JSX, уже являются фанатами React. Они уже используют React Native. Flutter предназначен для совсем другого типа разработчиков.

РЕДАКТИРОВАТЬ : я признаю, что мое использование fanboy здесь было неправильным.

@naiveaiguy , @Хикси

Те люди, которые хотят использовать JSX, уже являются фанатами React. Они уже используют React Native. Flutter предназначен для совсем другого типа разработчиков.

Вы ошибаетесь, и ваши комментарии, вызывающие разногласия («Реакция фанатов» и «другой тип разработчиков») нежелательны. JSX/DSX имеет технические достоинства, и другие предпочитают его. Эта ветка предназначена для обсуждения, если вам что-то не нравится, отпишитесь от нее. Также прекратите голосовать против каждого моего комментария, это просто не сулит вам ничего хорошего.

Я просто предлагаю предложить разработчикам два способа выбрать, какой им нравится, а кому-то нравится ставить палец вниз перед разными мнениями? Технологии должны быть открытыми и инклюзивными, а не играть в закрытом сообществе.

@anders-sandholm Я согласен с @escamoteur по поводу необходимости улучшить видимость дерева виджетов. Я бы сделал его пример следующим образом:

return
      Scaffold(
          appBar: AppBar(title: Text("WeatherDemo")),
          resizeToAvoidBottomPadding: false,
          body:
        Column(children: <Widget> [
          Padding(
              padding: const EdgeInsets.all(16.0),
              child:
            TextField(
                key: AppKeys.textField,
                autocorrect: false,
                controller: _controller,
                decoration: InputDecoration(hintText: "Filter cities",),
                style:  TextStyle(fontSize: 20.0,),
                onChanged: ModelProvider.of(context).textChangedCommand,
            ),
          ),
        ])
      );

Кроме того, я мог представить выделение имен классов виджетов другим цветом, стилем шрифта или жирностью, чтобы они сразу были еще более узнаваемыми.

@cbazza

Навешивание ярлыков? Я не имел в виду, что эти люди были негативными, просто они были другими. Мне нравится эта тема, но обвинять меня в недобросовестности немного иронично.

Слово «фанат» обычно считается уничижительным, и в этом контексте оно также было воспринято. Я рекомендую избегать подобных слов в дискуссиях здесь.

Пожалуйста, все, будьте вежливы и конструктивны. Мы обсуждаем здесь стиль , что-то очень субъективное, поэтому, как бы каждому ни нравились его собственные предпочтения, вряд ли они по своей сути превосходят предпочтения всех остальных. Перечислите преимущества и недостатки существующих и предлагаемых синтаксисов, но помните, что не все видят его одинаково, и это совершенно нормально.

@hartmannj

Только небольшие уточнения...

Однако, как упоминалось ранее, у Facebook была причина использовать JSX из-за того, как написан JavaScript (например, нет именованных параметров конструктора), чего нельзя сказать о Dart.

На самом деле, начиная с ES2015/ES6, в JS есть именованные параметры; вы можете просто использовать для этого «деструктурирование» :)
Вот пример:

// function declaration
function findUsersByRole ({
  role,
  withContactInfo, 
  includeInactive
}) {
  if (role === 'admin' && withContactInfo) {
  ...
  }
...
}


// usage
findUsersByRole({
  role: 'admin', 
  withContactInfo: true, 
  includeInactive: true
})

https://medium.freecodecamp.org/элегантные-шаблоны-в-современном-javascript-роро-be01e7669cbd

Кроме того, добавленная безопасность типов Dart действительно хороша!

Вы получаете ту же безопасность типов с DSX, что действительно приятно.

Поскольку это дубликат https://github.com/flutter/flutter/issues/11609 , о котором сообщалось ранее, я закрою его в пользу того.

я действительно не понимаю, как люди могут голосовать против этого - что-то, что является второй натурой того, как декларативный код написан в эпоху Интернета.

<like><this /></like>

пожалуйста, будьте достаточно гибкими, чтобы дать флаттеру возможность летать!

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

нам не нужно делать это как реагировать на нативный или html, просто используйте простой xml

и, может быть, XML, встроенный в дротик! ;П

Во вторник, 28 августа 2018 г., в 21:29, Touseef [email protected] написал:

нам не нужно делать это как реагировать на нативный или html, просто используйте простой xml

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/flutter/flutter/issues/15922#issuecomment-416550338 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AC8aNdVb_NV8c8JH4t36OS1OOvX6kY58ks5uVSmjgaJpZM4S6HPa
.

--
Тони Полинелли

Для меня JSX-подобная функциональность — это будущее, и она станет стандартной конструкцией для декларативных фреймворков, таких как React, Vue и Flutter.

нам не нужно встраивать xml в dart, если у нас может быть только 2 отдельных файла для пользовательского интерфейса и логики, тогда мы можем легко следовать mvvm, mvc или любому другому желаемому шаблону.

Я говорил это в другой теме, но:

Если вам действительно нужен JSX, хорошим стартером будет использование генерации кода. Используйте файл .html или .xml и создавайте виджеты из них.

Очевидно, что это не полноценный JSX, но начало положено. Достаточно посмотреть, как на это отреагирует сообщество.
Если этот синтаксис наберет обороты, возможно, команда Flutter пересмотрит эту тему.

В противном случае, я думаю, это просто потеря времени. Отсюда ясно видно, что это очень обсуждаемая тема.

Если флаттер представит и xml / jsx / назовите его как хотите, способ создания пользовательского интерфейса, я бы начал использовать его для приложений производственного уровня в одно мгновение!

Я согласен с @leossmith , что это единственное препятствие для приложений производственного уровня.

Лично я предпочел бы _не_ добавлять JSX или внешний язык разметки. Я предпочитаю хранить все на одном языке с проверкой типов. Я считаю, что лучший подход — продолжать совершенствовать язык Dart с целью кодирования глубоко вложенных декларативных деревьев пользовательского интерфейса. Они уже добавили несколько приятных функций в этой области:

• Помогает сделать ключевые слова new и const необязательными.
• Виртуальные закрывающие теги в IDE
• dartfmt тоже помогает

Я предпочитаю хранить все на одном языке с проверкой типов.

Это именно то, что делает DSX/JSX, язык Dart для DSX, Javascript для JSX!!!

Я считаю, что лучший подход — продолжать совершенствовать язык Dart с целью кодирования глубоко вложенных декларативных деревьев пользовательского интерфейса.

DSX — это усовершенствование языка Dart для лучшей поддержки глубоко вложенных декларативных деревьев. Так же, как JSX для Javascript.

https://facebook.github.io/jsx/

Цель этой спецификации — определить краткий и знакомый синтаксис для определения древовидных структур с атрибутами.

@cbazza Вы подняли хороший вопрос. JSX — это просто улучшение JavaScript.

Итак, сначала давайте четко разделим две вещи:

1. Внешний DSL для определения пользовательского интерфейса. Я 100% против этого. Я всегда считал, что это создает больше проблем, чем решает. Я написал сообщение в блоге, аргументируя этот момент. У него 58 тысяч просмотров и, что удивительно, почти нет особых мнений: 80% моего кода делает это (или почему шаблоны мертвы)
2. Улучшения языка. Чтобы упростить создание и визуализацию глубоко вложенных древовидных структур пользовательского интерфейса. В этом мы оба согласны, что есть возможности для улучшения.

Но мы немного отличаемся в подходе. Есть две причины, по которым JSX лучше подходит для React:

1. Структура данных: в Интернете JSX точно соответствует генерируемой вещи (узлы HTML DOM). Во флаттере мы генерируем экземпляры Widget.
2. Знакомство: люди привыкли смотреть на html-код. Но предложение DSX отличается от JSX/XML ровно настолько, чтобы сделать этот пункт недействительным.

Ниже приведены две вещи (я считаю), которые делают XML хорошим (и удобочитаемым) для построения деревьев пользовательского интерфейса. Вопрос в том, можно ли этого добиться без внедрения XML в язык:

1. XML имеет конечные теги. Это возможно с синтаксисом xml или без него. В Visual Basic это было в 90-х (вспомните End If). И в других языках есть. В среде IDE предусмотрены «виртуальные конечные теги», но это схематично. Я бы предпочел языковую поддержку.
2. XML имеет особое отношение к дочерним элементам. Атрибуты отличаются от детей. Но я бы сказал, что это палка о двух концах. В некоторых случаях Dart на самом деле более четкий и выразительный, чем XML в этом отношении. Например, виджеты-контейнеры с разными дочерними моделями контента:

MyWidgetA(children: [ w1, w2 ])
MyWidgetB(child: w1)
MyWidgetC(top: w1, bottom: w2)

Dave Предложение по проблеме с конечным тегом

ButtonsView(
        onDeal: onDeal,
        onHit: onHit,
        onStay: onStay,
)ButtonsView

Это было бы легко прочитать людям. И синтаксический анализатор просто заменит )ButtonsView на ) . Кроме того, среда IDE могла бы обеспечить лучшую проверку и помощь в этой схеме. Я бы сделал это обязательным в любое время, когда открытые и закрытые скобки не находятся на одной строке.

Dave Предложение по проблеме вложенных детей

Некоторые языки (например, kotlin) допускают специальную обработку аргументов типа лямбда. Они позволяют вам поместить лямбда-аргумент вне скобок. См. Передача лямбды в последний параметр .

Я предлагаю нечто подобное для Dart, но в качестве аргумента типа List, а не для лямбда-выражений. Я предлагаю специальный синтаксис для передачи аргумента списка типов с именем «дети»:

```
//вместо этого:
Foo(a:1, b:10,c:44, дети:[...])

// делаем так:
Фу(а:1,б:10,в:44)[

]

Для конструкторов/функций, которые берут одного дочернего элемента или двух дочерних элементов (например, сверху и снизу), оставьте все как есть, без изменений.

Я предпочитаю хранить все на одном языке с проверкой типов.

Это именно то, что делает DSX/JSX, язык Dart для DSX, Javascript для JSX!!!

Я считаю, что лучший подход — продолжать совершенствовать язык Dart с целью кодирования глубоко вложенных декларативных деревьев пользовательского интерфейса.

DSX — это усовершенствование языка Dart для лучшей поддержки глубоко вложенных декларативных деревьев. Так же, как JSX для Javascript.

https://facebook.github.io/jsx/

Цель этой спецификации — определить краткий и знакомый синтаксис для определения древовидных структур с атрибутами.

@StokeMasterJack - ваше предложение по проблеме с конечным тегом звучит так же, как и мое предложение некоторое время назад.
Идея: Автоматически генерируемые закрывающие теги

Я думаю, что флаттеру нужно что-то вроде этого. В большинстве случаев я изо всех сил пытаюсь вставить новые виджеты в глубокое гнездо. Я бы использовал синтаксис, подобный JSX, только для того, чтобы получить обозначение конечного тега.

Я не хочу писать закрывающие теги. Это боль в JSX/html/xml. Особенно, когда я хочу провести рефакторинг.
Я думаю, что виртуальные закрывающие теги довольно изящны. Это кажется хорошим компромиссом между обоими мирами.

Если нам действительно нужны какие-то улучшения, я думаю, мы можем продолжить изучение со стороны IDE. Например, vscode предоставляет следующую панель:

(Почти уверен, что Android Studio имеет то же самое)

Вместо того, чтобы останавливаться на сфокусированном методе, мы могли бы также добавить вложенность конструкторов.
Чтобы при наведении на конкретный класс мы получали следующий UI:

lib > main.dart > Foo > build > Container > Center > Text 

Если речь идет о визуальном отделении виджетов от другого контента, IDE тоже может сделать это снова.

У нас может быть другая подсветка синтаксиса для виджетов. Вместо обычного цвета, используемого для классов, мы можем иметь определенный цвет для подкласса виджета.

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

Существует довольно много вариантов рефакторинга, в том числе:

• Завернуть в новый виджет
• Удалить виджет
• Поменять виджет с ребенком
• Поменять виджет с родителем

Имея это в виду, вам больше не нужно иметь дело со скобками.

Честно говоря, я тратил часы ежедневно, играя с Flutter в течение нескольких месяцев. И я не чувствовал никакой неудобочитаемости или дискомфорта при написании вложенных виджетов.
Хотя для сравнения, я использовал React столько же, и есть некоторые вещи, которые меня расстраивают.

@rrousselGit — те варианты рефакторинга, которые у вас есть, кажутся полезными. Я не вижу их в Android Studio 3.2.
Я думал, что Android Studio предоставит лучшие возможности для разработки Flutter.

@Рокволе

Вот скриншот из Android Studio:

Активировано как быстрое исправление Option+Enter (macOS).
Я использую их все время, супер полезно.

По теме: кажется, что команда Flutter изучает варианты «UI как код», и рано или поздно мы можем получить больше улучшений в этом направлении. Хотя идеи @StokeMasterJack звучат интересно.

@Rockvole Великие умы думают одинаково!

@StokeMasterJack

Хороший ответ!!!

Есть две причины, по которым JSX лучше подходит для React:

1. Структура данных: в Интернете JSX точно соответствует генерируемой вещи (узлы HTML DOM). Во флаттере мы генерируем экземпляры Widget.

Сила JSX не в создании узлов HTML/DOM, а в управлении иерархиями компонентов; React Native не имеет узлов HTML/DOM, верно?

1. Знакомство: люди привыкли смотреть на html-код. Но предложение DSX отличается от JSX/XML ровно настолько, чтобы сделать этот пункт недействительным.

Как и выше, речь идет не о HTML-коде, а о синтаксисе, который четко отделяется от императивных конструкций основного языка и кричит о декларативной разметке для построения древовидных иерархий .

Я не поклонник вашего предложения или предложения Котлина, потому что оно выглядит как хак, сделанный для того, чтобы избежать надлежащего дизайна. Вместо того, чтобы разрабатывать DSL, который выглядит отлично, теперь я должен смотреть на код и пытаться понять, что он делает; Синтаксис выглядит неоднозначно. Есть преимущества в разделении императивных и декларативных конструкций; Сторонние инструменты могут легко найти XML-разметку, например, внутри кода.

@Рокволе

Я бы использовал синтаксис, подобный JSX, только для того, чтобы получить обозначение конечного тега.

Хорошо знать ;)

@rrousselGit

Я не хочу писать закрывающие теги.

Вам не нужно; WebStorm, например, автоматически генерирует закрывающий тег и даже переименовывает открывающий или закрывающий теги, когда вы редактируете другой. Действительно отличная функциональность редактора, которой должны следовать другие (смотря на ваш «VS Code»).

Честно говоря, я тратил часы ежедневно, играя с Flutter в течение нескольких месяцев. И я не чувствовал недостатка в читабельности или какого-либо дискомфорта при написании вложенных виджетов.

Я надеюсь, вы понимаете, что ваш опыт не отражает опыт других людей. С инструментами писать не так больно, как читать код. Зайдите на github, чтобы прочитать чужой код, и вы заметите, что чтение — это боль, код слишком многословный и длинный с вложенными структурами. Похоже, когда перед асинхронностью/ожиданием использовались цепочки промисов, они показали лучший способ. Также кажется, что декларативные методы менее важны, чем императивные; Я имею в виду, почему нет конструкций декларативной векторной графики? вместо этого я должен использовать императивные вызовы Skia, например, для рисования векторной графики.

Вам не нужно; WebStorm, например, автоматически генерирует

Vscode тоже так делает. Но это еще не идеально. Особенно на этапе рефакторинга при перемещении вещей.
Я думаю, что виртуальные теги обеспечивают гораздо более плавный опыт.

Я надеюсь, вы понимаете, что ваш опыт не отражает чужой опыт.

Для уверенности ! Я просто хотел указать, что это может быть скорее неопытность с инструментами, чем фактическое отсутствие 😄

Зайдите на github, чтобы прочитать чужой код, и вы заметите, что чтение — это боль, [...]

Я не совсем понимаю, как ваши аргументы здесь связаны с темой.
Проблема, которую вы перечислили, связана с плохой практикой, а не с синтаксисом. Это не вина Flutter, если люди хотят создать дерево виджетов длиной 500 штук.

@pulyaevskiy - спасибо за полезный совет, в Linux быстрое решение - Alt-Enter. Не очень легко обнаружить эту функцию, я обыскал верхние пункты меню, но, кажется, нигде, кроме как по волшебному нажатию клавиши :)

Я думаю, что виртуальные теги обеспечивают гораздо более плавный опыт.

Отображаются ли эти виртуальные теги, например, в исходном файле в github?

Я не совсем понимаю, как ваши аргументы здесь связаны с темой.

По сути, язык может предоставлять конструкции, чтобы сделать вещи менее подробными, как я упоминал в примере промисов и асинхронных/ожидающих. Конструкторы Flutter Widget огромны и часто принимают множество параметров; с DSX вы можете использовать оператор распространения , например, для сжатия конструктора из 10 строк в конструктор из 1 строки, и, следовательно, вы все еще можете видеть полную древовидную иерархию с меньшим количеством шума вокруг нее. Это упрощает чтение кода и позволяет, например, четко отделить стиль от древовидной структуры. Я не говорю, что это невозможно сделать, реструктурировав ваш код Dart, но это можно сделать без особых усилий или реструктуризации. Вам не нужно подстраиваться под ограничения языка, язык подстраивается под вас.

Проблема, которую вы перечислили, связана с плохой практикой, а не с синтаксисом.

До появления async/await лучшими практиками было повсеместное использование промисов вместо сумасшедших обратных вызовов событий. Использование промисов вызывает проблемы с читаемостью, которые были решены с помощью async/await. Это в основном то же самое, просто синтаксический сахар, но async/await понятнее при чтении чужого кода.

Это ужасный пример @woodstream

Обновление : Просто чтобы выразить свою точку зрения, а не просто избивать слова без каких-либо аргументов. Эквивалент DSX такой же длинный... Это не имеет ничего общего с количеством строк или HTML.

class MusicImage extends StatelessWidget {

  TextStyle titleTextStyle = TextStyle(
    fontWeight: FontWeight.w800,
    letterSpacing: 0.5,
    fontSize: 20.0
  );

  Container titleText = (
    <Container height={116.0} padding={EdgeInsets.all(10.0)}>
      <Text style={titleTextStyle}>title</Text>
    </Container>
  );

  TextStyle authorTextStyle = TextStyle(
    fontWeight: FontWeight.w800,
    letterSpacing: 0.5,
    fontSize: 10.0,
  );

  Container music = (
    <Container
      height={40.0}
      decoration={BoxDecoration(
        color: Colors.white,
        borderRadius: BorderRadius.all(Radius.circular(8.0))
      )}
      padding={EdgeInsets.fromLTRB(0.0, 5.0, 5.0, 0.0)}
      margin={EdgeInsets.fromLTRB(8.0, 0.0, 8.0, 0.0)}
    >
      <Stack>
        <Row>
          <Container
            height={30.0}
            width={30.0}
            decoration={BoxDecoration(
              borderRadius: BorderRadius.all(Radius.circular(8.0))
            )}
            margin={EdgeInsets.fromLTRB(5.0, 0.0, 5.0, 0.0)}
          >
            {Image.asset('images/bg2.jpg')}
          </Container>
          <Column>
            <Text>music</Text>
            <Text style={authorTextStyle}>author</Text>
          </Column>
        </Row> 
        <Align alignment={FractionalOffset.centerRight}>
          <Icon icon={Icons.play_arrow} />
        </Align>
      </Stack>
    </Container>
  )

  <strong i="9">@override</strong>
  Widget build(BuildContext context) {
    return (
      <Container
        height={168.0}
        margin={EdgeInsets.fromLTRB(16.0, 8.0, 16.0, 8.0)}
        decoration={BoxDecoration(
          borderRadius: BorderRadius.all(Radius.circular(8.0)),
          image: DecorationImage(
            image: new AssetImage('images/bg.jpg'),
            fit: BoxFit.cover,
          ),
        )}
      >
        {titleText}
        {music}
      </Container>
    );
  }
}

Как разработчик React, я думаю, что сообществу необходимо предоставить эту функцию самим, и когда разработчики начнут ее адаптировать и использовать; тогда основные участники будут вынуждены также адаптировать его изначально. Я разработчик React, и у меня много проблем, связанных с тем, как пользовательский интерфейс написан на флаттере, я бы хотел перейти на флаттер, но синтаксис не помогает, я бы даже исследовал, как реализовать синтаксис, подобный JSX. себя, как уже было сказано: «Приятно иметь возможность».

Я думаю, что одна из основных причин, по которой люди выступают против этого, заключается в том, что они не могут представить, что они его используют. Правда в том, что вам действительно не нужно, точно так же, как люди используют (по сравнению с реакцией) React.createElement(Component, {}, null) , а не <Component /> Если это будет реализовано, это побудит людей использовать Flutter в первую очередь. место, и это то, что мы действительно хотим. Большое сообщество, посвященное Flutter при поддержке друг друга. Если это не тот синтаксис, который вы бы использовали, ну ладно. Но тонны предпочли бы нотацию, подобную JSX, а не текущий метод.

Лично я считаю, что SGML и его производные просто уродливы. Если мы делаем DSL, почему бы не с синтаксисом, подобным QML?

Я также думаю, что некоторые из точек зрения pro-DSX объединяют функции Javascript как языка (которых Dart как язык не имеет) и функции JSX как DSL. Например,

По сути, язык может предоставлять конструкции, чтобы сделать вещи менее подробными, как я упоминал в примере промисов и асинхронных/ожидающих. Конструкторы Flutter Widget огромны и часто принимают множество параметров; с DSX вы можете использовать оператор распространения , например, для сжатия конструктора из 10 строк в конструктор из 1 строки, и, следовательно, вы все еще можете видеть полную древовидную иерархию с меньшим количеством шума вокруг нее.

Это не та функция, которую DSX волшебным образом предоставила бы, это функция JSX, потому что она есть в Javascript. Dart как язык может получить оператор распространения (довольно маловероятно, IMO), и в этом случае вы сможете использовать его с конструкторами и другими вызовами функций без необходимости использования специального DSL. Это также функция, которая работает в основном потому, что объекты, хэш-карты и массивы Javascript — это, по сути, одно и то же, что совершенно определенно не относится к Dart и почти наверняка никогда не изменится.

И это, я думаю, является проблемой, с которой сталкиваются многие люди против предложения, даже если оно не озвучено — это, по сути, просьба, чтобы Dart вел себя (или притворялся, что ведет себя) как Javascript, и хотя есть некоторые плюсы, факт в том, что это просто разные языки, которые все больше и больше расходятся с первых дней Dart 1.

Редактировать: Это не означает, что DSL для разметки/моделирования для пользовательского интерфейса — это совсем плохая идея. Честно говоря, нет, но я думаю, что вдохновение для этого должно исходить от языков/фреймворков, которые немного больше похожи на Dart/Flutter (в парадигме набора текста, а также в других семантических деталях — я не говорю о простом синтаксисе), чем Javascript. является.

Dart как язык может получить оператора распространения (довольно маловероятно, IMO)

На самом деле распространение для коллекций уже определено и готово к реализации, см. Коллекции распространения и всю «Языковую воронку» для получения дополнительной информации о будущих функциях языка Dart.

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

(Я смутно знаю об этом предложении, но последнее, что я проверил, вы не можете просто распространять Dart Size(10, 10) так, как вы можете распространять/уничтожать Javascript Size { width: 10, height: 10 } или распространять список /map аргументов в обычный вызов функции (без использования Function.apply , что пожертвовало бы безопасностью типов))

@filleduchaos

Лично я считаю, что SGML и его производные просто уродливы. Если мы делаем DSL, почему бы не с синтаксисом, подобным QML?

Потому что многие люди, в отличие от вас, не считают это уродливым и предпочитают его. Вам не нужно иметь много видения, чтобы увидеть всех энтузиастов React-разработчиков.

JSX/DSX вносит разметку в базовый язык Javascript/Dart таким образом, чтобы улучшить базовый язык и включить все конструкции языка программирования в разметке. Очень простая и мощная штука.

Это не та функция, которую DSX волшебным образом предоставила бы, это функция JSX, потому что она есть в Javascript.

Совсем не так; DSX может реализовать распространение самостоятельно, для его поддержки не требуется Dart. Было бы неплохо, если бы это было так, но не требование. В этом прелесть переноса с более высокого языка на Dart, более высокий язык не должен ограничиваться Dart.

Мой прототип онлайн-транспилятора DSX отлично обрабатывает оператора распространения , проверьте это:
https://spark-heroku-dsx.herokuapp.com/index.html

И это, я думаю, является проблемой, с которой сталкиваются многие люди против предложения, даже если оно не озвучено — это, по сути, просьба, чтобы Dart вел себя (или притворялся, что ведет себя) как Javascript, и хотя есть некоторые плюсы, факт в том, что это просто разные языки, которые все больше и больше расходятся с первых дней Dart 1.

Перестаньте думать о том, что такое Dart в настоящее время, и сосредоточьтесь на том, каким он мог бы быть, взяв лучшие идеи из всех других существующих языков.

Я думаю, что вдохновение для этого должно исходить от языков / фреймворков, которые немного больше похожи на Dart / Flutter (в парадигме набора текста, а также в других семантических деталях — я не говорю о простом синтаксисе), чем Javascript.

Typescript набирается и поддерживает JSX. Самая близкая к Flutter среда пользовательского интерфейса — это React, и угадайте, что React взлетел благодаря JSX. Пожалуйста, придумайте что-нибудь лучше, чем JSX/DSX, и если вы это сделаете, люди перестанут спрашивать о JSX/DSX, но я не видел ничего, что я считаю лучше, поэтому сейчас JSX — это современное состояние. .

Однако приятно видеть, что разработчики языка Dart берут лучшие идеи из других языков, таких как Python (понимание списков и словарей).

@cbazza

Потому что многие люди, в отличие от вас, не считают это уродливым и предпочитают его.

Наоборот. Почему именно этот синтаксис, а не какой-либо другой, особенно если он не имеет прочной связи с языком? (С Android SDK у Java и XML были отношения в течение многих лет. То же самое с Javascript и HTML, который сильно напоминает JSX. DSX, как было предложено, принесет синтаксис SGML, основанный на том, что он имеет смысл для других языков, но не обязательно для _Dart_).

JSX/DSX вносит разметку в базовый язык Javascript/Dart таким образом, чтобы улучшить базовый язык и включить все конструкции языка программирования в разметке. Очень простая и мощная штука.

Совсем не так; DSX может реализовать распространение самостоятельно, для его поддержки не требуется Dart. Было бы неплохо, если бы это было так, но не требование. В этом прелесть переноса с более высокого языка на Dart, более высокий язык не должен ограничиваться Dart.

Довольно интересно посмотреть на эти два утверждения в сопоставлении, потому что они просто доказывают мою точку зрения. JSX великолепен (для Javascript) именно из-за своей простоты - это просто сахар по сравнению с тем, что уже является языковыми конструкциями JS, он сам не реализует никакой специальной семантики. Вы справедливо восхваляете эту простоту, а затем продолжаете говорить, что DSX должен реализовывать семантику сам по себе, независимо от целевого языка, по-видимому, не осознавая, 1) сколько еще работы требуется, и 2) как это полностью лишает смысла быть простой, но мощный DSL.

Мой прототип онлайн-транспилятора DSX отлично обрабатывает оператора распространения , проверьте это:
https://spark-heroku-dsx.herokuapp.com/index.html

Я уже видел ваш транспилятор, и хотя его работа впечатляет, он никоим образом не приближается к обработке оператора распространения так, как это делает Javascript как язык (и, следовательно, JSX) по умолчанию. Как уже упоминалось, распространение (и, в конечном счете, деструктурирование) коллекций не сильно противоречит Dart и фактически находится в процессе реализации. Распространение и деструктурирование любого объекта (что, в отличие от JS, не то же самое, что Карты) — это, и ваш транспилятор, похоже, тоже не справляется с этим (и на самом деле требует помещения аргументов в Карты, что довольно однообразно). и непригодный для использования Dart (например, с ним нельзя взаимодействовать достаточно безопасным способом)).

Перестаньте думать о том, что такое Dart в настоящее время, и сосредоточьтесь на том, каким он мог бы быть, взяв лучшие идеи из всех других существующих языков.

Конечно. Но из языков, с которых Dart можно было бы поднять, лично JS не очень высок в списке — я честно думаю, что попытки быть слишком похожими на JS (ради интероперабельности) искалечили Dart в его первые дни.

Конечно, я бы хотел UI DSL. Но этот DSL должен быть идиоматичным для _Dart_, а не заимствован полностью из семантически другого языка только из-за популярности.

И я также хотел бы, чтобы люди перестали путать то, что делает Javascript, с тем, что делает JSX DSL, потому что некоторые из упомянутых преимуществ на самом деле являются замаскированными запросами функций на уровне языка. Чтобы продолжить с оператором распространения, если Dart как язык действительно поддерживает весь диапазон оператора, как в JS, то я не вижу, почему return <SomeWidget {...someArgs, arg: newValue } />; предпочтительнее читать, чем return SomeWidget(...someArgs, arg: newValue); или QML-подобный return SomeWidget { ...someArgs, arg: newValue }; , если кто-то не привязан к SGML.

@filleduchaos

Почему именно этот синтаксис, а не какой-либо другой, особенно если он не имеет прочной связи с языком? (С Android SDK у Java и XML были отношения в течение многих лет. То же самое с Javascript и HTML, который сильно напоминает JSX. DSX, как было предложено, принесет синтаксис SGML, основанный на том, что он имеет смысл для других языков, но не обязательно для Dart).

Перестаньте объединять вещи, которые, по вашему мнению, идут вместе (и создайте отношения), и сосредоточьтесь на выборе лучших идей, независимо от того, откуда они взялись. Вы как бы искусственно разделяете вещи, когда в этом нет необходимости.

Я выбираю синтаксис JSX, потому что он хорошо зарекомендовал себя в React, и это то, чего ожидают и хотят люди React. Этот билет именно об этом, если это не для вас, не используйте его.

Довольно интересно посмотреть на эти два утверждения в сопоставлении, потому что они просто доказывают мою точку зрения. JSX великолепен (для Javascript) именно из-за своей простоты - это просто сахар по сравнению с тем, что уже является языковыми конструкциями JS, он сам не реализует никакой специальной семантики. Вы справедливо восхваляете эту простоту, а затем продолжаете говорить, что DSX должен реализовывать семантику сам по себе, независимо от целевого языка, по-видимому, не осознавая, 1) сколько еще работы требуется, и 2) как это полностью лишает смысла быть простой, но мощный DSL.

Реализует ли он новую семантику или нет, это не имеет значения. Простота исходит от его использования. Если его легко использовать пользователям/разработчикам, они будут его использовать. Пользователей/разработчиков не волнует, насколько что-то сложно внутри (или сколько работы нужно было сделать), их просто волнует, насколько это упрощает их жизнь и улучшает их код.

Я уже видел ваш транспилятор, и хотя его работа впечатляет, он никоим образом не приближается к обработке оператора распространения так, как это делает Javascript как язык (и, следовательно, JSX) по умолчанию.

Мое намерение с распространением на DSX состояло в том, чтобы просто распространять атрибуты, а не полную реализацию распространения JS. Он отлично работает для того, что он есть, и у него нет проблем с типобезопасностью. Проверка/корректность типов происходит, когда Dart компилирует то, что генерирует DSX.

искалечил Dart в первые дни его существования.

То, что портило Dart в первые дни, заключалось в том, что он не обеспечивал простой совместимости с JS, чтобы текущие библиотеки JS можно было легко использовать с кодом Dart (и наоборот). Кроме того, это та же самая причина, по которой Typescript преуспел там, где Dart потерпел неудачу.

Конечно, я бы хотел UI DSL. Но этот DSL должен быть идиоматичен для Dart, а не полностью взят из семантически другого языка только из-за популярности.

Популярность диктует все. Лучшие идеи являются лучшими идеями, потому что они становятся популярными, потому что многие люди ценят их преимущества.

И я также хотел бы, чтобы люди перестали путать то, что делает Javascript, с тем, что делает JSX DSL, потому что некоторые из упомянутых преимуществ на самом деле являются замаскированными запросами функций на уровне языка.

Опять же это не актуально.

Что нам действительно нужно от людей из Google (Dart/Flutter), так это общая поддержка транспиляции через исходные карты, чтобы можно было разработать любой язык более высокого уровня, ориентированный на Dart/Flutter, и он отлично работал бы с текущими инструментами (IDE, отладчик и т. д.) . Выровняйте игровое поле, и вы гарантируете, что лучшие идеи придут на платформу от других.

@cbazza

Я выбираю синтаксис JSX, потому что он хорошо зарекомендовал себя в React, и это то, чего ожидают и хотят люди React. Этот билет именно об этом, если это не для вас, не используйте его.

Это кажется мне довольно спорным и имеет право на существование. Почему Flutter должен иметь первоклассную поддержку именно синтаксиса React? Почему не файлы компонентов Vue или синтаксис Xamarin.Forms? Почему (предположительно официальный) UI DSL для Flutter должен основываться на том, чего ожидает и хочет одна конкретная группа людей, использующих другую структуру на другом языке? Если вам нужен инструмент сообщества специально для разработчиков React/JS, это одно. Но просить, чтобы сам фреймворк включал его исключительно для того, чтобы удовлетворить всех вас, - это слишком много ИМО.

Реализует ли он новую семантику или нет, это не имеет значения. Простота исходит от его использования. Если его легко использовать пользователям/разработчикам, они будут его использовать. Пользователей/разработчиков не волнует, насколько что-то сложно внутри (или сколько работы нужно было сделать), их просто волнует, насколько это упрощает их жизнь и улучшает их код.

На мой взгляд, это такая странная форма права. И нет, разработчики будут заботиться о том, насколько сложна реализация, когда она начнет вызывать проблемы и дрейф функций, как это обычно бывает со сложностью абстракций. Разработчики, которые хотят сделать больше, чем просто использовать DSL — например, расширить его, — определенно будут заботиться о том, насколько сложной является реализация. Разработчики, которые должны будут создавать и поддерживать его, также заслуживают внимания.

Мое намерение с распространением на DSX состояло в том, чтобы просто распространять атрибуты, а не полную реализацию распространения JS. Он отлично работает для того, что он есть, и у него нет проблем с типобезопасностью. Проверка/корректность типов происходит, когда Dart компилирует то, что генерирует DSX.

У него «нет проблем с безопасностью типов», только если вы вообще об этом не думаете. Я сказал, что карты аргументов не могут быть _используемыми_ полностью безопасным образом с остальной частью кодовой базы Dart, где, по-видимому, вы захотите взаимодействовать с этими аргументами так же, как с реквизитами и тому подобным в JavaScript - передавать их из другого Виджет, импортировать их из другого модуля и т. д., а не просто объявлять их в одном месте, и в этом случае какой смысл в обычном вызове конструктора?

Чтобы проиллюстрировать, что я имею в виду, вы можете сделать это в JS:

class MyCustomSize {
  constructor(length, width, height) {
    this.length = length;
    this.width = width;
    this.height = height;
    this.calculateVolume.bind(this);
  }

  calculateVolume() {
    return this.length * this.width * this.height;
  }
}

const Cuboid = ({ length, width, height }) => { // blah blah }

const literalSize = { 'length': 30, 'width': 20, 'height': 10 };
const size = new MyCustomSize(30, 20, 10);

size.length = 100; // Can interact with the object as normal, no compromises
console.log(size.getVolume()); // and even call methods
size.foo = 50 // If you're using TypeScript, you get a nice error
literalSize.height = 15 // can interact with the hashmap as though it were an object

const SomeComponent = () => (
  <div>
    <Cuboid {...literalSize} />{/* valid */}
    <Cuboid {...size} />{/* also valid even though size is an object */}
  </div>
)

Но с Dart и вашим транспилятором, для которого требуются хэш-карты аргументов:

class MyCustomSize {
  int length, width, height;

  MyCustomSize(this.length, this.width, this.height);

  calculateVolume() {
    return length * width * height;
  }
}

class Cuboid extends StatelessWidget {
  final int length, width, height;

  Cuboid(this.length, this.width, this.height);

  <strong i="9">@override</strong>
  Widget build(BuildContext context) { // blah }
}

Map literalSize = { 'length': 30, 'width': 20, 'height': 10 };
Map invalidSize = { 'length': 300, 'width': 200, 'height': 100 };
final size = MyCustomSize(30, 20, 10);

literalSize.height = 15; // Invalid, you must use square bracket notation which is honestly ugly to do a lot of the time
invalidSize['foo'] = 50; // No indication of anything wrong here

class SomeWidget extends StatelessWidget {
  <strong i="10">@override</strong>
  Widget build(BuildContext context) {
    return (
      <Column>
        <Cuboid {...literalSize} />{/* Yes, works */}
        <Cuboid {...invalidSize} />{/* Sure the transpiled code errors as there is no parameter named foo. But this is now a completely opaque error. What if the `foo:50` key-value pair was added in some other section of your codebase? In a third party library even? How do you debug that*/}
        <Cuboid {...size} />{/* How do you plan on handling this as a plain transpilation step? */}
      </Column>
    )
  }
}

То, что портило Dart в первые дни, заключалось в том, что он не обеспечивал простой совместимости с JS, чтобы текущие библиотеки JS можно было легко использовать с кодом Dart (и наоборот). Кроме того, это та же самая причина, по которой Typescript преуспел там, где Dart потерпел неудачу.

Взаимодействие Dart с JS никогда не было сложным, если только (и это я постоянно подчеркиваю) вы просто не хотите продолжать писать Javascript и не желаете изучать что-либо еще. Typescript, являющийся надмножеством, не столько работает с JS, сколько просто является JS, до такой степени, что намеренно имеет ненадежную систему типов только для обслуживания JS (а также нет времени выполнения для фактического обеспечения его выразительной системы типов, которая является чертовски стыдно, что много лет спустя). Но вернемся к моей точке зрения: лично я считаю, что Dart принял несколько плохих дизайнерских решений ради JS, и Dart 2 действительно должен был стать первой итерацией языка.

Популярность диктует все. Лучшие идеи являются лучшими идеями, потому что они становятся популярными, потому что многие люди ценят их преимущества.

«Лучшие» или, скорее, хорошие идеи — это хорошие идеи, потому что они достойны . Иногда они становятся популярными, иногда нет. Иногда плохие идеи становятся популярными, иногда нет. Предполагать, что популярность является прямым показателем заслуг, откровенно абсурдно, и лично я бы очень не хотел распространяться на сообщество Dart, каким бы маленьким оно ни было.

Что нам действительно нужно от людей из Google (Dart/Flutter), так это общая поддержка транспиляции через исходные карты, чтобы можно было разработать любой язык более высокого уровня, ориентированный на Dart/Flutter, и он отлично работал бы с текущими инструментами (IDE, отладчик и т. д.) . Выровняйте игровое поле, и вы гарантируете, что лучшие идеи придут на платформу от других.

...Я не думал, что можно стать еще более достойным, чем ты был раньше, и все же мы здесь. Почему именно этот UI SDK должен быть доступен для всех языков высокого уровня в мире? И снова предложение сильно, сильно звучит как «Сделайте Dart/Flutter в моем языке/фреймворке» — вы можете просто выйти и сказать, что хотите создавать приложения Flutter с помощью Javascript. И да, еще больше жира на локте, и я был бы полностью готов внести свой вклад в такой общественный проект, но, откровенно говоря, смешно ожидать положительного ответа, если вы запрашиваете официальную поддержку для этого.

Еще раз повторяю - я не против UI DSL и мне бы очень понравился. Но если мы просим команду запечь его, то это должен быть DSL, идиоматический для Dart. Потому что да, здесь есть целые десятки людей, которым на самом деле нравится Dart как язык.

Еще одно редактирование: одно дело запросить DSL, предложить JSX в качестве возможного вдохновения синтаксиса/синтаксиса и быть открытым для других предложений. Меня (и я подозреваю многих, кто комментировал) неправильно настаивает на DSX .

@filleduchaos

Вы весело сбиты с толку, и у меня еще не так много времени, чтобы тратить его впустую.

Единственное, о чем я прошу команду Dart/Flutter, это то, что я сказал ранее:

What we really need from Google (Dart/Flutter) people is generic transpiling support via source maps so that any higher level language can be developed that targets Dart/Flutter and it would work just fine with the current tools (IDE, debugger, etc). Level the playing field and you guarantee the best ideas will come to the platform from others.

Это обеспечивает все необходимое для реализации DSX, файлов компонентов Vue, Xamarin.Forms, NativeScript, QML и т. д. и, следовательно, позволит сообществу придумывать все, что они хотят, и никому не нужно «брать» мой DSX. Не нравится DSX, вы можете использовать простой Dart или легко создать что-то свое.

Я бы сказал, что вы ищете такие вещи, как https://github.com/dart-lang/build и dartanalyzer.
Вы, вероятно, пропустите часть или две (например, возможность создавать плагины-анализаторы в зависимости от паба), но я почти уверен, что команда Dart не против помочь с этим.

В любом случае, я не думаю, что постоянная резкость по отношению друг к другу поможет прогрессу фреймворка.
Максимум, что мы вынесем из этого, — это еще одна навсегда закрытая проблема, потому что она «слишком нагрелась».

@filleduchaos

Что касается вашего примера «foo», распространение DSX — это вещь времени компиляции, поэтому карта должна быть определена как const , иначе я мог бы придумать что-нибудь еще, что я хотел, чтобы это происходило во время компиляции (например, создать новое ключевое слово DSX или аннотацию для него, за которой следует карта const). Это должно быть во время компиляции, а не во время выполнения, потому что Dart не поддерживает динамическую вставку параметров конструктора во время выполнения. Не проблема, потому что это решает проблему, которую я хотел решить, то есть распространение атрибутов на конструкторы.

@cbazza Дело в том, что часть того, что делает оператор распространения таким удобным в JS / JSX, заключается в том, что вам не нужно накладывать ограничения, такие как «вы можете использовать только хэш-карту» или «все ваши аргументы должны быть известны во время компиляции» или «вы не можете взаимодействовать с аргументами/реквизитами, которые вы хотите передать виджету, так же, как вы можете взаимодействовать со всем остальным» (обратите внимание, что вы не предложили ничего для обработки случая, когда вещь со свойствами, которые вы need на самом деле является объектом, а не литералом карты) -0 все хорошо и хорошо, когда это простой пример, но такого рода вещи будут чрезвычайно раздражать _fast_ в любом проекте среднего размера. Я имею в виду, в какой момент можно перестать нагромождать обходные пути, компромиссы и аннотации, сделать шаг назад и задаться вопросом, действительно ли расширение подходит для существующего языка?

JSX был таким успешным (по сравнению с большинством шаблонов), потому что он не заставляет вас программировать определенным образом (или, скорее, не заставляет вас писать код иначе, чем в Javascript). Практически совершенно безболезненно использовать _любой_ JavaScript; это то, что я имею в виду, создавая DSL, который действительно соответствует языку. То же самое и с Redux. Redux в кодовой базе JS — это красиво (при правильном использовании); с другой стороны, все примеры Flutter, которые я видел с использованием Redux, честно говоря, выглядят болезненно по сравнению с использованием Streams/шаблона BLoC. Это не значит, что нет вещей, которые бы совпадали с большим успехом: React Context и Flutter InheritedWidget реализуют общую концепцию, которая невероятно хорошо сочетается с сильными сторонами обоих. Я просто не уверен, что JSX в настоящее время является одной из таких вещей - за исключением нескольких изменений на уровне языка, честно говоря, похоже, что DSX было бы больно разрабатывать _и_ больно использовать для чего-то большего, чем тривиальные примеры, тогда как, вероятно, можно было бы написать полнофункциональный преобразователь JSX с нуля в ленивые выходные из-за того, насколько просто сопоставить его с JS.

Также я был немного агрессивен ранее, и я извиняюсь.

@filleduchaos

Я не пытаюсь создать полностью универсальный оператор распространения , который работает везде и для всего, даже тот, который запланирован для будущего Dart, не является таким же универсальным, как оператор JS. То, что я хочу, чтобы распространение обрабатывало в контексте DSX, отлично справляется. Например, DSX не нуждается в распределении объектов.

Коллекции распространения
https://github.com/dart-lang/language/issues/47

Я разрабатывал очень большие проекты с JSX, и мне действительно никогда не приходилось использовать распространение атрибутов тега. JSX прекрасно работает и без него. Причина, по которой я добавил DSX, заключается в том, что он решает проблему для виджетов Flutter, для которой нет простого решения, в частности, если виджет принимает 20 параметров в конструкторе, как вы можете написать это менее чем в 20 непрерывных строках, которые сделают виджет дерево пирамида гибели. Единственная особенность распространения DSX состоит в том, чтобы позволить убрать некоторые из этих строк из дерева и поместить их в другое место.

@cbazaa Я оцениваю, использовать ли React Native или Flutter. Склоняюсь к Flutter, потому что все это просто Dart, чтобы компилятор мог проверить мои опечатки в пользовательском интерфейсе. Также см.: https://medium.com/flutter-io/out-of-depth-with-flutter-f683c29305a8

Обнаруживает ли JSX и мои опечатки? Я использую TypeScript.

Я ненавижу HTML / отдельные разметки. Например, в Angular, если я что-то неправильно набрал/переменные в HTML, я нахожу свои ошибки только после рендеринга страницы.

@sivabudh

Обнаруживает ли JSX и мои опечатки? Я использую TypeScript.

Да, некоторые опечатки JSX обнаруживаются во время компиляции (например, имя компонента), но не имена свойств (которые будут обнаружены во время выполнения) при использовании JS/ES6; но поскольку вы используете TypeScript, система типов улавливает все опечатки JSX во время компиляции:
https://www.typescriptlang.org/docs/handbook/jsx.html

@cbazza — это dsx с открытым исходным кодом?

@pushqrdx
Пока нет, я не опубликовал его исходный код.

Как потребитель React + TypeScript и Flutter могу предложить себя в качестве тестировщика. Ваше здоровье

Будет ли у нас исходный код dsx? Будет очень здорово!

Я приветствую усилия cbazza, но я не буду использовать DSX во Flutter. Тем не менее, рад испытать это.

Проблема № 27141 отслеживает добавление поддержки генерации кода в систему сборки. Это будет сделано через https://github.com/dart-lang/build с Builder . Теоретически должно быть довольно просто подключить компилятор/транспилятор dsx, когда эта функция будет готова.

После двух выпусков я впервые встретил такую ​​упорную команду.

Это не обсуждение JSX, а обсуждение вложенного ада

Даже если вы не можете дать JSX-решение, вы должны сделать вложенность меньше, а код — более читабельным.

Я думаю, что преимущество JSX очевидно, но команда флаттера пытается его игнорировать.

JSX не решает проблему вложенности. React сталкивается с той же проблемой

Если вам не нравится такая вложенность, вы можете взглянуть на хуки , которые являются портом хуков React, которые сами по себе являются попыткой решить ад вложенности.

Я думаю, мы должны выяснить, почему JSX появился на свет. Это потому, что функция h/createElement плохо написана, а код плохо читаем. Неожиданно флаттер теперь написан в 10 000 раз хуже, чем функция h/createElement , что видно глазами

JSX появился, потому что React по своей сути представляет собой смесь Javascript и HTML. Синтаксис XML с интерполяцией/внедрением Javascript естественным образом создает JSX.

Flutter полностью отделен от Javascript и HTML, поэтому он плохо переводится в JSX. Я согласен с тем, что проекты Flutter часто очень вложены, и это может быть настоящей болью, особенно когда dartfmt разбивает эти сильно вложенные строки. Ужасный.

Я также хотел бы отметить, что я чувствовал, что Flutter был ужасно структурирован, когда я был новичком в нем, пришедшим из React, но Flutter объективно намного легче работать, когда вы прошли начальную кривую обучения. Кривая обучения не уникальна для Flutter, она распространена при изучении новых фреймворков. Flutter особенно сложен, потому что у него нет причин вести себя как синтаксис HTML, с которым знакомы многие люди.

Я думаю, что есть способы решить проблему вложенности, и JSX не является решением.

Некоторые идеи:

1. Разработайте внутреннее руководство по стилю, которое требует, чтобы люди разбивали массивные деревья флаттера на более мелкие компоненты.

2. Получите dartfmt , чтобы официально признать, что Flutter имеет уникальный набор потребностей в форматировании по сравнению с пакетами Dart, и поработайте с командой Flutter/Dart, чтобы найти разумное решение. @мужественный

3. Используйте генерацию кода, например пакет @rrousselGit @stateless , чтобы упростить разработчикам задачу номер 1.

Честно говоря, проблема вложенности возникает в основном, когда мы не хотим рефракторить наш код.

Виджеты созданы для того, чтобы их можно было разбить на множество более мелких частей.
Использование и злоупотребление инструментом рефакторинга extract widget .

Это делает код намного более читабельным, уменьшает избыточность и, возможно, даже исправляет ошибки/увеличивает производительность.

Хотя я по большей части согласен, виджеты Flutter настолько высокого уровня, что я видел, как многие люди делают целые представления в одном виджете, потому что... он действительно работает очень хорошо, и вам не нужно передавать реквизиты через 4-5 уровни виджетов. Что вы теряете в процессе, так это то, что вы получаете этот ужасный вложенный код, который dartfmt разбивается во что-то неузнаваемое. Итак, я понимаю, почему люди это делают, я понимаю, что есть решение, но я также понимаю, почему люди не используют это решение.

JSX появился, потому что React по своей сути представляет собой смесь Javascript и HTML. Синтаксис XML с интерполяцией/внедрением Javascript естественным образом создает JSX.

Как вы объясните тот факт, что React Native использует JSX и не имеет ничего общего с HTML?

Как вы объясните тот факт, что React Native использует JSX и не имеет ничего общего с HTML?

Потому что он использует React. Вероятно, они не хотели заново изобретать синтаксис

Потому что он использует React. Вероятно, они не хотели заново изобретать синтаксис

Таким образом, JSX на самом деле не является смешением Javascript и HTML, как утверждает @lukepighetti , а скорее XML-like syntax extension to ECMAScript without any defined semantics... who's purpose is to define a concise and familiar syntax for defining tree structures with attributes.
Все это прописано в спецификации: https://facebook.github.io/jsx/

Насколько я понимаю, React впервые был выпущен как react + react-dom с компилятором jsx , поэтому смесь HTML + JavaScript была естественной. После этого react использовался для управления другими средствами визуализации, такими как react-native , react-vr , react-pdf и т. д. и т. д. Так что я по-прежнему придерживаюсь своего первоначального утверждения как разумным и чутким к истории и родословной React. Спецификация 2019 года — это спецификация 2019 года, которая не касается истории React.

я согласен

Но для меня есть большая проблема. Vue и React работают одинаково в этом аспекте.
У React есть функция createElement , а у Vue есть функция h .

Мы никогда не создаем экземпляры компонентов вручную как в React, так и в Vue. Это структура, которая заботится об этом.

Флаттер ведет себя иначе. Мы напрямую манипулируем экземпляром виджета.

Таким образом, в мире Flutter <Foo /> просто означает new Foo()

Но в этом случае JSX совершенно не связан с виджетами. Мы просто меняем синтаксис создания экземпляров классов в dart.

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

@лукепигетти
react-pdf — это не еще один рендерер реагирования, вы, должно быть, думаете о react-canvas .
Итак, react != react-dom != react-native . Пакет react отвечает за управление иерархиями компонентов с помощью JSX , поэтому react не волнует, генерирует ли он react-dom , react-native , react-canvas , поэтому react на самом деле не относится к HTML.

Спецификация 2019 года — это спецификация 2019 года, которая не касается истории React.

Не существует такой вещи, как спецификация JSX 2019 года. Существует только одна версия JSX, и это оригинальная версия, опубликованная в 2014 году по предоставленной мной ссылке (https://facebook.github.io/jsx/).

@rrousselGit

Мы просто меняем синтаксис создания экземпляров классов в dart.

В случае DSX с Flutter это именно то, что делает транспилятор.

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

Как вы можете что-то потерять, если ничего не удалено, вы просто получаете другой способ сделать что-то (с преимуществами и недостатками), и теперь у вас есть свобода выбора, выберите тот, который лучше всего подходит вам.

Привет, я полагаю, что вы можете неправильно понять мое сообщение. react управляет другими рендерерами реагирования, такими как react-dom , react-native , react-pdf , react-vr и т. д. Афаик, react и react-dom были выпущены одновременно, так что наследие jsx , на мой взгляд, вполне очевидно. Надеюсь, вы не копаетесь в моем сообщении, потому что у нас разные мнения о ценности JSX в контексте Flutter. Наверное, лучше было бы придерживаться темы, а не мудрить.

Привет, lukepighetti, вы использовали React Native с JSX в течение одного-двух месяцев? Если это так, вы должны понимать, почему создание приложения с помощью JSX И реагировать на нативный (или реагировать, я знаю, что они разные) стиль фреймворка прост и хорошо структурирован.
Однако, если вы не использовали его какое-то время, вы никогда не поймете, почему JSX так полезен и важен.

Я все еще надеюсь, что Google сможет понять красоту JSX, и у нас было много людей, поддерживающих его. Команда Google может однажды подумать о DSX или JSX для фреймворка, вдохновленного React, флаттер.

Привет, lukepighetti, вы использовали React Native с JSX в течение одного-двух месяцев? Если это так, вы должны понимать, почему создание приложения с JSX И нативным стилем React (или React, я знаю, что они разные) являются простыми и хорошо структурированными.

Я не могу говорить за lukepighetti, но я профессионально работаю с React уже два года, а сейчас занимаюсь Vue. Так что я довольно хорошо разбираюсь в JSX.

Точно так же я использую Flutter уже около 2 лет. Сначала я тоже думал, что Flutter нужен какой-то JSX.
Но за это время Flutter значительно улучшился, и я передумал.

• JSX ужасно писать вручную. Чтобы сделать его приемлемым, требуется много инструментов, включая автоматическое закрытие тегов, автоматическое переименование тегов и emmet. И даже тогда он далеко не так прост, как синтаксис Flutter.

Например, легко преобразовать Foo() в Foo(child: Bar()) .
Но рефакторинг <Foo /> в <Foo><Bar /></Foo> — нет.

• Flutter предлагает множество вариантов рефакторинга, которые еще больше упрощают работу со скобками.

• Виртуальные закрывающие теги, которые предлагает Flutter, компенсируют отсутствие закрывающих тегов.
  _Но они не отображаются в код-ревью!_
  Они на самом деле делают! Вы можете делать код-ревью из вашей IDE. См. https://code.visualstudio.com/blogs/2018/09/10/introduction-github-pullrequests .

  • JSX плохо подходит для модели Flutter.

Что, если виджет принимает как child , так и children ? Получаем ли мы:

<Foo
  child={<Bar />}
>
  <Bar />
</Foo>

?

В этом случае это означает, что в целях согласованности child всегда следует рассматривать как именованный аргумент, а не использовать слот children .

Дело в том, что очень немногие виджеты требуют children . Подавляющее большинство — это либо один child , либо комбинация настраиваемых именованных параметров (например, Scaffold ).

Это означает, что подавляющее большинство виджетов, использующих JSX, будут выглядеть так:

<Container
  child={<Bar />}
/>

Что _хуже_ тогда:

Container(
  child: Bar(),
)

Подводя итог, я думаю, что Flutter в порядке. И даже если бы JSX был доступен, я сомневаюсь, что это действительно улучшило бы ситуацию.

Как я уже сказал, upthread я думаю, что есть много путаницы между тем, что на самом деле является JS/ECMAScript/общими веб-функциями (распределение объектов, деструктуризация, взаимозаменяемость объектов/хэш-карт, все узлы DOM* имеют очень похожий интерфейс, гибкость HTML в общие и т. д.) с тем, что функции JSX. Бывшие IMO — это то, что делает JSX приятным для написания. Без них вы просто пишете XML, а большинство моих знакомых, у которых действительно есть выбор, не любят писать XML.

*Стоит отметить, что это, прежде всего, является моим главным противодействием попыткам переделать Flutter в XML. Я не думаю, что есть какой-то реальный смысл пытаться отрицать, что JSX/React имеет глубокие корни в Интернете, а элементы DOM имеют давний стандарт каждого узла, имеющего _attributes_ и _children_. С другой стороны, Flutter не обязывает разработчиков называть слот пользовательского виджета для других виджетов children или даже child , и я не вижу причин, по которым он должен начать это делать.

Я понимаю, почему другой поток JSX был заблокирован. Я не должен защищать свои навыки/опыт в комментариях GitHub, объясняя, почему я думаю, что JSX не приносит пользу Flutter. Я мог бы легко сказать: «У вас недостаточно опыта работы с Flutter, чтобы иметь какое-либо мнение о Flutter». Нехорошо, не так ли. Вам понравится ваше племя клавишных воинов.

Что, если виджет принимает как child , так и children ? Получаем ли мы:

Почему виджет должен иметь как child , так и children ? Это либо то, либо это。
Другая тема，Некоторые виджеты Flutter используют children , а другие используют child , никто не думает, что это сложно и легко спутать？ children содержит child , так что нет независимо от того, сколько у вас child , один или несколько, просто используйте children , чтобы выполнить работу.

@rrousselGit

JSX ужасно писать вручную. Требуется много инструментов, чтобы сделать это терпимым,

С вами не согласен не только весь мир React, но и весь мир HTML и мир XML.

Flutter предлагает множество вариантов рефакторинга, которые еще больше упрощают работу со скобками.

Итак, вы говорите, что Flutter «требует много инструментов», но, поскольку вы предвзяты, вы чувствуете необходимость разгромить другую сторону. К вашему сведению: лучше всего принять тот факт, что существует более одного способа сделать что-то и что некоторые люди предпочтут другой способ сделать это.

Они на самом деле делают! Вы можете делать код-ревью из вашей IDE.

Это не решает проблему для всех других онлайн-инструментов проверки кода, используемых командами. Эти инструменты манипулируют исходным кодом, и если его нет в исходном коде, его не существует.

JSX плохо подходит для модели Flutter.

Это просто ваше плохое мнение, любой может видеть, что DSX добавляет улучшения в JSX, которые идеально подходят для Flutter.
https://spark-heroku-dsx.herokuapp.com/index.html

Итак, вы говорите, что Flutter «требует много инструментов»

Нет, я сказал "еще легче", а не "терпимо".

Я часто отвечаю на StackOverflow/Slack, а иногда даже с телефона.
И у меня явно плохое время, когда я отвечаю на вопрос, связанный с html, но с Flutter все в порядке.

Лучшее, что можно сделать, — это признать, что существует более одного способа сделать что-то и что некоторые люди предпочтут другой способ сделать это.

Это работает наоборот. Вы должны ясно видеть, что сообщество не на 100% фанаты JSX. Количество отрицательных голосов как по этому вопросу, так и по предыдущему доказывает это.

Это просто ваше плохое мнение, любой может видеть, что DSX добавляет улучшения в JSX, которые идеально подходят для Flutter.

Я не согласен. Синтаксис содержит множество сложных символов, доступ к которым на многих раскладках клавиатуры затруднен.
Он также содержит тонны повторений.

В любом случае, я не понимаю, почему ты постоянно такой агрессивный. Мы все пытаемся сделать Flutter лучше.
Нет смысла быть резким и снова закрывать дискуссию.

Если JSX плохо работает во флаттере, я могу согласиться не присоединяться к JSX, но нам следует подумать о вложенном аду.

Еще одна побочная история — точка с запятой в языке дартс. Это действительно раздражает.

Еще одна побочная история — точка с запятой в языке дартс. Это действительно раздражает.

На dart-lang/language есть запрос на это: https://github.com/dart-lang/language/issues/69 .
Иди ставь 👍

Это длинное обсуждение касается возможности использовать это:

<A property="a">
  <B/>
  <C/>
</A>

Вместо этого:

A(property: a, children: [
   B(), 
   C()
])

Даже если кто-то согласится с тем, что прежний синтаксис лучше, чего я лично не делаю, это сопряжено с постоянными затратами на обслуживание, более высокой сложностью и новыми возможными источниками ошибок не только в языке/фреймворке, но и в окружающих инструментах, таких как IDE, отладчик, линтер и т. д. Это также увеличивает время сборки. И это требует от разработчиков изучения нового синтаксиса и изучения внутренностей транспилятора, чтобы понять, когда и как создаются экземпляры. Все это в значительной степени с единственной целью React & co. разработчики чувствуют себя как дома.

Прежде чем приступить к новым языкам, я бы лучше сосредоточился на улучшении Dart, который далек от идеала, в нем отсутствуют важные функции, такие как сопоставление с образцом , классы данных , ADT , деструктуризация , правильные опции и т. д. Некоторые из этих PR открыты уже 5+. годы. Это, в отличие от добавления косметического и ненужного слоя разметки для создания виджетов, оказывает огромное влияние на архитектуру, безопасность и общее качество кода.

Даже если это отнесено к разряду «управляемых сообществом», сообщество все равно может потратить время на работу над чем-то значимым. Но, конечно, каждый может делать со своим временем то, что он хочет. Просто перестаньте оказывать такое непропорциональное давление на команду Flutter, пожалуйста.

https://twitter.com/mattly/status/1109464147782074373
https://twitter.com/orta/status/1109467814862172160

Эй, я-Шютц.
есть раздел ответов.

Об этом я и говорил в этом длинном посте. JSX исправил «проблему спагетти HTML и XML» (нечитаемый и сложный код пользовательского интерфейса). По моему личному мнению, после использования флаттера это сложнее, чем JSX или хуже.

В эти годы я видел, как люди говорили, что Flutter не может использовать некоторые преимущества React, например, истинная идея всего — это компоненты.

Не уверен, что следую. В выделенном вами тексте пользователь говорит, что JSX ему легче изучить, потому что он знаком с HTML и имеет похожий синтаксис. Я не понимаю, как это оправдывает существование JSX и тем более имитации Flutter.

Я не стал добавлять ответы на скриншоты просто потому, что изображения заняли бы слишком много места. Они казались довольно благосклонными к тому, что я опубликовал, а также излишним. Я разместил ссылки.

@JonathanSum Flutter сложнее, чем JSX, или Flutter отличается от _React_, и это вызывает у вас трения? В некоторых случаях это более многословно, да, и, возможно, менее читабельно без виртуальных закрывающих тегов в IDE, но я не совсем уверен, почему использование конструкторов более _сложно_, чем написание XML-подобного DSL, и я все еще не совсем уверен почему так много людей, кажется, думают, что XML-подобный DSL будет серебряной пулей, которая упростит использование Flutter для _понятия_. Особенно с учетом того, что у Flutter нет предшествующей истории с проблемами, для решения которых был создан React/JSX — React делает манипуляции с DOM проще и чище, и это хорошо, но какое конкретно это имеет отношение к Flutter?

В эти годы я видел, как люди говорили, что Flutter не может использовать некоторые преимущества React, например, истинная идея всего — это компоненты.

Не касаясь идеи о том, что у React есть некоторая «истинная» идея о том, что все является компонентами, которых нет у Flutter, есть также некоторые преимущества дизайна Flutter/Dart, которые React/JS не могут захватить. И вы можете сказать то же самое (и наоборот) для большинства приличных UI SDK/фреймворков/библиотек. Невероятно, но разные проекты на самом деле разные; возможно, люди, приходящие на один проект, будут лучше обслуживаться, если они не начнут ожидать, что это будет [вставьте проект, который они использовали в прошлом]. 🙂

Есть несколько интересных идей https://github.com/munificent/ui-as-code

Скорее всего, это было бы довольно серьезным изменением, но предложение о свободе параметров заставило меня задуматься о том, насколько более краткими могли бы быть методы сборки, если бы Dart имел, например , спецификацию аргументов метода Crystal .

Конечно, компилятор Crystal будет последним в гонке со слизняком и черепахой, так что вот что 😅

Теперь я согласен не добавлять JSX и не оказывать лишнего давления на флаттер.

Но что касается dart, он гораздо менее элегантен, чем JS или TS. я чувствую себя беспомощным

Например, путь разработки технологии пользовательского интерфейса Microsoft — от WinForm к WPF, а теперь и во Flutter — отказаться от WPF и вместо этого использовать WinForm. В ответ на жалобы разработчиков команда Flutter усердно работала над реализацией визуального окна WinForm и редактора свойств.

Как новичок во флаттере, я должен сказать, что это должно быть в дорожной карте. Если не jsx, то более удобочитаемый способ размещения виджетов.

Я вижу функцию рендеринга класса реакции, а также изображение визуализированного класса и ассоциации в данный момент.

Я вижу файл дротика и визуализированный контент, и мне потребуется 5-6 минут, чтобы понять, как это работает...

Я могу сделать полусложный класс реагирования за 5 минут в обычном текстовом редакторе, потому что он интуитивно понятен.

Я не могу сделать это в трепете. Без автозаполнения я закончил как разработчик. Мне не нравится зависеть от расширения для разработки чего-либо -.-

Однако. Будет интересно, как разработчики дротиков справятся с этой «проблемой». В Dart 2 сделали его более читабельным. Я не знаю, как они собираются улучшить читаемость дротика 3-4-5. но я думаю, что рано или поздно потребуется рефакторинг функции сборки компонентов.

РЕДАКТИРОВАТЬ:
Неважно, только что снова попробовал React Native, и я ненавидел jsx, систему реквизита, тот факт, что все было динамическим, снова был действительно страшной концепцией, я думаю, тогда это просто личное мнение. Оставь флаттер как есть....

Они запросили DSX не только потому, что любят JSX. Им нужен Флаттер.

Объявление пользовательского интерфейса должно быть визуально отделено в коде для лучшей читабельности и поддержки кода. Особенно в больших командах с большим количеством юниоров/средних. Исходя из Adobe Flex, я могу сказать, что чтение объявлений пользовательского интерфейса Flutter сильно снижает производительность.
Если не DSX (что было бы здорово, IMO), но что-то нужно сделать с текущей ситуацией, по крайней мере, на уровне IDE.
Все прежние фреймворки для разработки пользовательского интерфейса имели эту функцию, и она должна быть и у нас.

Объявление пользовательского интерфейса должно быть визуально отделено в коде для лучшей читабельности и поддержки кода.

и для лучшей интеграции с другими инструментами, такими как, например, «конструкторы графического интерфейса».

Исходя из Adobe Flex, я могу сказать, что чтение объявлений пользовательского интерфейса Flutter сильно снижает производительность.

Представьте объявление пользовательского интерфейса, такое как MXML, с мощью Flutters! Я могу только мечтать!

Теперь, когда у нас есть поддержка codegen, лучший способ внедрить что-то подобное в продукт — создать пакет, который активирует это и покажет, что он очень популярен.

@Hixie , есть ли какой-нибудь указатель на документ для codegen?

Теперь, когда у нас есть поддержка codegen, лучший способ внедрить что-то подобное в продукт — создать пакет, который активирует это и покажет, что он очень популярен.

Мне кажется, что codegen предназначен только для .dart -> .dart, входной файл должен быть действительным файлом .dart. Это не очень полезно для файлов .dsx, поскольку это надмножество dart. Мне все еще нужна поддержка кросс-компиляции в .dart с исходными картами, такими как функции для отладки и т. д.

Пожалуйста, взгляните на SwiftUI, который был выпущен вчера. Кажется, это то, к чему должен стремиться Flutter, а не разметка, подобная React.

Одни только неявные выражения члена Swift были бы такими удивительными

Я не согласен с синтаксисом SwiftUI. Это конечно легко, но некоторые аспекты выглядят волшебно.

Но технически у нас уже может быть что-то относительно похожее:

Column(mainAxisSize: MainAxisSize.min)([
  if (foo) Text('foo'),
  Text('bar'),
]);

Это действительный код дротика, где Column — это _все еще_ класс.

Вот виджет без сохранения состояния, демонстрирующий это:

class Foo extends StatelessWidget {
  const Foo({Key key}) : this._(key: key);
  const Foo._({Key key, this.children}) : super(key: key);

  final List<Widget> children;

  <strong i="12">@override</strong>
  Widget build(BuildContext context) {
    return Column(children: children);
  }

  Foo call(List<Widget> children) {
    return Foo._(key: key, children: children);
  }
}

Это шаблонно, но генератор кода может помочь, особенно с будущими членами расширения.

Единственная проблема с этим подходом заключается в том, что мы теряем конструкторы const (поскольку он использует функцию для указания дочерних элементов) и создаем экземпляр класса виджета _twice_.

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

@rrousselGit Мне любопытно, какие аспекты SwiftUI кажутся вам волшебными - мне это кажется довольно простым расширением синтаксиса Swift.

На их примере кода отсюда :

• Content можно изменить? Означает ли это, что у них есть встроенный магазин Mobx/Vue?
• Что это за @State ?
• Почему body является переменной? Это геттер? Если да, то когда геттер вызывается снова?
• является body частью интерфейса или множеством подобных переменных внутри Content ?
• Что делает эта item in _exactly_? Почему правый операнд in является не чем-то итерируемым, а «результатом»?
• Почему Image выровнено по левому краю заголовка/подзаголовка, когда HStack нет?

Я не могу точно вспомнить, но я почти уверен, что у меня не было таких вопросов, когда я брал Flutter.

@rrousselGit Это может быть из-за вашего фона, а не из-за того, что синтаксис или семантика Flutter очевидны по своей сути (я встречал множество людей, которые были весьма озадачены этим). И вопросы, которые вы подняли, кажутся странным соединением чрезмерного анализа 14-строчного фрагмента кода на наличие ошибок, фактически не зная языка, на котором он написан.

• Это не совсем изменчиво (в смысле Dart или JS)? Это структура. Кроме того, хранилища в стиле MobX/Vue (т. е. прикрытие довольно ограниченной языковой поддержки) — не единственный способ справиться с изменчивостью.

• @State — это атрибут, также известный как аннотация в некоторых языках (например, Dart), иначе известный как очень распространенная вещь в коде Swift. Если вы имеете в виду то, что он делает, даже не глядя на документы, он, скорее всего, помечает свойство как состояние, которое будет меняться со временем.

• body — это вычисляемое свойство, очевидное для разработчиков Swift. Что касается того, когда он пересчитывается, Widget build(BuildContext context) также по своей сути сообщает вам, когда он вызывается снова?

• Content (опять же совершенно ясно для разработчиков Swift) расширяет/реализует View , где вы будете искать ответы на свой вопрос (на самом деле у него очень хорошая справочная страница API).

• Это в значительной степени «почему ключевое слово в этом языке не то же самое, что ключевое слово в языке, который я использую», а не что-то особенно «волшебное». Ключевое слово in здесь — это не то же самое, что конструкция for...in — оно указывает, что тело замыкания вот-вот начнется. { item in ... } — это функциональный блок, передаваемый конструктору List ; ListView itemBuilder , если хотите.

• Вы законно спрашиваете, почему представление имеет свои собственные инкапсулированные правила компоновки?

В SwiftUI:

1-Приятно видеть состояние, объявленное в представлении, а не как побочный придаток.

2-Хорошие отдельные методы для установки вещей вместо того, чтобы передавать все в конструктор (методы позволяют действовать действиям, а не просто передавать данные).

3-Очень приятно видеть декларативную векторную графику, смешанную со всем остальным, что является декларативным (как я предлагал в прошлом с декларативным SVG, таким как виджеты) !!!
https://developer.apple.com/tutorials/swiftui/рисование-пути-и-формы

4-Очень простая анимация и конструкции перехода
https://developer.apple.com/tutorials/swiftui/animating-views-and-transitions

5-Drag&Drop инструменты дизайна, синхронизированные с редактором кода в обоих направлениях.

Есть бородавки, как и все остальное, но я скорее сосредоточусь на том, что они сделали очень хорошо.

Эти «вопросы» существуют только для того, чтобы продемонстрировать потенциально запутанные моменты. Это не _фактические вопросы_.

Это может быть из-за вашего фона

Скорее всего. Я не говорю, что их подход плохой или что-то в этом роде. Я говорю, что это не казалось мне естественным, как с Flutter.
Виджеты Flutter почти не используют «причудливую языковую функцию» и могут быть реализованы практически на любых языках (хотя недавние if/for для коллекций меняют это).
В то время как их демонстрация SwiftUI широко использует специфические функции Swift.

Что касается того, когда он пересчитывается, сборка виджета (контекст BuildContext) также по своей сути сообщает вам, когда он вызывается снова?

Моя точка зрения здесь заключается в отсутствии связи между State и актом пересчета body .
React и Flutter очень четко говорят об этом: setState.
Vue/Mobx «волшебные», использующие ту же функцию @State .

Это действительно хорошо, но это другая модель.

Вы законно спрашиваете, почему представление имеет свои собственные инкапсулированные правила компоновки?

Нет, это скорее «явное» против «неявного».
Кажется, что они действительно сосредоточились на том, чтобы «сделать как можно больше в как можно меньшем количестве кода», даже если это скрывает часть логики (в этом случае логика ltr против rtl )

Flutter попросит вас использовать Row .

Flutter использует и полагается на множество «причудливых языковых функций» (читай: языковые функции, к которым тот, кто говорит, не привык и / или не согласен). Сразу в голову приходят постоянные конструкторы (и стиль именования конструкторов в Dart в целом), перегрузка операторов, классы, являющиеся неявными интерфейсами, @covariant и примеси — это функции, которые вызовут реакцию от путаницы до прямой маркировки как запах кода в зависимости от опыта разработчика. Я, вероятно, мог бы составить более длинный список, если бы подумал час. И это не обвинение Flutter в большей степени, чем обвинение SwiftUI — я не понимаю, почему кто-то может считать добродетелью писать программное обеспечение на определенном языке, чтобы его можно было написать одинаково на любом языке — в чем смысл? смысл разных языков, если мы должны притворяться, будто различий между ними не существует?

Кроме того, я совершенно не согласен с тем, что либо setState , либо @State явно указывают на свою связь с актом восстановления представления. В обоих случаях вам просто говорят, что если вы измените что-то, что было помечено как состояние, фреймворк разберется, что строить. В обоих случаях разработчик по-прежнему не имеет явного контроля над тем, что происходит и когда именно. Вы находите вызов функции более знакомым, люди, работающие на других языках, находят декораторы более знакомыми. Но вызов функции не делает вещи не волшебными.

Flutter попросит вас использовать Row

Я так понимаю, вы никогда не использовали ListTile , у которого такое же поведение, как показано здесь, но с именованными параметрами? Должны ли мы также спросить, почему Scaffold «волшебным образом» помещает кнопку меню в левую часть панели приложений, когда вы этого не просили?

Разница в том, что в нынешнем состоянии Dart очень похож на большинство основных языков.

Это важно.
Вопрос «Нужно ли мне изучать Dart, или я могу просто начать изучать Flutter?» встречается довольно часто.
На данный момент ответ таков: «Просто изучите Flutter. Вы сможете написать эффективный дротик за один день».
Это не гарантирует, что так будет всегда, но я думаю, что это одна из сильных сторон Flutter.

Остальное обсуждение немного не по теме. Если хотите, мы можем продолжить эту часть по почте (моя почта на github работает).

Почему это не заблокировано? Это уже плохо развивается, и это точно так же, как ранее заблокированная проблема.

Я сделал простой здесь:
https://github.com/danialdezfouli/flutterjsx
https://www.npmjs.com/package/flutterjsx
https://www.youtube.com/watch?v=Oj1JMSurphA

Эта ветка была автоматически заблокирована, так как после ее закрытия не было никаких действий в последнее время. Если вы все еще испытываете подобную проблему, откройте новую ошибку, включая вывод flutter doctor -v и минимальное воспроизведение проблемы.