копия @lukechurch

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

Итак, пример «Базовые виджеты» на « https://flutter.io/widgets-intro/#basic -widgets» будет выглядеть следующим образом:

import 'package:flutter/material.dart';

class MyAppBar extends StatelessWidget {
  MyAppBar({this.title});

  // Fields in a Widget subclass are always marked "final".

  final Widget title;

  <strong i="7">@override</strong>
  Widget build(BuildContext context) {
    let style = {
        height: 56.0, // in logical pixels
        padding: const EdgeInsets.symmetric(horizontal: 8.0),
        decoration: <BoxDecoration color={Colors.blue[500]}/>,
    };

    return <Container style={style}>
      <Row>
        <IconButton
            icon={<Icon name={Icons.menu}/>}
            tooltip='Navigation menu'
            onPressed={null}
        />
        <Expanded>
           {title}
    </Expanded>  
        <IconButton
            icon={<Icon name={Icons.search}/>}
            tooltip='Search'
            onPressed={null}
        />
      </Row>
    </Container>;
  }
}

class MyScaffold extends StatelessWidget {
  <strong i="8">@override</strong>
  Widget build(BuildContext context) {
    // Material is a conceptual piece of paper on which the UI appears.
    return <Material>
      <Column>
          <MyAppBar
             title={<Text 
               text='Example title'
               style={Theme.of(context).primaryTextTheme.title},
             />}
          />
          <Expanded>
            <Center>
              <Text text='Hello, world!'/>
            </Center>
          </Expanded>
      </Column>
    </Material>;
  }
}

void main() {
  runApp(<MaterialApp
    title='My app'
    home={<MyScaffold/>}
  />);
}

Как насчет этого синтаксиса?:

import 'package:flutter/material.dart';

class MyAppBar extends StatelessWidget {
  MyAppBar({this.title});

  // Fields in a Widget subclass are always marked "final".

  final Widget title;

  <strong i="6">@override</strong>
  Widget build(BuildContext context) {
    return Container(
      height: 56.0, // in logical pixels
      padding: EdgeInsets.symmetric(horizontal: 8.0),
      decoration: BoxDecoration(color: Colors.blue[500]),
      child: Row(
        children: <Widget>[
          IconButton(
            icon: Icon(Icons.menu),
            tooltip: 'Navigation menu',
            onPressed: null,
          ),
          Expanded(
            child: title,
          ),
          IconButton(
            icon: Icon(Icons.search),
            tooltip: 'Search',
            onPressed: null,
          ),
        ],
      ),
    );
  }
}

class MyScaffold extends StatelessWidget {
  <strong i="7">@override</strong>
  Widget build(BuildContext context) {
    // Material is a conceptual piece of paper on which the UI appears.
    return Material(
      child: Column(
        children: <Widget>[
          MyAppBar(
            title: Text(
              'Example title',
              style: Theme.of(context).primaryTextTheme.title,
            ),
          ),
          Expanded(
            child: Center(
              child: Text('Hello, world!'),
            ),
          ),
        ],
      ),
    );
  }
}

void main() {
  runApp(MaterialApp(
    title: 'My app',
    home: MyScaffold(),
  ));
}

Хм, небольшое улучшение, но не очень...
Вот что можно сделать с помощью XML:
(1) Больше никаких «детских» и «детских» вещей
(2) легко манипулировать сторонними инструментами (разбирать, анализировать и регенерировать)
(3) обратите внимание, что переключение между разметкой и программированием легко обнаруживается. Я имею в виду, что внутри XML у вас есть '{}' для разделения кода, а в коде у вас есть ' Также отделите все «стиль» от основной структуры.
Я знаю, что это в основном полностью поддерживает путь React, но вы все равно на полпути;)

копия @kasperl

(1) Больше никаких «детских» и «детских» вещей

Я не очень понимаю, почему это желательно. "ребенок" и "дети" не являются особенными. Рассмотрим, например, ListTile. Как бы вы сделали это? Почему «значок» в IconButton или «дом» в MaterialApp — это то, чему вы хотите дать имя, а не «дочерний элемент» в расширенном? Все три — просто произвольные аргументы, которые принимают объекты Widget. Нет ничего волшебного в «ребенке» и «доме».

(2) легко манипулировать сторонними инструментами (разбирать, анализировать и регенерировать)

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

(3) обратите внимание, что переключение между разметкой и программированием легко обнаруживается.

Почему это желательно? Я имею в виду, почему все это считается «программированием»? Это все просто выражения.

Я имею в виду, что внутри XML у вас есть '{}' для разделения кода, а в коде у вас есть '

Я не очень понимаю различия.

Также отделите все «стиль» от основной структуры.

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

Я не очень понимаю, почему это желательно. "ребенок" и "дети" не являются особенными. Рассмотрим, например, ListTile. Как бы вы сделали это? Почему «значок» в IconButton или «дом» в MaterialApp — это то, чему вы хотите дать имя, а не «дочерний элемент» в расширенном? Все три — просто произвольные аргументы, которые принимают объекты Widget. Нет ничего волшебного в «ребенке» и «доме».

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

Почему это желательно? Я имею в виду, почему все это считается «программированием»? Это все просто выражения.

Это связано с (2), потому что это значительно упрощает жизнь создателям инструментов, особенно создателям графического интерфейса, поскольку им не нужно полностью анализировать Dart; но это также облегчает чтение кода.

Я не очень понимаю различия.

Формат XML очень прост, поэтому, когда вы видите '{}', вы знаете, что он вычисляет выражение в dart. То же самое и наоборот, когда вы читаете код дротика и видите ') вы знаете, что иерархия объектов создается из XML-разметки.

Также в окончательном XML-процессоре я бы не стал передавать объекты атрибутам родителей и вместо этого создавал дочерние теги, как показано ниже:

this...
          <MyAppBar>
             <Title style={Theme.of(context).primaryTextTheme.title}>  
                 Example title
             </Title>
          </MyAppBar>

instead of this...
          <MyAppBar
             title={<Text 
               text='Example title'
               style={Theme.of(context).primaryTextTheme.title},
             />}
          />

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

Но почему только для некоторых свойств? И как вы справляетесь со случаями, когда есть два дочерних слота, например ListItem? XML-синтаксис, похоже, не очень хорошо справляется с этим.

Также я не совсем уверен, что это менее шаблонно.

Сравнивать:

   <Container style={style}>
      <Row>
        <IconButton
            icon={<Icon name={Icons.menu}/>}
            tooltip='Navigation menu'
            onPressed={null}
        />
        <Expanded> {title} </Expanded>  
      </Row>
    </Container>

   Container(style: style,
      child: Row(
        children: [
          IconButton(
            icon: Icon(Icons.menu),
            tooltip: 'Navigation menu',
            onPressed: null,
          ),
          Expanded(child: title),
        ],
      ),
    )

Мне совсем не ясно, что XML-синтаксис чище или менее шаблонен. Там намного больше знаков препинания и некоторое дублирование контента (например, в закрывающих тегах). И вам пришлось добавить некоторые имена, так что, конечно, вы теряете «ребенок», но получаете «имя» на иконке.

Кроме того, с XML, как вы даете понять, что Row может иметь ноль, один или более одного дочернего элемента, в то время как Center должен иметь ровно один дочерний элемент? Что произойдет, если кто-то сделает это?:

   <Center> <Test/> <Test/> </Center>

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

Им не нужно было бы полностью анализировать Dart, если бы у нас также был API для анализа Dart, верно? Я имею в виду, вы бы разобрали то, что хотите разобрать, а остальное оставили. Также я не уверен, что на самом деле его легче анализировать, поскольку на самом деле это не XML; увидеть ниже.

но это также облегчает чтение кода.

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

Формат XML очень прост, поэтому, когда вы видите '{}', вы знаете, что он вычисляет выражение в dart.

Однако на самом деле это не XML, верно? Это какой-то вариант XML. Существуют ли для него четко определенные правила синтаксического анализа? Например, это допустимо?

  <Test name={describe("}")}>

Как он узнает, что первый «}» не является концом выражения атрибута, не анализируя Dart?

То же самое и наоборот, когда вы читаете код дротика и видите ') вы знаете, что иерархия объектов создается из XML-разметки.

Вы знаете это сегодня, когда видите ключевое слово new , верно? Или даже в приведенном выше предложении разметки без новых слов, когда вы видите любое слово с заглавной буквы. Это действительно преимущество XML, или вы лучше знакомы с XML, чем с Dart?

Также в окончательном XML-процессоре я бы не стал передавать объекты атрибутам родителей и вместо этого создавал дочерние теги, как показано ниже:

Я действительно не понимаю, что вы предлагаете здесь. Насколько я могу судить, это вообще не правильно сформированный XML. Можете ли вы уточнить, какой именно синтаксис вы предлагаете и как он работает? Например, конструктор «Текст», кажется, исчез; откуда процессор это знает

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

Если вам действительно интересно узнать, почему JSX популярен, просто погуглите «учебник по реакции» и обратите внимание, что за последние 2 года все статьи о React используют JSX. Первоначальный способ создания иерархий компонентов в React (эквивалентный текущему способу во Flutter) больше никогда не упоминается, потому что JSX стал предпочтительным методом (лучшая практика).

https://facebook.github.io/реакт/туториал/туториал.html
https://facebook.github.io/react-native/docs/flatlist.html

Еще одна интересная вещь заключается в том, что Typescript также принял JSX:
https://www.typescriptlang.org/docs/handbook/jsx.html

Вы не поняли, что синтаксический анализ XML (с некоторым дополнительным кодом для правильного пропуска '{}') на порядки проще, чем полный синтаксический анализ языка программирования, такого как Dart. Это факт. Вы предполагаете, что разработчики инструментов будут использовать Dart в своей разработке, но это не так, Intellij, скорее всего, использует Kotlin и Java в своих IDE, поддерживающих Dart (это особый случай, потому что они специализируются на анализе языка; всем остальным будет трудно полностью разобрать Dart с другого языка).

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

Прекратите придираться к вещам, которые не полностью определены. Все ваши сомнения развеялись, просто узнайте больше о том, как это было реализовано в JSX. У меня просто нет времени на это здесь.

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

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

Я не сомневаюсь, что JSX "горячий". В React не-JSX синтаксис намного хуже, чем альтернативный синтаксис, предложенный в этом выпуске (тот, который выглядит как наш текущий код, но без ключевых слов «new» и «const»). Я пытаюсь понять, применимы ли к Flutter те же причины, по которым JSX является «горячим» в React.

Что касается TypeScript, выполняющего JSX, в 2012 году я участвовал в попытках указать E4H , а еще до этого был E4X . Обе попытки погибли. Поэтому для меня важно, чтобы мы понимали, что именно людям нравится в JSX по сравнению с другими синтаксисами.

Разбирать XML непросто, разбор типа XML-но-с-фигурными скобками тоже непрост. Анализ типа XML, но с фигурными скобками, каким-то образом встроенного в другой язык, еще менее прост. Однако то, насколько легко это реализовать, вероятно, не имеет большого значения, потому что это будет реализовано один или два раза, а затем библиотека, которая это сделает, будет повторно использоваться. (Я принимал активное участие в написании спецификаций для синтаксического анализа HTML и участвовал в аналогичной работе для XML, и я реализовал синтаксический анализатор для Dart, так что у меня есть довольно хорошее представление о том, насколько сложны синтаксический анализ языков разметки по сравнению с языками программирования на самом деле. является.)

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

Но почему это выгодно?

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

Прекратите придираться к вещам, которые не полностью определены. Все ваши сомнения развеялись, просто узнайте больше о том, как это было реализовано в JSX. У меня просто нет времени на это здесь.

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

Я пытаюсь понять, применимы ли к Flutter те же причины, по которым JSX является «горячим» в React.

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

Умер E4X или нет, не имеет значения, потому что ничто не живет вечно. Я много использовал ActionScript с E4X и считаю, что Adobe отлично справилась с этой задачей. В некотором смысле Flutter — это просто более новая версия Adobe Flash с приложениями Flex.

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

Отлично, вы знаете, что синтаксический анализ языка разметки тривиален по сравнению с синтаксическим анализом императивного языка программирования.

Но почему это выгодно?

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

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

Легко ли вы видите структуру своих гигантских вложенных выражений? Можно ли легко манипулировать этой структурой с помощью других инструментов, таких как конструкторы графического интерфейса пользователя? Я имею в виду, как Adobe Flex Builder использует, чтобы делать, перетаскивать виджеты, подключать их к пользовательскому интерфейсу, а затем переключаться в режим просмотра кода и просто редактировать все, что вы хотите, а затем переключаться обратно в режим графического интерфейса и продолжать манипулировать виджетами. Вы не можете сделать это легко, когда программист заходит внутрь ваших «гигантских вложенных выражений» и пишет любой действительный код дротика, который не соответствует структуре, которую ожидает редактор графического интерфейса. С фиксированной структурой XML это не проблема.

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

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

  new ListTile(
    title: new Text('CineArts at the Empire',
        style: new TextStyle(fontWeight: FontWeight.w500, fontSize: 20.0)),
    subtitle: new Text('85 W Portal Ave'),
    leading: new Icon(
      Icons.theaters,
      color: Colors.blue[500],
    ),
  ),

  <ListTile>
    <title> 
      <Text style={{fontWeight: FontWeight.w500, fontSize: 20.0}}>
         CineArts at the Empire
      </Text>
    </title>
    <subtitle>
      <Text>85 W Portal Ave</Text>
    </subtitle>
    <leading>
      <Icon data={Icons.theaters} color={Colors.blue[500]}/>
    </leading>
  </ListTile>,

Он выглядит длиннее, чем версия с дротиками, но я мог бы поместить все в такое же количество строк. Дело в том, что IDE/редактор может предоставить «+» и «-» для расширения и свертывания этих XML-узлов в любом случае.

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

Умер E4X или нет, не имеет значения, потому что ничто не живет вечно.

Вопрос не в том, умер ли он, а в том, почему он умер. Умерла ли она, потому что не дала решения, которого хотели люди? Он умер из-за проблем с реализацией? Он умер из-за проблем с патентами? Было ли это слишком рано? Поздно? Я думаю, важно извлечь уроки из прошлого опыта. Почему E4X и E4H потерпели неудачу там, где преуспел JSX?

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

Легко ли вы видите структуру своих гигантских вложенных выражений?

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

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

Отлично, вы знаете, что синтаксический анализ языка разметки тривиален по сравнению с синтаксическим анализом императивного языка программирования.

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

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

Если это основное преимущество, то это то, что мы можем проверить. Мы могли бы взять группу инженеров, которые привыкли писать код HTML, React, код iOS, код Android, Flutter, приложения командной строки и т. д., и представить каждому из них различные синтаксисы и попросить их описать, что, по их мнению, результирующий пользовательский интерфейс будет выглядеть. Затем мы можем измерить, какой синтаксис дает наилучшие результаты. @InMatrix , может быть, мы могли бы посмотреть на это после того, как работа над анимацией завершится?

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

Да в принципе по крайней мере. Должно быть относительно просто механически преобразовывать выражения Dart в XML, JSON или любой другой структурированный язык, который можно использовать. Это просто вопрос преобразования синтаксиса, фактическая информация та же самая. Лично я бы не стал преобразовывать его в другой синтаксис, если бы делал редактор с графическим интерфейсом, я бы просто разобрал его в структуру данных в памяти прямо из Dart.

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

Дело в том, что вы можете поместить в структуру XML точно такой же «любой действительный код дротика», как и в выражении дротика. Они буквально механически взаимозаменяемы. Так что я не очень понимаю, как использование XML помогает в этом. Например, как бы вы превратили это в XML?:

new ListView.builder(
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0,
  itemBuilder: (BuildContext context, int index) {
    return new Text('entry $index');
  },
)

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

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

Я работал над Adobe Flex SDK, который сочетал в себе XML-разметку и ActionScript, последние пару лет, пока этот продукт существовал в Adobe. Я понимаю привлекательность разметки для определения пользовательского интерфейса, но я также могу вспомнить некоторые недостатки:

• Визуальные элементы приложения Flex можно определить с помощью разметки и кода. Насколько я помню, в крупных реальных приложениях доминировал код. Удобочитаемость не обязательно является преимуществом для приложений, определяемых как сложные гибриды разметки и кода.
• IDE «Flex Builder» должна была поддерживать приложения, определяемые разметкой и кодом. Это усложняло создание и поддержку IDE. Разработчики склонны рассматривать его как инструмент ActionScript.
• Развитие и поддержка "компилятора" XML было значительным бременем, из-за которого команда инженеров была занята полный рабочий день. Хранение компилятора и инструментария в тесном взаимодействии замедлило эволюцию всего SDK.

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

Вопрос не в том, умер ли он, а в том, почему он умер. Умерла ли она, потому что не дала решения, которого хотели люди? Он умер из-за проблем с реализацией? Он умер из-за проблем с патентами? Было ли это слишком рано? Поздно? Я думаю, важно извлечь уроки из прошлого опыта. Почему E4X и E4H потерпели неудачу там, где преуспел JSX?

Он умер, потому что E4X был реализован только в ActionScript, который использовался только внутри Adobe Flash/Flex, и Adobe закрыла проект. Вместо этого Adobe изменила курс на открытые стандарты, где нет единого поставщика исходного кода с возможностью блокировки и взрыва экосистемы.

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

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

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

Забавно, но похоже, что закрывающий XML-тег, о котором вы упоминали ранее, слишком многословен.

Если это основное преимущество, то это то, что мы можем проверить. Мы могли бы взять группу инженеров, которые привыкли писать код HTML, React, код iOS, код Android, Flutter, приложения командной строки и т. д., и представить каждому из них различные синтаксисы и попросить их описать, что, по их мнению, результирующий пользовательский интерфейс будет выглядеть. Затем мы можем измерить, какой синтаксис дает наилучшие результаты. @InMatrix , может быть, мы могли бы посмотреть на это после того, как работа над анимацией завершится?

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

Дело в том, что вы можете поместить в структуру XML точно такой же «любой действительный код дротика», как и в выражении дротика.

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

new ListView.builder(
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0,
  itemBuilder: (BuildContext context, int index) {
    return new Text('entry $index');
  },
)

let style = {
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0
};

<ListView.builder style={style}>
  {(context, index) => <Text> entry {index} </Text>}
</ListView.builder>

Я широко использовал Adobe Flex Builder...

Разработчики склонны рассматривать его как инструмент ActionScript.

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

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

Не в сегодняшнем мире. Императивные языки развились в философии Python и отлично подходят для разработки. Декларативные методы со встроенной разметкой (XML) стали мейнстримом с появлением React; и JSON стал предпочтительным текстовым форматом данных.

E4X был реализован только в ActionScript.

E4X был стандартом ECMA. Mozilla какое-то время поставляла его, но затем удалила (очень необычный шаг для производителя браузера). Другие поставщики браузеров никогда не хотели его реализовывать. (Однако они реализовали и другие новые функции ECMA.) С E4H производители браузеров никогда не были заинтересованы в его реализации (хотя опять же, они реализовали множество других вещей, которые я помог изобрести).

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

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

Забавно, но похоже, что закрывающий XML-тег, о котором вы упоминали ранее, слишком многословен.

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

... ListView ...

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

Это может быть контраргументом к этому запросу и/или, возможно, некоторым пониманием, которое следует иметь в виду, если вы хотите разметку. У меня сильное чувство, что добавление разметки создает некоторые проблемы с GWT. Мне не хотелось бы видеть, как проходит другой API.

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

GWT начинал таким образом, создавая пользовательские интерфейсы с помощью Java. Затем появился UiBinder, где вы могли создать пользовательский интерфейс в разметке xml со спецификацией. Затем инструментарий Eclipse Plugin смог создать пользовательский интерфейс в разметке xml. Android тоже это делает, не нужно заморачиваться. Итак, что я видел, разметка отлично работает для разработчиков UI IDE. Но на самом деле разметка — это огромные затраты времени и дополнительные инструменты сложности для перехода к реальной программе. А инструменты всегда приходят последними. Так что в то же время, пока все это проявляется в реальности, есть два мира. Два интересных способа сделать все. Один на языке по умолчанию и один в разметке. Так что сегодня я поддерживаю GWT. Когда я пишу документацию, мне приходится писать ее дважды: один раз для Java и один раз для XML-разметки UiBinder. Таким образом, реальный вопрос, если вы хотите пойти по пути разметки, я думаю, следует задать вопрос, стоит ли добавленная сложность путешествия!

JSX, я думаю, направлен на решение других проблем, когда вы хотите объединить то, что вы делаете с HTML и javascript. На самом деле кажется, что добавленная сложность спецификации разметки не соответствует потребностям написания пользовательского интерфейса с разметкой. Особенно, когда у вас нет языка разметки документа в качестве цели. По крайней мере, не для обычного пользователя.

На позитивной ноте. Мне нравится работать с инструментами. Так что я вижу, что язык разметки весьма полезен. Гораздо проще писать и изменять AST, когда вы используете разметку.

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

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

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

Я бы сказал, что только Adobe полностью поддерживала E4X и имела хорошие отношения с разработчиками. Поставщики браузеров постоянно что-то добавляют и удаляют из своих браузеров; разве Google не удалил поддержку MathML?

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

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

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

let style = {
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0
};

<ListView.builder style={style}>
  {(context, index) => <Text> entry {index} </Text>}
</ListView.builder>

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

Но на самом деле разметка — это огромные затраты времени и дополнительные инструменты сложности для перехода к реальной программе.

Все, о чем я прошу, это добавить эти простые расширения к компилятору Dart, чтобы разработчики, если захотят, могли писать с использованием этой XML-структуры. Старый способ будет продолжать работать, и объем работы, связанный с этим, совсем невелик. На самом деле вы можете увидеть, сколько строк кода требуется компилятору babel.js для работы с JSX, и я говорю о сотнях, а не о тысячах строк (я только что проверил).

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

Конечно, но React был таким, и это вообще не проблема.

Когда я пишу документацию, мне приходится писать ее дважды: один раз для Java и один раз для XML-разметки UiBinder.

Не в React, потому что разметка живет внутри кода.

добавленная сложность стоит путешествия!

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

React лидирует в разработке новейших методов разработки UI/UX. Он имеет огромную тягу к разработчикам. Ваш самый большой риск — не соответствовать планке React.

JSX, я думаю, направлен на решение других проблем, когда вы хотите объединить то, что вы делаете с HTML и javascript.

JSX предназначен не только для HTML, React Native генерирует представления (например, виджеты Flutter) из разметки XML.

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

Больше похоже на то, как можно улучшить UI/UX. Лучшее значение: быстрее, качественнее (код и UI/UX), плавное взаимодействие между дизайнером и разработчиком и т. д.

Кстати, действительно хорошая работа над инструментами разработчика; "Флаттер-доктор" был потрясающим!!!
Теперь я готовлю на газу и могу быть опасно креативным ;)

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

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

Если это основное преимущество, то это то, что мы можем проверить. Мы могли бы взять группу инженеров, которые привыкли писать код HTML, React, код iOS, код Android, Flutter, приложения командной строки и т. д., и представить каждому из них различные синтаксисы и попросить их описать, что, по их мнению, результирующий пользовательский интерфейс будет выглядеть. Затем мы можем измерить, какой синтаксис дает наилучшие результаты. @InMatrix , может быть, мы могли бы посмотреть на это после того, как работа над анимацией завершится?

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

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

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

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

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

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

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

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

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

AppBar на https://flutter.io/catalog/samples/basic-app-bar/ настолько уникален, что его нельзя назвать повторно используемым компонентом; это компонент-оболочка/составной компонент, и в этих случаях почему бы просто не использовать локальный метод для создания этой части пользовательского интерфейса? Я предполагаю, что если бы он делал больше вещей, имело бы смысл поместить его в обертку/композитный компонент.

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

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

AppBar на https://flutter.io/catalog/samples/basic-app-bar/ настолько уникален, что его нельзя назвать повторно используемым компонентом.

Он также относительно небольшой, так что все в порядке.

Что касается производительности, это несколько не по теме этой проблемы, поэтому, пожалуйста, создайте новую проблему, если вы хотите ее обсудить (или по электронной почте flutter-dev или опубликуйте сообщение о переполнении стека, что вы предпочитаете).

https://github.com/Kotlin/anko/wiki/Anko-Layouts

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

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

Я призываю людей, вовлеченных в процесс, дать React Native вращение и посмотреть, о чем мы говорим.

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

@birkir Я на 100% с вами в этом вопросе. Отсутствие JSX, который идеально подходит для Flutter, делает Flutter старым и ржавым, ощущается как технология 1990-х годов. На самом деле кажется, что все так или иначе принимают JSX; последним из них является популярный фреймворк Vue.js.

+1

@zoechi Каков ваш предыдущий опыт работы с JSX, вы действительно использовали его или просто смотрели на него? Я думаю, что вы, ребята, недооцениваете JSX, говоря, что он даст небольшие выгоды здесь и там. Если у вас нет пользователей, у вас нет продукта.

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

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

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

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

Итак, каковы ваши убедительные аргументы?

Действительно !!! «Кажется, никто не удосужился объяснить, что именно получит Флаттер… бла-бла-бла».
Вы не читали эту ветку полностью? Ваша концентрация внимания больше, чем ваши знания JSX?

Вы, ребята, страдаете синдромом NIH (здесь это не изобретено). "Хорошие художники копируют, великие художники воруют", посредственные художники, ну и ведите себя как вы.

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

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

Добавление функций, потому что они есть у других, — слабый аргумент. Хорошо.
Почему у флаттера есть горячая перезагрузка? Откуда это пришло? Иисус чувак.

Почему мы не смогли предоставить вам веские аргументы, ребята? Развитие проекта и привлечение разработчиков — наша главная причина.

Причина номер два, читабельность :

https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/demo/cupertino/cupertino_buttons_demo.dart против https://gist.github.com/birkir/e921158239c324ab95bb0b174383a562

Причина номер три, GUI Builders . Я процитирую первую строку в README.

Новый пакет SDK для мобильных приложений, который поможет разработчикам и дизайнерам создавать современные мобильные приложения для iOS и Android.

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

Развитие проекта и привлечение разработчиков

Отношения до сих пор неясны.

Причина номер два, читабельность:

Сделать код Dart более читабельным кажется мне лучшей целью

Причина номер три, GUI Builders. Я процитирую первую строку в README.

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

Ваши контраргументы не могут опровергнуть эту идею, не так ли?

1. Отношение довольно ясное. Разве не целью проекта является популярность?
2. Здорово! Будет ли он близок к читабельности JSX? Каково текущее предложение для такой вещи?
3. Было заявлено, что это можно сделать . Адаптация поддержки JSX для доступных в настоящее время сборщиков графического интерфейса будет намного проще.

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

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

Некоторые запросы функций языка Dart могут сделать код более коротким/читабельным:

• Дополнительные new и const для Dart 2
• Мета-проблема для обсуждения предложения разрешить именованные аргументы везде - это может позволить виджету с аргументом child пропускать именованный аргумент.
  
  
  
  • Переменное количество аргументов — это может позволить виджетам с аргументом children (например, Row и Column) пропускать этот именованный аргумент и его объявление списка.
  
  

С этими изменениями код может выглядеть так:

  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Cupertino Buttons')),
      body: Column(
        Padding(padding: EdgeInsets.all(16.0),
          Text(
            'iOS themed buttons are flat. They can have borders or backgrounds but '
            'only when necessary.'
          ),
        ),
        Expanded(
          Column(mainAxisAlignment: MainAxisAlignment.center,
            Text(_pressedCount > 0
                   ? 'Button pressed $_pressedCount time${_pressedCount == 1 ? "" : "s"}'
                   : ' '),
            Padding(padding: EdgeInsets.all(12.0)),
            Align(alignment: Alignment(0.0, -0.2),
              Row(mainAxisSize: MainAxisSize.min,
                CupertinoButton(onPressed: () { setState(() { _pressedCount += 1; }); },
                  Text('Cupertino Button'),
                ),
                CupertinoButton(onPressed: null,
                  Text('Disabled'),
                ),
              ),
            ),
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: () { setState(() { _pressedCount += 1; }); },
              Text('With Background'),
            ),
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: null,
              Text('Disabled'),
            )
          ),
        ),
      )
    );
  }

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

  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Cupertino Buttons')),
      body: Column(
        Padding(padding: EdgeInsets.all(16.0),
          Text(
            'iOS themed buttons are flat. They can have borders or backgrounds but '
            'only when necessary.'
          ),
        ),
        Expanded(
          Column(mainAxisAlignment: MainAxisAlignment.center,
            Text(_pressedCount > 0
                   ? 'Button pressed $_pressedCount time${_pressedCount == 1 ? "" : "s"}'
                   : ' '), // Text
            Padding(padding: EdgeInsets.all(12.0)),
            Align(alignment: Alignment(0.0, -0.2),
              Row(mainAxisSize: MainAxisSize.min,
                CupertinoButton(onPressed: () { setState(() { _pressedCount += 1; }); },
                  Text('Cupertino Button'),
                ), // CupertinoButton
                CupertinoButton(onPressed: null,
                  Text('Disabled'),
                ), // CupertinoButton
              ), // Row
            ), // Align
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: () { setState(() { _pressedCount += 1; }); },
              Text('With Background'),
            ), // CupertinoButton
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: null,
              Text('Disabled'),
            ), // CupertinoButton
          ), // Column
        ), // Expanded
      ), // Column
    ); // Scafold
  }

Этот разговор накаляется. Я хотел бы призвать всех прочитать наш кодекс поведения:
https://flutter.io/design-principles/#conflict-разрешение
Я собираюсь закрыть этот разговор на несколько дней, пока все обдумывают, как они могут уважительно и продуктивно внести свой вклад.

Все мы знаем, что синтаксис для создания пользовательского интерфейса — очень важная часть опыта мобильной разработки. На данный момент синтаксис немного подробен, мне нужно что-то new только для того, чтобы добавить поле: margin: new EdgeInsets.symmetric(horizontal: 4.0) , я думаю, что может быть более простой способ.

Можно ли создать DSL, как это сделала команда Kotlin для разработчиков Android? Он называется Anko , DSL для создания пользовательского интерфейса Android:

verticalLayout {
  padding = dip(30)
  editText {
    hint = "Name"
    textSize = 24f
  }
  button("Login") {
    textSize = 26f
  }
}

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

Пожалуйста, не вводите XML-подобный синтаксис во Flutter.

Я больше года программировал на Android Java, а потом начал искать кроссплатформенный набор инструментов, чтобы попробовать.
Я начал с React Native, а затем попробовал React. Мне не очень понравился синтаксис JSX, потому что это не совсем javascript и не совсем html, так что это еще одна вещь, которую нужно изучить.
Когда я попробовал Flutter, мне было намного легче начать работу (вероятно, в основном из-за моего опыта работы с Java).

Я думаю, что некоторые из причин, по которым я не хотел бы, чтобы XML-синтаксис добавлялся к флаттеру:

1. Еще одна вещь, которую нужно изучить - вместо этого можно потратить на изучение фьючерсов ;P
2. Переключение контекста — вы переключаете контекст между XML и кодом, что является просто ненужной когнитивной нагрузкой.
3. Были дни, когда я программировал на Java утром и на Python днем. С React вам может понадобиться понимать Javascript, Babel, JSX, HTML, CSS и многое другое в одной кодовой базе.
4. Причина, по которой XML не нужен во Flutter, заключается в том, что у dart есть именованные аргументы, которые довольно хорошо заменяют атрибуты XML.
5. В Dart есть очень крутой dartfmt, который очень хорошо делает отступы в коде без каких-либо усилий.

По сравнению с Android

1. Вы все равно должны изучить программный способ, зачем добавлять еще один способ делать что-то?
2. Макет XML в Android быстрее отображает изменения на устройстве, но запуск во Flutter в любом случае практически мгновенный, поэтому добавление XML не даст этого преимущества.
3. Сочетание Android XML и программных средств добавляет сложности, например, увеличение фрагментов XML и внедрение в XML-дерево программными средствами.
4. Мгновенный запуск во Flutter настолько быстр, что вам не нужна модель XML, чтобы визуализировать, как она будет выглядеть, вы можете просто нажать клавишу и сразу увидеть изменение.
5. Ошибки из-за проблем с программным макетом отличаются от проблем с макетом в XML, поэтому вам нужно понять два набора вещей.

Я бы сделал еще один шаг и удалил pubspec.yaml и заменил его на pubspec.dart и получил конфигурацию в коде dart.

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

Это не должно быть двухстороннее редактирование (XML/макет), как Android XML, но вы просто сохраняете свой макет на потом. Если вам нужно изменить его, вы можете перегенерировать код и (надеюсь) просто изменить некоторые аргументы.

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

Флаттер НОВЫЙ. Это совершенно НОВЫЙ способ делать вещи. Да, это заимствовано из парадигмы реагирования. Но это не значит, что ему нужно следовать тем же шагам. Я не думаю, что цель команды флаттера состоит в том, чтобы привлечь разработчиков из React Native, чтобы они пришли к флаттеру, а только в том, чтобы создать что-то новое, что может заинтересовать разработчиков. Google использует его внутри, прежде чем поделиться им с миром, и они были продуктивны с Это. Я делюсь комментариями с @Hixie о том, что он ничем не отличается от JSX для создания пользовательского интерфейса. Да, это немного более многословно, чем правый чистый дротик. Но на самом деле это значительно упрощает отладку вашего кода.

Причина, по которой я против языка разметки, JSX или всего, что находится на вершине технологии, заключается в том, что это требует от платформы гораздо больше работы. Вы можете быть счастливы, создавая язык разметки для пользовательского интерфейса, но у вас будет так много разработчиков, работающих над платформой, которые плачут и рвут на себе волосы, чтобы заставить ее работать на вас. Другая точка зрения заключается в том, что JSX работал для сообщества Javascript, где, как всегда, его главная цель — упростить жизнь разработчику и не беспокоиться о компромиссах. Не поймите меня неправильно. React(JSX) для Интернета был создан на небесах, потому что HTML в любом случае является разметкой. Но для React Native посмотрите на весь код в репозитории, который они должны были сделать, чтобы заставить его работать. Добавление JSX во флаттер потребует тонны работы и двух моментов, о которых нужно подумать при добавлении новых функций. И снова просто чтобы можно было удалить дочерний параметр и константу и новые ключевые слова?. Я предпочитаю знать, что на самом деле происходит в коде, и иметь контроль над тем, что происходит, чем использовать волшебный синтаксис, который только добавляет накладные расходы.

Ну это мое мнение. Не хочу начинать новую гигантскую дискуссию. Просто упомянем тот факт, что JSX великолепен для сообщества реагирования/javascript, потому что он работал для них, но для Dart/flutter я считаю немного излишним добавлять JSX просто для привлечения разработчиков из React Native.

Вау, можно было написать в блоге xD

@Рокволе ,

Еще одна вещь, которую нужно изучить - вместо этого можно потратить на изучение фьючерсов ;P

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

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

Не проблема, нет переключения контекста, это просто часть среды, которая делает программирование UI/UX чище.

Затем он сгенерирует код Flutter, который не предназначен для редактирования.

Почему нет? Тогда не очень полезно.

@franzsilva

Я не думаю, что цель команды флаттера - привлечь разработчиков из React Native, чтобы они пришли к флаттеру.

Действительно !!! React Native доминирует, и, учитывая, что общее количество мобильных разработчиков, использующих кроссплатформенные инструменты, ограничено, вы действительно думаете, что Flutter может стать хитом, не привлекая React Native?

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

Это не правильное утверждение. Отладка кода JSX, который является просто кодом javascript, не проще и не сложнее, это то же самое.

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

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

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

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

Просто упомянем тот факт, что JSX великолепен для сообщества реагирования/javascript, потому что он работал для них, но для Dart/flutter я считаю немного излишним добавлять JSX просто для привлечения разработчиков из React Native.

JSX также должен отлично работать с Dart/Flutter. Это ни в коем случае не перебор. Есть ли веская причина, по которой JSX не будет работать для Dart/Flutter? Если бы я написал код и выпустил его, почему он не подходит для разработки Dart/Flutter?

Возьмем конкретный пример от @xinthink :

На данный момент синтаксис немного подробен, мне нужно что-то new только для того, чтобы добавить поле: margin: new EdgeInsets.symmetric(horizontal: 4.0) , я думаю, что может быть более простой способ.

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

  // Flutter as written today
  return new Container(
    margin: new EdgeInsets.symmetric(horizontal: 4.0),
    decoration: new ShapeDecoration(shape: new CircleBorder(), color: Colors.blue[100]),
    child: new AnimatedCrossFade(
      duration: const Duration(seconds: 3),
      firstChild: const FlutterLogo(style: FlutterLogoStyle.horizontal, size: 100.0),
      secondChild: const FlutterLogo(style: FlutterLogoStyle.stacked, size: 100.0),
      crossFadeState: _showHorizontal ? CrossFadeState.showFirst : CrossFadeState.showSecond,
    ),
  );

  // Flutter as written later this year once we remove "new" and "const" keywords
  return Container(
    margin: EdgeInsets.symmetric(horizontal: 4.0),
    decoration: ShapeDecoration(shape: CircleBorder(), color: Colors.blue[100]),
    child: AnimatedCrossFade(
      duration: Duration(seconds: 3),
      firstChild: FlutterLogo(style: FlutterLogoStyle.horizontal, size: 100.0),
      secondChild: FlutterLogo(style: FlutterLogoStyle.stacked, size: 100.0),
      crossFadeState: _showHorizontal ? CrossFadeState.showFirst : CrossFadeState.showSecond,
    ),
  );

Как бы вы порекомендовали выразить эту _точную_ семантику?

  // Remove "new" and "const", infer the class for enum values, allow int literals for doubles
  return Container(
    margin: EdgeInsets.symmetric(horizontal: 4),
    decoration: ShapeDecoration(shape: CircleBorder(), color: Colors.blue[100]),
    child: AnimatedCrossFade(
      duration: Duration(seconds: 3),
      firstChild: FlutterLogo(style: horizontal, size: 100),
      secondChild: FlutterLogo(style: stacked, size: 100),
      crossFadeState: _showHorizontal ? showFirst : showSecond,
    ),
  );

У Babel.js есть небольшой аккуратный веб-сайт, где вы можете ввести JSX, и он преобразует его в простой Javascript:
https://babeljs.io/repl/# ?babili=false&evaluate=true&lineWrap=false&presets=es2015%2Creact%2Cstage-0&code=function%20hello()%20%7B%0A%20%20return%20%3Cdiv%3EHello% 20мир!%3C%2Fdiv%3E%3B%0A%7D

Я сделаю эквивалент для DSX для Dart. Просто доказательство концепции, посмотрим, сколько времени это займет у меня...

Вот последний пример @Hixie в «DSX», использующий руководство по стилю Airbnb и предполагающий, что все дочерние элементы могут автоматически сопоставляться со свойствами child .

return (
  <Container
    margin={EdgeInsets.symmetric(horizontal: 4)}
    decoration={ShapeDecoration(shape: CircleBorder(), color: Colors.blue[100])}
  >
    <AnimatedCrossFade
        duration={Duration(seconds: 3)}
        crossFadeState={_showHorizontal ? showFirst : showSecond}
    >
      <FlutterLogo style={horizontal} size={100} />
      <FlutterLogo style={stacked} size={100} />
    </AnimatedCrossFade>
  </Container>
);

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

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

Если ваша цель состоит в том, чтобы вывести HTML из JavaScript, JSX имеет смысл в качестве золотой середины. Потому что, когда вам нужны теги в конце дня, React.createElement('div', null, 'foo') намного хуже, чем <div>foo</div> .

Если ваша цель состоит в том, чтобы вывести дерево объектов Dart из... Dart, а красиво отформатированное дерево конструкторов Dart идеально (возможно, более) читабельно, я не вижу смысла в обходе XML. И я не пропускаю эти XML-файлы, исходящие от Android.

Это то, что позволяет использовать XML... Послушайте, прошло 5 месяцев только разговоров, теперь я что-то делаю по этому поводу, так что дайте мне немного времени (у меня есть работа на полный рабочий день, и я могу выделить только около 4 часов по выходным).

Наткнулся на эту тему, интересная с обеих сторон. Как разработчик React, заинтересованный во Flutter, есть пара других аргументов, о которых я не упоминал (хотя я лишь бегло просмотрел все комментарии).

1. Объявление закрывающего тега улучшает понимание дочерних элементов и свойств. К сожалению, пользовательский интерфейс может быть глубоко вложенным, и наличие четкого тега по сравнению с неизвестным помогает прояснить и проанализировать дочерние элементы. Это также позволяет мне перемещать код между компонентами и очень декларативно видеть, когда что-то неуместно (например, закрывающий тег перед a). Это сложнее с несколькими вложенными ) .

2. Моя первоначальная интуитивная реакция на множество вложенных компонентов внутри конструкторов напоминает мне «ад обратных вызовов» . Это была очень болезненная эра JS, которая начинает улучшаться, и возвращение к ней кажется чем-то вроде шага назад.

3. Что касается № 2, печальный факт заключается в том, что мы должны убедить людей переключиться (или, по крайней мере, попробовать). Многие люди используют React/React Native и даже больше используют HTML/JS. Создание простого и в основном синтаксически знакомого учебника / руководства, специально предназначенного для некоторых болевых точек React, может быть чрезвычайно привлекательным для тех, кто немного устал.

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

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

Я думаю, что это основное различие между Open JavaScript и Dart. JavaScript действительно с открытым исходным кодом, в то время как запрос на Dart становится предметом разговора, и в конечном итоге вы демотивированы отрицательными голосами.

Освободите место для новых идей!

@jayjun Выглядит потрясающе! Можно где-нибудь попробовать?

@sanketsahusoft Не волнуйтесь, очень скоро вы сможете попробовать мою версию, и она даже лучше, чем @jayjun.

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

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

Карлос.

Поможет ли это с проблемой потери отслеживания закрывающих тегов?
Идея: Автоматически генерируемые закрывающие теги

Вот предлагаемый синтаксис разметки для примера @Hixie :

<Container margin=<EdgeInsets.symmetric horizontal=4 />
           decoration=<ShapeDecoration shape=<CircleBorder> color={{ Colors.blue[100] }} />>
    <AnimatedCrossFade duration=<Duration seconds=3 />
                       crossFadeState={{ _showHorizontal ? showFirst : showSecond }}>
      <FlutterLogo style=horizontal size=100 />
      <FlutterLogo style=stacked size=100 />
    </AnimatedCrossFade>
</Container>

@abarth , интересно, что вы сделали, так это добавили возможность третьего атрибута, которая упрощает внешний вид выражений, когда они являются другим тегом.
JSX имеет:
1 - <tag attrib=""/> или <tag attrib=''/>
2 - <tag attrib={}/>
Вы предложили другое:
3 - <tag attrib=<anotherTag.../>/>
с JSX вы должны написать это как:
<tag attrib={<anotherTag.../>}/>

@cbazza Да, третий случай довольно распространен во Flutter, поэтому имеет смысл пропустить дополнительное вложение { .

@abarth Ах, но я делаю большинство этих вещей ненужными, используя стили, подобные CSS !!! Транспилятор расширяет эти CSS-стили в соответствующие вызовы Flutter. Теперь структура тегов стала намного чище, а стили можно легко импортировать из дизайнерских инструментов, таких как InVision, Figma, Atomic и т. д.

@cbazza Круто, я использую много виджетов с закрытием, например FutureBuilder . Я надеюсь, что ваш транспилятор сможет сгенерировать что-то вроде:

return new FutureBuilder(
  future: Firestore.instance
      .collection('stuff')
      .document(id)
      .get(),
  builder: (context, snapshot) {
    if (!snapshot.hasData) {
      switch (snapshot.connectionState) {
        case ConnectionState.waiting:
          return const Text('Loading...');
        default:
          return new Text('${id} not found');
      }
    }

    return new Text(snapshot.data['name']);
  },
);

@jayjun Да, это не проблема. Транспайлер — это простой XML-процессор, и когда дело доходит до синтаксического анализа выражений (всего, что находится внутри {}), он просто становится текстовым BLOB-объектом, поэтому записывает его дословно.

@xinthink

Можно ли создать DSL, как это сделала команда Kotlin для разработчиков Android?

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

По моему скромному мнению, Flutter не нужен JSX. Flutter должен был выбрать Kotlin вместо Dart. Kotlin позволяет нам писать сложную логику пользовательского интерфейса с красивым синтаксисом из коробки, имеет огромное сообщество, готовые инструменты, проверенные в боевых условиях в разработке для Android...

Просто говорю.

Kotlin хорош, я его фанат, но он не работает на iOS… на самом деле работает, но еще не выпущен (сейчас на стадии предварительного релиза).
Для разработки UI/UX я по-прежнему предпочитаю JSX вместо Anko DSL. Мне нравится тот факт, что я могу визуально отделить декларативную разметку от императивного кода и довольно легко смешивать и сопоставлять компоненты.

Dart, Kotlin и Swift имеют сходство:
https://sethladd.github.io/swift-is-like-kotlin-and-kinda-like-dart/

Я люблю это :

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

Это в основном причины, по которым я выбрал Dart, а не Kotlin/Swift/React.

_Хотя решение о поддержке Dart и Swift в новой ОС Google Fuchsia меня смущает._

Я не уверен, что Dart более знаком, если вы пришли с Java. Я пришел с Java и у меня нет проблем с Kotlin или Swift; в основном объявление типа перевернуто, ничего нового, поскольку оно использовалось в Pascal и ActionScript.

Да, вы можете создавать веб-страницы с помощью Dart, но я не вижу в этом большого интереса. Единственный другой язык, который хорошо зарекомендовал себя в Интернете, — это TypeScript, поскольку он хорошо интегрируется с тремя наиболее популярными веб-фреймворками.

Взгляните на другой синтаксис, доступный для React в Интернете:
https://github.com/Workiva/over_react#fluent-стиль-компонент-потребление
У обеих версий Dart нет шансов против JSX!!!

TypeScript был разработан для компиляции в Javascript, и для этого он лучше, чем Dart. Он также поддерживает JSX.
Дротик сжимается со всех сторон. У Swift есть импульс, поэтому разумно поддерживать его на ОС Fuchsia вместе с вашим ребенком.

Сколько осталось до прототипа? Я хотел бы использовать его!

Некоторое время я использовал React, и JSX увеличил мою производительность в десять раз. Это не спорный вопрос: другие команды правильно решили, что так будет лучше, так почему бы не Flutter? (риторический: я читал ветку... (фейспалм))

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

Некоторые из интересных вещей, с которыми я экспериментирую:
1) используя пространство имен xml для дочерних тегов, чтобы они были вставлены с правильным именованным аргументом Dart в родительском.
2) оператор распространения для лучшей организации стилей, таких как свойства, чтобы их можно было определить/сгруппировать вне xml на карте, а затем ввести и распространить по тегу, как типичный материал React.
3) свойство styleCSS, которое генерирует стили флаттера из CSS.

(1) и (2) являются общими, поэтому работают для всего кода Dart Flutter.
(3) специализируется на виджете Flutter (контейнер, текст и т. д.), и я пока делаю только эти 2.

@yuriy-manifold только потому, что что-то сработало для JS, не означает, что это хорошая идея для Dart.
Если бы вы читали приведенные выше обсуждения, вы бы увидели, что на самом деле это спорно.
Я не понимаю, почему 2 языка лучше, чем один.

то, что что-то сработало для JS, не означает, что это хорошая идея для Dart.

JSX — невероятная идея для разработки UI/UX в реактивной среде независимо от языка. Если бы у меня было больше свободного времени, я бы выпустил LSX, который является JSX для логотипа;)

Я не понимаю, почему 2 языка лучше, чем один.

Вы можете программировать iOS с помощью Objective-C и Swift (2 языка)
Вы можете программировать Android с помощью Java и Kotlin (2 языка)
...

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

@cbazza

Вы можете программировать iOS с помощью Objective-C и Swift (2 языка)
Вы можете программировать Android с помощью Java и Kotlin (2 языка)

Как это связано с обсуждением JSX? Как это можно считать преимуществом?
Вы можете использовать Swift на iOS, потому что это преемник Objectiv-C.
Вы можете использовать Kotlin на Android, потому что он считается отличным улучшением Java.
Похоже, вы утверждаете, что JSX должен заменить Dart. Это не имеет большого смысла для меня.

@зоэчи

Как это связано с обсуждением JSX? Как это можно считать преимуществом?
Вы можете использовать Swift на iOS, потому что это преемник Objectiv-C.
Вы можете использовать Kotlin на Android, потому что он считается отличным улучшением Java.
Похоже, вы утверждаете, что JSX должен заменить Dart. Это не имеет большого смысла для меня.

На самом деле вы сказали это (JSX — это заметное улучшение по сравнению с текущим способом), но пришли к неправильному выводу (JSX заменяет Dart).

@cbazza это почти то же самое

в чем реальное преимущество перед простым Dart?

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

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

Добавление чего-то вроде JSX в Dart требует очень много работы и сложности в инструментах Flutter и IDE. Вы должны предоставить надлежащие аргументы, чтобы другие даже рассмотрели возможность взглянуть на это.

@zoechi звучит как заезженная пластинка, требующая «хороших» аргументов, раньше было дано много, но вы просто не поняли; это нормально, "каждому свое".

Добавление чего-то вроде JSX в Dart требует очень много работы и сложности в инструментах Flutter и IDE. Вы должны предоставить надлежащие аргументы, чтобы другие даже рассмотрели возможность взглянуть на это.

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

Опять же, DSX — это просто приятное улучшение, которое люди могут использовать или нет, потому что оно не меняет текущий способ, а просто предоставляет альтернативу, с которой другие (разработчики React) сразу же узнают.

@cbazza

много было дано

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

Не совсем, моя работа почти готова

Здорово. Тогда команде Flutter не нужно ничего делать, и проблема может быть закрыта ;p
Включает ли это поддержку автозаполнения и проверки синтаксиса во всех IDE, поддерживаемых Flutter?

Здорово. Тогда команде Flutter не нужно ничего делать, и проблема может быть закрыта ;p

;)

Включает ли это поддержку автозаполнения и проверки синтаксиса во всех IDE, поддерживаемых Flutter?

Большинство IDE уже поддерживают XML и JSX, поэтому им не составит труда добавить мои небольшие дополнения.

Интересно, может ли синтаксис JSX быть более ценным в angular Dart? Похоже, это скорее ситуация, к которой вы привыкли, а не «лучше». Синтаксис JSX, вероятно, кажется более естественным для веб-разработчиков.

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

https://blog.dantup.com/2014/08/you-have-ruined-html/

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

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

Время пришло...
С большим удовольствием объявляю об онлайн-транспиляторе DSX.
https://spark-heroku-dsx.herokuapp.com/index.html

Хорошая работа с транспилером cbazza
Я бы сказал, что с JSX легче следовать закрывающим тегам. Идея, которую я упоминал ранее:
Идея: Автоматически генерируемые закрывающие теги

В вашем первом примере будет указан флаттер-код (удален необязательный новый в будущем Dart):

Material(
  child: Column(
    children: <Widget>[
      MyAppBar(
        title: Text(
          'Example title',
          style: Theme.of(context).primaryTextTheme.title,
        )-Text,
      )-MyAppBar,
      Expanded(
        child: Center(
          child: Text(
            'Hello, world!',
          )-Text,
        )-Center,
      )-Expanded,
    ],
  )-Column,
)-Material;

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

Как новичок во Flutter, но хорошо знакомый с React, я выделил несколько моментов:

• Модель управления состоянием практически одинакова.
• Дерево виртуального рендеринга виджета/компонента почти такое же.
• Зная модель состояния и компонентов, я чувствую, что уже сейчас готов написать приложение, за исключением некоторых особенностей Dart и API-интерфейсов платформы, но...
• Язык стилей является камнем преткновения. Я имею в виду https://flutter.io/web-analogs/ , но не так просто понять, какие импорты необходимы для работы (EdgeInset? Color?) или когда мне следует использовать примитивы вместо экземпляров классов.
• Парсер CSS из DSX-конвертера @cbazza действительно полезен для определения эквивалентов макета в модели Flutter.

Относительно JSX:

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

<Item
  right={() => new Text("Right")} {/* a named slot */}
  left={() => new Text("Left")}> {/* another named slot */}
  <ChildOne /> {/* generic children prop with 2 children */}
  <ChildTwo>
    <NestedChild />
  </ChildTwo>
</Item>

• Лучшим аргументом против JSX, который я видел, было то, что у Dart есть именованные аргументы.
• Почему для элемента важно знать, есть ли у него несколько дочерних элементов или один дочерний элемент? Возможно, конструкция «фрагмент» могла бы устранить неоднозначность этого API.

Я все еще думаю, как новичок во Flutter с некоторым опытом работы с Angular, React и т. Д., Что обычный способ Dart и многое другое в Dart 2.0 лучше, чем этот DSX. Это просто имеет больше смысла, чем некоторые параметры XML и CSS. 🤷‍♂️

@cbazza в вашем втором демонстрационном примере 466 символов по сравнению с 391 в дротике (оба без пробелов). Мне он кажется визуально раздутым. Мне пришлось бы изучить его семантику, чего мне не нужно с обычным кодом Dart. И я понятия не имею, как использовать с ним парадигмы программирования общего назначения (if, forEach и т. д.).

Если бы у меня был выбор, я бы остановился на этой модели.

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

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

Если людям сейчас действительно нужен синтаксис, подобный JSX, усилия сообщества кажутся подходящим вариантом. И это поможет сделать дело (или нет), когда команда Flutter рассмотрит его в выпуске после 1.0.

Лично я полностью согласен со следующим аргументом: не потому, что JSX работает для React (где вы уже создаете пользовательский интерфейс с помощью языка разметки), он автоматически работает для Flutter.

@tehfailsafe

Хорошая новость заключается в том, что даже если это было принято командой Flutter (что вряд ли основано на этой ветке), никто не был бы ЗАСТАВЛЕН использовать его. Это ВАРИАНТ. Я не понимаю, почему это так эмоционально заряжено, что некоторым людям может нравиться писать код с синтаксисом, который вам не нравится...

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

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

Это потому, что Интернет не был разработан для такой системы. Если у вас есть статический язык разметки, такой как HTML, и вы хотите «динамизировать» его, вам нужно изобрести систему, которая должна работать поверх него. В итоге вы получите некую конструкцию, ограниченную базовой платформой.
(см.: https://gbracha.blogspot.de/2014/09/a-domain-of-shadows.html)

С другой стороны, у Flutter нет языка разметки. Я еще не видел причин вкладывать ресурсы в что-то менее динамичное и менее выразительное.

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

Кроме того, спасибо @cbazza :)

@yuriy-многообразие

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

Вопрос не в том, полезен ли JSX для React? вопрос: «Полезно ли что-то вроде JSX для Flutter?».

Я думаю, что нет.

Есть еще несколько вещей, которые следует учитывать:

• Отделение спецификации макета от кода приложения может сделать код более перспективным; например, это предложение по синтаксису Dart 2 не повлияет на методы build , если они будут преобразованы в соответствии с обновляемой прагмой в код Dart из независимого формата, такого как JSX.
• Определение макета как разметки позволяет отделить движок рендеринга от движка виджетов (с сохранением состояния/виртуализации) в духе отношений React с ReactDOM и React Native, потенциально упрощая перенос виджетов на новые платформы.
• Определение формата разметки упрощает перенос существующих макетов во Flutter, например, из Sketch или других инструментов дизайна.

Хорошая работа с транспилером cbazza

@Rockvole , спасибо.

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

@zoechi , спасибо. Да, это просто еще один вариант для тех, кто любит JSX. Если это не ваше дело, продолжайте делать то, что вы делаете, здесь ничего не меняется.

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

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

Я все еще думаю, как новичок во Flutter с некоторым опытом работы с Angular, React и т. Д., Что обычный способ Dart и многое другое в Dart 2.0 лучше, чем этот DSX. Это просто имеет больше смысла, чем некоторые параметры XML и CSS.

@tenhobi , тогда это здорово, очевидно, DSX не для всех.

Если бы у меня был выбор, я бы остановился на этой модели.

@b-strauss, это не замена, это вариант для людей, которым нравится JSX.

Есть любовь и ненависть, но большинство мнений расходятся в пользе JSX по сравнению с простым Dart.

@lukaspili , DSX предназначен для людей с React Native, которые любят JSX, если вы не видите его преимуществ, не используйте его. Это не DSX против простого Dart. Это DSX против JSX, чем ближе 2, тем лучше.

Хорошая новость заключается в том, что даже если это было принято командой Flutter (что вряд ли основано на этой ветке), никто не был бы ЗАСТАВЛЕН использовать его. Это ВАРИАНТ. Я не понимаю, почему это так эмоционально заряжено, что некоторым людям может нравиться писать код с синтаксисом, который вам не нравится...

@tehfailsafe , спасибо, что выслушали!!! Вы попали в самую точку, почему такое огромное сопротивление чему-то, что сделает React Native людей действительно счастливыми.

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

@b-strauss, как только поклонники React Native перейдут на Flutter, появится множество людей, которые помогут с этими другими необходимыми вещами. Приоритет 1 — украсть долю разума у ​​React Native и сделать его максимально простым для людей, работающих с React Native.

С другой стороны, у Flutter нет языка разметки. Я еще не видел причин вкладывать ресурсы в что-то менее динамичное и менее выразительное.

@b-strauss, почему DSX «менее динамичен» и «менее выразителен», чем обычный Dart? DSX - это Dart, вы не пробовали транспайлер.

@yuriy-manifold, спасибо.

Вопрос не в том, полезен ли JSX для React? вопрос: «Полезно ли что-то вроде JSX для Flutter?».

@b-strauss, конечно. это бесполезно для текущих разработчиков Flutter, но очень полезно для дизайнеров, которые могут выводить CSS из своих инструментов, это очень полезно для людей, использующих платформу React Native.

@alexkrolick , очень хорошие наблюдения.

@cbazza

это не замена, это вариант для людей, которым нравится JSX.

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

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

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

Почему DSX «менее динамичен» и «менее выразителен», чем простой Dart? DSX - это Dart, вы не пробовали транспайлер.

Каждая DSL по определению менее выразительна, чем GPL. Как с помощью DSX условно скрыть виджет? Как перебрать коллекцию и сопоставить каждый элемент с виджетом? Как использовать переключатель? Теперь вам нужно создать синтаксис и семантику для конструкций, которые уже есть в вашей GPL. Так зачем вообще изобретать DSL?

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

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

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

@b-strauss, чтобы быть ясным, JSX компилируется в вызовы функций (в React вызывает createElement(ComponentClass) , в Dart это должны быть конструкторы).

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

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

Единственными конструкциями являются преобразования между именами элементов + атрибутами и вызовами функций + аргументами, а также экранированные выражения ( {...} ).

• Как с помощью DSX условно скрыть виджет?

(JS)
  { condition && <A /> }
  { condition ? <A /> : <B /> }

• Как перебрать коллекцию и сопоставить каждый элемент с виджетом?

(JS)
  { ['a', 'b'].map(i => <A property={i} />) }

• Как использовать переключатель?
  Насколько я знаю, в Dart, как и в JS, вы не можете использовать встроенный переключатель, поскольку это не выражение. Если вы находитесь за пределами дерева виджетов, вы можете просто использовать переключатель в обычном режиме.

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

@b-strauss, React Native — это не веб-разработка, это кроссплатформенная мобильная разработка, которая является основным конкурентом Flutter; и да, JSX похож на источник света, он привлечет множество разработчиков React Native. Я попросил эту функцию в августе 2017 года, слишком много разговоров, слишком мало действий.

Каждая DSL по определению менее выразительна, чем GPL. Как с помощью DSX условно скрыть виджет? Как перебрать коллекцию и сопоставить каждый элемент с виджетом? Как использовать переключатель? Теперь вам нужно создать синтаксис и семантику для конструкций, которые уже есть в вашей GPL. Так зачем вообще изобретать DSL?

Вы совершенно неправы. Хорошая новость в том, что я когда-то тоже ошибался. Большинство (но не все) DSL пытаются воссоздать программные конструкции в разметке (и это не очень эффективно), JSX привносит разметку в программирование (используя все преимущества основного языка). Разница трансформационная. Ответ на все ваши вопросы в основном заключается в том, чтобы использовать то, как вы делаете это в Dart, потому что это Dart. Все, что находится между '{}', является кодом Dart, за исключением оператора расширения. Это все выражения дротика, но вы также можете использовать анонимные функции, которые возвращают выражение. Как вы видите в транспилере тег (\) — это просто новый элемент виджета (новый текст()).

Какие проблемы решит DSL, которые вы не можете решить прямо сейчас?

Зачем использовать Dart, если можно использовать нули и единицы, разве это не все, что необходимо для решения любой вычислительной задачи?

Вы продолжаете говорить, что это лучше, почему это лучше?

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

Я не сомневаюсь, что DSX привлечет некоторых людей, работающих с JSX. Я знаю, что людям не нравятся вещи, которые отличаются от других. И знакомство кажется единственным аргументом. Так почему бы не использовать CSS?
Почему бы не использовать JavaScript? Их знает больше людей, чем Dart.

Да, использование CSS имеет смысл для облегчения рабочего процесса дизайнера-разработчика. DSX поддерживает это. Преимуществом Dart перед Javascript является скорость выполнения (производительность).

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

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

@alexkrolick , спасибо за подробности.

@cbazza

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

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

@Б-Штраус

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

@cbazza Не могли бы вы отправить мне электронное письмо, пожалуйста? [email protected]

Уже сделал это предложение в старой теме, но я все еще думаю, что это важный момент

ИМХО, устранение необходимости использовать 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,
                    ),
          ),

Я согласен с тем, чтобы упростить флаттер, который не хочет использовать синтаксис, подобный JSX, и я также поддерживаю концепцию разделения на несколько виджетов, но теперь это позволяет мне почувствовать, что эра MVC вернулась в jquery. Такой сценарий, что был простой виджет, с отступами, рамкой и расположением по центру для него позже, многие символы "}" серьезно влияют на читабельность. Тем не менее, это цельный виджет, я не хочу его разбивать, любой полезный решение? Хотя мой английский плохой, я стараюсь выражать свои мысли.

Господи помоги нам всем.

Хорошо, это никуда не денется. Не похоже, что кто-то собирается перейти на другую сторону в ближайшее время. Здесь определенно нужно достичь какого-то компромисса. Конечно, «про-DSX» против «анти-DSX» на самом деле не имеет удовлетворительного компромисса, что вызывает разочарование. Можем ли мы переформулировать наши позиции, чтобы они были более совместимыми?

@naiveaiguy «они» могут получить свой DSX.
Если команда Flutter не реализует его, это может быть инициатива с открытым исходным кодом.
Это не означает, что подход с использованием только Dart, как сейчас, больше не будет работать.
Оба мира могут сосуществовать.

Я так согласен с @zoechi , что они могут сосуществовать... вот и все, и я думал, что это было решено в старой теме

@лрн

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

Браво, это точно.

В React вы можете сделать это 4 способами (и я только сегодня узнал о других 2 способах!!!)

(1) Вы можете использовать JSX (это то, что мне нравится)
https://reactjs.org/docs/introduction-jsx.html

(2) Вы можете использовать оригинальный способ (который похож на Flutter)
https://reactjs.org/docs/реакт-без-jsx.html

В конце ссылки выше даже упоминаются 2 перспективных проекта сообщества

(3) Синтаксис гиперскрипта для разметки React.js
https://github.com/mlmorg/реагировать-гиперскрипт

(4) Краткий синтаксис гиперскрипта.
https://github.com/ohanhi/гиперскрипт-помощники

Иметь альтернативы - это хорошо, прошли те времена, когда вы могли получить Форд любого цвета, который вам нравился, если он был черным :)

@naiveaiguy , почему для вас это проблема, если есть текущий подход и DSX?
(это то, что я получаю от ваших отрицательных голосов)

@naiveaiguy «они» могут получить свой DSX.
Если команда Flutter не реализует его, это может быть инициатива с открытым исходным кодом.
Это не означает, что подход с использованием только Dart, как сейчас, больше не будет работать.
Оба мира могут сосуществовать.

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

Наличие альтернатив — это хорошо, прошли те времена, когда вы могли получить Ford любого цвета.
нравится, пока черный :)

Правда что. Тем не менее, я думаю, мы все можем согласиться с тем, что мы не хотим, чтобы Dart/Flutter стал еще одной экосистемой JS/Web Frontend. Flutter еще даже не вышел из бета-версии, и мы уже хотим, чтобы у него было 2 стандарта для чего-то вроде субъективного.

В React вы можете сделать это 4 способами (и я только сегодня узнал о других 2 способах!!!)

Большинство из них управляются сообществом, хотя React ссылается на них. Хорошая середина. Сейчас официально поддерживаются только 2 из них: React.createElement и способ JSX, который является оболочкой над другим. Ценность JSX печально известна в этом контексте, но здесь она не так очевидна. Имея это в виду, можем ли мы достичь середины пути, имея только один официальный стандарт и документы, ссылающиеся на DSX, когда это уместно?

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

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

@zoechi Лично я не верю, что эти две идеи могут сосуществовать в нынешнем состоянии Flutter — нам действительно не следует поощрять раскол такого рода так рано — но на данный момент это выглядит как единственный компромисс.

@naiveaiguy

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

Не могли бы вы уточнить, почему они не могут сосуществовать? (учитывая тот факт, что DSX - это просто синтаксический сахар, или, как говорит @emalamela , «просто оболочка текущего пути»).

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

@emalamela

Тем не менее, я думаю, мы все можем согласиться с тем, что мы не хотим, чтобы Dart/Flutter стал еще одной экосистемой JS/Web Frontend.

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

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

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

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

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

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

Да, 44 Mio сочли это достаточно важным, чтобы проголосовать :D

Да, 44 счел это достаточно важным, чтобы проголосовать :D

Однако при сортировке по «голосу за» этот запрос функции занимает 7-е место в списке из 3131 открытых заявок.

https://github.com/flutter/flutter/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

@cbazza Я не хочу возражать против этой функции, но комментарии типа «если вы не сделаете x, то случится ужасно y» просто смешны.

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

@sonaye

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

Однако при сортировке по «голосу за» этот запрос функции занимает 7-е место в списке из 3131 открытых заявок.

@cbazza

Он также является самым отрицательным. Это довольно спорно.

@emalamela ,

Он также является самым отрицательным. Это довольно спорно.

Поскольку этот запрос функции является альтернативой текущему способу и не меняет текущий способ, вообще не должно быть никаких разногласий; если вам не нравится JSX/DSX, продолжайте программировать, как вы это делаете сегодня.

Так называемые разногласия существуют только потому, что команде Flutter нужно проделать работу, чтобы сообщество могло правильно использовать DSX. Если бы инструменты Flutter (компилятор, анализатор, поддержка ide и т. д.) поддерживали предварительную обработку с исходными картами, DSX был бы сделан давно, и, скорее всего, произошли бы и другие языковые инновации/идеи от сторонних разработчиков.

new Card(
  child: Column(
    crossAxisAlignment: CrossAxisAlignment.start,
    children: <Widget>[
      AspectRatio(
        aspectRatio: 18 / 11,
        child: Image.asset('assets/diamond.png'),
      ),
      new Padding(
        padding: EdgeInsets.fromLTRB(16, 12, 16, 8),
        child: Column(
          crossAxisAlignment: CrossAxisAlignment.start,
          children: <Widget>[
            Text('Title'),
            SizedBox(height: 8),
            Text('Secondary Text'),
          ],
        ),
      ),
    ],
  ),
)

Становится:

<Card>
  <Column crossAxisAlignment={CrossAxisAlignment.start}>
    <AspectRatio aspectRatio={18 / 11}>
      <Image src={asset('assets/diamond.png')} />
    </AspectRatio>

    <Padding padding={EdgeInsets.fromLTRB(16, 12, 16, 8)}>
      <Column crossAxisAlignment={CrossAxisAlignment.start}>
        <Text>Title</Text>
        <SizedBox height={8} />
        <Text>Secondary Text</Text>
      </Column>
    </Padding>
  </Column>
</Card>

@emalamela Аргументы за и против JSX исчерпаны обсуждением, есть много материала, который вы можете найти. Я лишь делюсь своим личным мнением.

Во-первых, читабельность кода. Я могу сразу получить четкое представление о структуре пользовательского интерфейса в JSX (занимает секунды), мысленный модальный режим очень нагляден. Во-вторых, удобство использования. Я бы сказал, что JSX можно использовать, даже не зная JS/Dart или чего-то еще о базовом API. Это очень подходит для тех, кто только изучает программирование, или для тех, кто является частью моей команды, дизайнеры теперь могут кодировать пользовательский интерфейс.

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

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

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

Вы можете сказать, что JSX (или DSX в данном случае) имеет большое значение, просто посмотрев количество комментариев в этом выпуске.

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

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

И, как @eseidelGoogle (https://youtu.be/h7HOt3Jb1Ts?t=2m41s) сказал другому парню: «Flutter — это способ писать для iOS и Android в единой кодовой базе. Мы стараемся сделать это быстро и легко [. ..] Flutter говорит вплоть до аппаратного обеспечения [...] У нас очень многоуровневый подход, поэтому вы можете брать столько, сколько хотите. [...] У нас есть куча инвестиций в инструменты ."

Реализуйте JSX, пожалуйста.

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

@rajaraodv Тот факт, что Flutter продвигается как фреймворк реактивного стиля, не означает, что это просто разновидность ReactJS.
Из большинства комментариев у меня сложилось впечатление, что людям просто трудно принять, что что-то новое не совпадает с тем, что они уже знают.

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

@zoechi , вы что-то упускаете: согласно документу Flutter, вдохновением для создания флаттера послужил React.
Может быть, это только моя проблема. Я действительно чувствую, что мне трудно читать код пользовательского интерфейса, даже если он в синтаксисе Dart 2.

флаттер был вдохновлен React Native

Я не понимаю, как это говорит «все то же самое, за исключением того, что язык называется Flutter вместо JS».

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

и вы утверждаете, что единственным вообразимым решением этой проблемы является DSX?

Думали ли вы, что Flutter даже не 1.0 и что поддержка IDE со временем может улучшиться?

Недавно были предприняты только первые крошечные шаги для улучшения поддержки Flutter IDE в редакторе кода, такие как быстрые исправления («wrap xxx») и закрывающие метки.

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

@зоэчи ,

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

Опять же, Plain Dart или DSX — это просто вопрос стиля, и нет смысла спорить, что лучше. Это просто личное предпочтение, и у людей есть свои причины выбирать тот или иной.

Что произошло в мире React, так это то, что, перейдя на JSX, вы просто не вернетесь назад. Как уже говорилось выше, вы подсаживаетесь на JSX после некоторого использования. JSX был принят другими за пределами мира React (Typescript, Vue), и он отлично подходит для Flutter.

и вы утверждаете, что единственным вообразимым решением этой проблемы является DSX?

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

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

Конечно, дело в том, что этот тикет не об общем «улучшении опыта разработчиков». Это очень специфично, и речь идет о поддержке JSX во Flutter. Сообщество хочет использовать DSX как альтернативу обычному Dart.

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

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

Мне неизвестны какие-либо препятствия, мешающие кому-либо, не входящему в команду Google Flutter/Dart, написать что-то похожее на JSX для Dart/Flutter. Я хотел бы видеть ошибки на тех, если кто-то пытается. (Возможно также, что я пропустил их в комментариях выше, так как я признаю, что не прочитал каждое слово этой очень длинной ошибки.) :)

Спасибо! Рад видеть такой энтузиазм!

@seidelGoogle ,

Как Intellij и/или VS Code (с Dart-Code) смогут устанавливать точки останова и выполнять код из файла .dsx? (Я имею в виду, что это не файл .dart). Как насчет функции автозаполнения из файла .dsx (как в случае с файлом .dart)?

Вы много вложили в инструменты, но они не поддерживают предварительную обработку (с исходными картами) нового языка (например, DSX), который легко транспилируется в Dart/Flutter.

Транспайлер доступен, но нет простого способа полностью его интегрировать:
https://spark-heroku-dsx.herokuapp.com/index.html

PS В этом билете только половина комментариев!!!
https://github.com/флюттер/флаттер/issues/15922

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

@jonahwilliams , нет, код транспилятора DSX не был выпущен, потому что для этого еще слишком рано.
Вы можете просто использовать 2 рукописных эквивалентных файла (.dsx и .dart), чтобы проверить возможности предварительной обработки, такие как точки останова, пошаговое выполнение, автозаполнение и т. д.

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

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

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

Если вы сгенерировали исходные карты (https://pub.dartlang.org/packages/source_maps), я полагаю, что получить хотя бы некоторую базовую поддержку в IDE довольно тривиально, независимо от Dart/Flutter. Но опять же, это все предположения, без знания того, что делает ваш инструментарий и как вы ожидаете, что он будет работать.

@matanlurey поддержка предварительной обработки с помощью исходных карт - это общий механизм, который не зависит от какого-либо конкретного транспилятора. Это функциональность, предназначенная для поддержки любого будущего языка, который только можно вообразить. Браузер/отладчик Chrome прекрасно его поддерживает, и я могу отлаживать любой язык, транслируемый в JS.

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

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

В настоящее время Flutter не хочет угождать NativeScript, ReactNative, Android, Web и другим разработчикам, которые привыкли к похожим макетам XML. У них есть дела поважнее, так что давайте расформируемся и пойдем спать.

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

@escamoteur
Эй, эскамотер. Вы думаете, что я не потратил много времени на изучение флаттера?
В flutter.io/tutorials/layout/, в конце раздела «Упаковка виджетов», код, который дал туториал, не работает.
Я упомянул эту проблему в блоке проблем с флаттером, но никто не хочет об этом заботиться.

• Код дротика: main.dart
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/main.dart

• Спецификация: pubspec.yaml
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/pubspec.yaml

• https://flutter.io/tutorials/layout/

@JonathanSum есть ли связь между вашим комментарием и темой этого выпуска?

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

Group Dart: «Синтаксис Dart намного лучше, а JSX/DSX просто не годится»
Группа JSX/DSX: «Синтаксис JSX/DSX намного лучше, а Dart просто не годится»

Я не могу быть единственным, кто это увидит? Обе стороны приводят веские доводы в пользу и против своей позиции. Я думаю, что здесь упущено то, что @cbazza не только критиковала, НО ТАКЖЕ ЧТО-ТО СДЕЛАЛА С ЭТИМ. Попытка преодолеть разрыв между веб-разработчиками/реагированием/реагированием и флаттером, чтобы принести пользу флаттеру.

И мои 2 цента... Как разработчик с полным стеком, у меня есть опыт работы с широким спектром языков и подходов... JSX - один из моих любимых способов написания кода, и я надеюсь, что будет альтернативный синтаксис для Darts.. , И я не говорю, что текущий синтаксис плохой, просто я предпочитаю стиль JSX.

Я должен не согласиться с этой цитатой из группы JSX/DSX

Дарт просто не годится

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

• Android имеет макеты XML.
• iOS имеет раскадровку XIB (XML)
• GTK+ имеет XML для Pango и т.д.
• Qt имеет QML (например, YAML)
• Xamarin имеет XAML

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

...

Неужели это настолько безумное предложение, что мы должны получать такие отзывы от команды/пользователей Flutter?

@birkir и все они приносят массу неприятностей, которых у Flutter нет \o/
Нет необходимости в другом языке.
Вы также можете разделить представление во Flutter, даже с одним и тем же языком.

@birkir эта ветка на 100% посвящена Dart и синтаксису.

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

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

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

Я рад, что есть еще один кроссплатформенный вариант… Apple будет следующей, кто предложит что-то? И, может быть, они увидят, что многим из нас нравится в react/react-native? IDK, если у них есть что-нибудь готовящее.

команда Flutter увидела этот отзыв (при запросе подхода JSX/DSX), и они

Эта ошибка все еще открыта, потому что мы не поняли, что мы хотим здесь делать. Мы с нетерпением смотрим на эксперименты (например, cbazza), чтобы увидеть, как люди их используют. В какой-то момент мы планируем добавить в систему сборки крючок для таких инструментов codegen, хотя вряд ли мы сделаем это в ближайшем будущем. В долгосрочной перспективе мы надеемся использовать полученные знания, чтобы повлиять на развитие Dart как языка. Это может означать добавление чего-то вроде E4X/H4X/JSX/DSX в сам Dart. Или, может быть, мы узнаем, что никто на самом деле не использует его, поэтому мы ничего не будем делать. Или, может быть, каждому нужно что-то свое, поэтому ответом будут хуки codegen и пользовательские пакеты, такие как cbazza. Мы еще не знаем.

@jstansbe - Apple считает, что кроссплатформенность означает IPhone, iPad и Mac OS. Они скорее добавят турели поверх обнесенного стеной сада, чем построят что-то кроссплатформенное :)

Я думаю, что если бы было возможно отступ и форматирование виджета другим способом, он был бы более похож на jsx и был бы удобен для пользователей, имеющих опыт работы с xml и html (почти все разработчики Android)... проверьте этот код в codelab

return new Container(
    margin: const EdgeInsets.symmetric(horizontal: 8.0),
    child: new Row(
      children: <Widget>[
        new Flexible(
          child: new TextField(
            controller: _textController,
            onSubmitted: _handleSubmitted,
            decoration: new InputDecoration.collapsed(
              hintText: "Send a message"),
          ),
        ),
        new Container(                                                 //new
          margin: new EdgeInsets.symmetric(horizontal: 4.0),           //new
          child: new IconButton(                                       //new
            icon: new Icon(Icons.send),                                //new
            onPressed: () => _handleSubmitted(_textController.text)),  //new
        ),                                                             //new
      ],
    ),
  );

проверьте этот дротик на код jsx

<Container margin="">
   <Row>
       <Flexible>
            <TextField   controller=""
                                onSubmitted=""
                                decoration="">
                 <OtherWidget></OtherWidget>

            </TextField>
        </Flexible>
   </Row>
</Container>

и сравните с этим другим форматом, более htmlish

  return Container(margin: const EdgeInsets.symmetric(horizontal: 8.0), child:
            Row(children: <Widget>[
                Flexible(child:
                    TextField(controller: _textController,
                              onSubmitted: _handleSubmit,
                              decoration: new InputDecoration.collapsed(hintText: "manda un mensaje"),),
                    ),
                Container(margin: const EdgeInsets.symmetric(horizontal: 4.0),child:
                     IconButton(icon: Icon(Icons.send),
                               onPressed: ()=>_handleSubmit(_textController.text),),)
              ],
            )
    );

это немного больше похоже, и теперь вам нужно только смотреть слева направо, чтобы заметить различные виджеты, похожие на html/xml/jsx.

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

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

После прочтения всех комментариев здесь и частного обсуждения с моими друзьями (разработчиками мобильных приложений, java/kotlin/objective-c/swift), мое наблюдение:

Люди просят о двух вещах,

• __Лучшая читаемость и более легкое написание__. Глубокая вложенность, смешанная с некоторыми синтаксическими шумами (круглые скобки, точка с запятой, new , child , children ), раздражает в текущем способе кодирования.
• __Отдельный стиль/дизайн от кода__. Визуальное разделение полезно для чтения (отличить стиль от императивного кода с первого взгляда), а реальное разделение полезно для инструментов (например, IDE с редактором макетов).

Есть также в основном две группы с разными мнениями,

• Улучшение текущего синтаксиса без добавления дополнительных сложностей для решения проблемы.
  В этом направлении уже есть некоторые улучшения. Например, дополнительные new , const в Dart 2.0 и предлагаемая функция virtual "closing tag" comments .
• Внедрение дополнительных языков разметки (например, JSX или XML) для решения проблемы.

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

Комментарии виртуального закрывающего тега @hooluupog уже давно работают в IntelliJ, AS, VSCode.

@Хикси

Эта ошибка все еще открыта, потому что мы не поняли, что мы хотим здесь делать. Мы с нетерпением смотрим на эксперименты (например, cbazza), чтобы увидеть, как люди их используют.

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

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

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

Это может означать добавление чего-то вроде E4X/H4X/JSX/DSX в сам Dart.

Прочтите верхние абзацы спецификации JSX, чтобы убедиться, что нет необходимости менять язык Dart, поскольку JSX/DSX не имеет семантики и не предназначен для реализации движками или включения в языки. Он предназначен для использования в препроцессоре (транспиляторе). DSX можно использовать с Flutter и в Интернете, чтобы сделать React-Dart точно таким же, как React.js, но с языком Dart.

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

Или, может быть, мы узнаем, что никто на самом деле не использует его, поэтому мы ничего не будем делать.

Как люди могут использовать то, что им изначально недоступно, а затем сделать вывод, что ничего не нужно делать, потому что люди этим не пользуются? Это так сильно напоминает мне подражание Шону Спайсеру Мелиссы Маккарти на SNL о «запрете на поездки»… «круговое использование слова» :)

https://www.youtube.com/watch?v=1Dvo6EHEJQE&t=48s

Или, может быть, каждому нужно что-то свое, поэтому ответом будут хуки codegen и пользовательские пакеты, такие как cbazza. Мы еще не знаем.

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

Люди не могут использовать мои эксперименты

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

Не могли бы вы уточнить сроки, когда мы можем ожидать каких-либо изменений в системе сборки?

Не совсем (см., например, https://en.wikipedia.org/wiki/Forward-ooking_statement , почему такие заявления могут быть трудными), но, вероятно, не в ближайшие недели.

нет необходимости менять язык Dart

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

Добавить JSX в бэклог и позволить ему конкурировать, как гладиатор, с миллионом плюс одним другим срочным требованием?

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

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

Если мы хотим уменьшить многословие, я предпочел бы черпать вдохновение, например, у Анко (https://github.com/Kotlin/anko/wiki/Anko-Layouts). Там вы можете определить новые локальные переменные в любом месте и использовать обычные циклы for для динамического построения списка дочерних элементов, что может упростить выполнение кода. Кроме того, LayoutBuilder стал бы проще для глаз, поскольку каждый уровень вложенности в любом случае уже является лямбда-функцией (нет необходимости передавать дополнительную лямбда-построитель). В любом случае, это просто для вдохновения, и я не думаю, что Flutter следует копировать это 1:1.

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

React Native не является веб-разработкой и не использует HTML. Спросите опытных разработчиков React (или полностью прочитайте эту и другую ветку JSX), и вы увидите, что многие разработчики React считают JSX лучшим способом написания пользовательских интерфейсов.

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

Это утверждение ясно демонстрирует, что вы не знаете JSX. JSX (как и DSX) использует все программные конструкции (циклы for и т. д.) из языка размещения (Javascript/Dart).

Этот тикет интересует только JSX-подобная функциональность, для других подходов (например, Anko) создайте свой собственный тикет для обсуждения там.

React Native не является веб-разработкой и не использует HTML. Спросите опытных разработчиков React (или полностью прочитайте эту и другую ветку JSX), и вы увидите, что многие разработчики React считают JSX лучшим способом написания пользовательских интерфейсов.

React появился задолго до React Native. Первоначальный дизайн JSX основан на рендеринге HTML, а не на собственных пользовательских интерфейсах. Никто не смог привести ни одного убедительного аргумента в пользу того, что JSX делает лучше. Сравнивая

new Scaffold(
  appBar: new AppBar(
    title: new Text(widget.title),
  ),
  body: new Column(
    child: ...,
  ),
)

к

<Scaffold
    appBar={<AppBar title={<Text>{widget.title}</Text>} />}
  >
  <Column>
    ...
  </Column>
</Scaffold>

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

Scaffold(
  appBar: AppBar(title: Text(widget.title)),
  body: Column(
    child: ...,
  ),
)

Обратите внимание, как исчезли все уродливые {<{<>} />} и закрывающие теги </...> .

Это утверждение ясно демонстрирует, что вы не знаете JSX. JSX (как и DSX) использует все программные конструкции (циклы for и т. д.) из языка размещения (Javascript/Dart).

Нет, вы не можете использовать операторы if или циклы for (или оператор switch или любой другой оператор) в JSX:

function render(data) {
  return (
    <div>
      // This is impossible
      let total = 0;
      for (let item of data.list) {
        total += item.value;
        <div>{ total }</div>
        <div>{ item.name }</div>
      }
    </div>
  )
}

Допускаются только выражения. Таким образом, вы должны использовать условные операторы ( c ? x : y , что делает else if очень уродливым) и Array.map и т. д. (что также может быть очень уродливым) или переместить части вашего кода в в верхней части функции рендеринга или в отдельную вспомогательную функцию. То же самое и с Flutter, конечно. Anko не имеет этого ограничения и делает написание (некоторого) кода пользовательского интерфейса более естественным.

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

React появился задолго до React Native. Первоначальный дизайн JSX основан на рендеринге HTML, а не на собственных пользовательских интерфейсах.

Первоначальный дизайн JSX основан на знакомом способе создания/манипулирования древовидными структурами, которые специально отображаются при работе с пользовательским интерфейсом; подумайте об иерархиях компонентов (https://facebook.github.io/jsx/), которые проявляются в веб-разработке, нативной разработке, любой разработке пользовательского интерфейса и т. д.

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

В том-то и дело, что мы не стремимся заменить текущий способ, мы стремимся добавить альтернативный способ, знакомый разработчикам React.

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

Нет, вы не можете использовать операторы if или циклы for (или оператор switch или любой другой оператор) в JSX:

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

function render(data) {
  return (
    <div>
      { ()=>{
        // This is *not* impossible
        let divs=[];
        let total = 0;
        for (let item of data.list) {
          total += item.value;
          divs.push(<div>{ total }</div>);
          divs.push(<div>{ item.name }</div>);
        }
        return divs;
      }() }
    </div>
  )
}

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

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

Кстати, попробуйте следующее на моем онлайн-транспиляторе по адресу:
https://spark-heroku-dsx.herokuapp.com/index.html

@<Scaffold>
  <appBar:AppBar>
     <title:Text [widget.title]/>
  </appBar:AppBar>
  <Column>
    {kids}
  </Column>
</Scaffold>@

и вы получаете:

--------new Scaffold(
--------  appBar: new AppBar(
--------    title: new Text(
--------      widget.title,
--------    ),
--------  ),
--------  child: new Column(
--------    child: kids,
--------  ),
--------);

DSX похож на JSX, но для Dart & Flutter, поэтому у него есть свои особенности, которые описаны по ссылке выше.

когда я вижу это, я получаю воспоминания от макетов xml из Android. Я не думаю, что это хорошая идея для реализации этого. Теперь, когда вам даже не нужно писать new и const , это выглядит даже лучше.

@charafau Можете ли вы поделиться примером/img/ссылкой на «разметки xml из Android», о которых вы говорите?

Нет, @wkornewald. Если «JSX стал популярным не потому, что это лучшее решение для написания пользовательских интерфейсов, а потому, что это лучшее решение для написания HTML», почему React до сих пор использует JSX для создания мобильных и настольных приложений? Даже ваше настольное приложение Github, кроссплатформенное мобильное приложение Walmart, приложение Tesla и Skype также созданы RN.

React не помещает цикл for в тег JSX, потому что концепция React связана с компонентом. Верхняя часть — это логика, а нижняя — JSX, и так всегда. Все разделено на множество компонентов и соединено вместе в большой компонент.

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

@JonathanSum

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

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

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

Не очень, много давали раньше, просто прочитал полностью обе ветки. Я упоминал эти 2 вещи раньше:
(1) Больше никаких «детских» и «детских» вещей
(2) легко манипулировать сторонними инструментами (разбирать, анализировать и регенерировать)

С помощью (2) вы можете улучшить разметку, чтобы делать то, что невозможно с помощью только Dart; например, оператор распространения DSX или создание многих параметров функций из меньшего набора.

Другие предоставили много хороших моментов, но я не копаю это для вас;)

(1) как уже упоминалось, такие вещи также могут быть изменены/улучшены в Dart, и уже обсуждались. Это просто не произойдет до выхода Dart 2.
Простое предположение, что DSX поддерживает всевозможные новые функции, а Dart — нет, на мой взгляд, не является справедливым аргументом.
(2) Я почти уверен, что это можно сделать и с Dart, и, конечно, уже есть парсер для Dart.

Другие предоставили много хороших моментов, но я не копаю это для вас;)

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

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

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

Дело в том, что прямо сейчас у Dart/Flutter везде есть шумные дочерние/потомки при создании виджета, а у XML/DSX нет. Прямо сейчас это очень веский аргумент в пользу использования DSX для удаления этого дочернего/дочернего шума. Можете ли вы просто принять это как веский аргумент? (только потому, что вы говорите, что Dart будет иметь это в будущем, это не делает аргумент недействительным).

Также фактом является то, что синтаксический анализ XML намного проще, чем синтаксический анализ полного языка Dart, и каждый язык имеет синтаксический анализатор XML, тогда как только у Dart есть полный и законченный синтаксический анализатор языка Dart. Вы видите, что это тоже веский аргумент?

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

Аргументы для необязательного синтаксиса DSX:

1) Подключить и привлечь больше разработчиков из React (веб- и нативных)
2) Лучший опыт переноса компонентов React Native в виджеты Flutter.
3) Обеспечивает согласованность дочерних/дочерних свойств в виджетах.
4) Читабельность кода (утвержденный аргумент)
5) Просмотр логического линтинга отдельно от дротика
6) Открывает мир инструментов для создания пользовательского интерфейса.
7) Открывает экосистему для препроцессоров

DSX +1

DSX +1

С удовольствием бы написал кучу плюсов и минусов, но, прочитав все эти комментарии, я чувствую, что буду повторять все снова и снова.
Перестаньте быть таким наивным и невежественным, никто не говорит, что вас ЗАСТАВЛЯЮТ писать пользовательские интерфейсы с использованием DSX, это просто вариант (лучшая альтернатива).
Есть причина, по которой вы можете писать JS 101203103 разными способами.

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

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

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

TLDR; если вы так сильно хотите DSX, напишите плагин-анализатор и принесите его в Dart самостоятельно. Интернет полюбит вас, вы получите тысячи звезд на Github и почувствуете, что это React. Беспроигрышный.

PS Я даже буду гоняться за тобой, чтобы сделать это

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

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

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

Если вы читали ветку, это была идея с первого дня. Мы просто хотим, чтобы поддержка flutter/dart сделала транспайлер.

TLDR; если вы так сильно хотите DSX, напишите плагин-анализатор и принесите его в Dart самостоятельно. Интернет полюбит вас, вы получите тысячи звезд на Github и почувствуете, что это React. Беспроигрышный.

Прочтите ветку, это уже было сделано @cbazza (плагин анализатора не поможет)

https://github.com/flutter/flutter/issues/11609#issuecomment -388484681

PS Я даже буду гоняться за тобой, чтобы сделать это

Здорово! Просто даже теорию того, как это будет работать, было бы интересно увидеть.

СГТМ. Значит, мы все ждем какой-то поддержки предварительной обработки.

Я предпочитаю синтаксис конструктора, чем передачу параметров через конструктор

<strong i="6">@override</strong>
Widget build(BuildContext context) {
    return container()
      .height(56.0)
      .padding(8.0)
      .decoration(BoxDecoration(color: Colors.blue[500]))
      .child(text("Hello world!")
                   .style(...)
                  .build());
}

как на https://fblitho.com/

Text.create(context)
    .text("Hello World")
    .textSizeDip(50)
    .build();

DSX +1

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

Учитывая, что практически невозможно убрать функции после их реализации, я бы предложил принцип предосторожности. Давайте посмотрим, как работают некоторые из новых синтаксических функций Dart 2, прежде чем вносить существенные изменения в способ создания приложений Flutter.

@wstrange
Я могу тебя понять. Раньше я был против JSX и смешивания js с xml/html... потом попробовал. После нескольких месяцев работы с React я влюбился в JSX. Два убийственных преимущества:

1. нет нового синтаксиса и утилит
2. больше нет передачи переменных, функций и т.д.

@wstrange ,

Учитывая, что практически невозможно убрать функции после их реализации,

Это не данность, кто бы мог подумать, что Google удалит MathML из Chrome?

Давайте посмотрим, как работают некоторые из новых синтаксических функций Dart 2, прежде чем вносить существенные изменения в способ создания приложений Flutter.

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

@Бессонов ,

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

@cbazza Я могу сказать то же самое о Flutter. Потратьте несколько недель на его использование, и вы не будете скучать по JSX.

Реакция говорит нам обо всем.

Как и сейчас, +1 почти вдвое больше, -1

@escamoteur ,
Да, очень справедливое заявление, но я провел много времени с Flutter и, безусловно, вижу ценность, которую DSX добавит к нему. Как заметил @leedstyh , фанаты DSX лидируют в гонке почти 2-к-1, что довольно удивительно, учитывая, что люди на этом форуме — люди Flutter.

У меня есть вопрос:

При использовании синтаксиса DSX мы неявно предполагаем, что вложенный дочерний элемент или дочерние элементы имеют тип Widget. Что, если мы хотим явно указать, что мы хотим, чтобы вложенный дочерний элемент/дочерние элементы были определенным подтипом виджета?

например, когда я хочу, чтобы дочерние элементы моего пользовательского виджета принимали только список контейнеров, я могу аннотировать дочерние элементы с помощью List<Container> , и IDE выдаст ошибку, как только я добавлю что-либо отличное от контейнера. Насколько я знаю, нет способа обеспечить безопасность типов, как это, при использовании dsx. Возможно, у нас может быть какая-то ошибка при компиляции приложения, но я думаю, что ошибка, возникающая при наборе текста, все же лучше.

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

@sandangel ,

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

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

В примере 2 по адресу https://spark-heroku-dsx.herokuapp.com/index.html , если бы действия были массивом «Контейнер» вместо «Виджета» по умолчанию, это выглядело бы следующим образом:

        <actions:children:Container>
            <IconButton 
                icon={new Icon(Icons.search)}
                tooltip='Search'
                onPress={null}
            />
        </actions:children:Container>

        <actions:*:Container>
            <IconButton 
                icon={new Icon(Icons.search)}
                tooltip='Search'
                onPress={null}
            />
        </actions:*:Container>

привет @cbazza , спасибо за ваш ответ.

Меня интересует ваше решение. Не злоупотребляем ли мы пространством имен xml, как описано в Пространствах имен w3shool-XML ?

Поскольку в нем указано, что пространство имен в основном используется для разрешения конфликта имен в XML-документе.

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

Можем ли мы иметь что-то лучше?

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

Приходя из React-native, я сначала поддерживал JSX-подобную реализацию, и мне не нравились вложенные объекты, но я начинаю получать удовольствие от ООП и вижу все как объект!

Людям, пришедшим из React-native, я настоятельно рекомендую этот плагин! https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer

@кларктанк
Можете ли вы расширить свой опыт с помощью react-native (JSX), Flutter (OOP) и вашего путешествия от одного к другому?

@cbazza Я думаю, что синтаксис шаблона angular соответствует семантике xml, и, насколько мне известно, между синтаксисом angular и документом xml нет конфликта.

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

<children<Container>>
  <Container/>
</children>

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

Я действительно чувствую, что команда Flutter создала текущий API специально для нового способа объявления пользовательского интерфейса, который, как они предполагали, лучше, чем JSX, и любые усилия, которые мы пытаемся связать синтаксис JSX с текущим API, просто делают его неестественным/неудобным в использовании.

Реакция говорит нам обо всем.

Как и сейчас, +1 почти в два раза больше -1

Это ничего не значит.

За исключением тех, кто наблюдает за всеми проблемами Flutter, они удваивают ту, которая попадает в эту проблему, потому что они уже привыкли к JSX (и явно ищут его). Так что это, скорее, означает, что _люди, которые хотят опыта, похожего на JSX, удваивают количество людей, просматривающих все выпуски, которые проголосовали -1_. (имхо, часть людей, голосующих +1, даже толком не пробовали флаттер)

@sandangel ,

Я думаю, что синтаксис шаблона angular соответствует семантике xml, и, насколько мне известно, между синтаксисом angular и документом xml нет конфликта.

Конечно, но JSX не использует пространство имен, поэтому это не интересная функция XML.

<children<Container>>
  <Container/>
</children>

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

Я действительно чувствую, что команда Flutter создала текущий API специально для нового способа объявления пользовательского интерфейса, который, как они предполагали, лучше, чем JSX, и любые усилия, которые мы пытаемся связать синтаксис JSX с текущим API, просто делают его неестественным/неудобным в использовании.

Нет ничего нового в том, как Flutter объявляет пользовательский интерфейс в коде. Возможно, использование DSX для вас неестественно/неудобно, но для разработчиков JSX это не так. JSX / DSX идеально подходит для Flutter, он подходит как перчатка, и если вам не нравятся перчатки, идите голыми руками;)

@a14n ,

Это ничего не значит.

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

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

DSX — это не XML, он похож на XML, поэтому ему не нужно следовать семантике XML.

Конечно, но JSX не использует пространство имен, поэтому это не интересная функция XML.

Я не уверен, но я прочитал некоторые из ваших комментариев выше и думаю, что вы упомянули узел JSX/XML взаимозаменяемо. Во всяком случае, лично я считаю, что использование пространства имен в качестве решения не идеально.

Просто сравните

<actions:children:Container>

</actions:children:Container>

и

actions: <Container>[]

синтаксис.

@sandangel ,

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

@ a14n голосование есть голосование, это точно означает.

Я уважаю ваше чувство, может быть, это правда. Но даже с обратным соотношением (1 к 2) это все равно означает 33% пользовательской базы. Можно ли сказать, что 33% — это маленькая доля?

люди, которым нужен JSX-подобный опыт

Да, некоторые смотрят. Это также означает, что _отсутствие JSX-подобного является одной из причин, по которой люди не выбирают flutter_.

Flutter нацелен на большее количество разработчиков, а не только на тех, кто читает все выпуски.

@jstansbe
Я программист-самоучка, и, как и большинство самоучек, я начал с Javascript.
Затем я начал изучать React и React-Native. Я думаю, что в последние годы, особенно после ES6, в Javascript был добавлен стиль ООП.

Поэтому такие люди, как я, не привыкли к стилю программирования ООП. Несмотря на то, что родные Component в React — это такие же классы, как Widgets во Flutter.

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

Лично я считаю, что чистое ООП больше подходит для больших проектов.

@кларктанк ,

Обсуждая компьютерные языки, вы должны знать о:
(1) Синтаксис — символы и слова, составляющие язык
(2) Семантика - значение этих символов и слов

Например, вызовы функций на многих языках выглядят следующим образом (т.е. имеют следующий синтаксис):

a = someFunction(param1, param2)

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

a = someFunction[param1, param2]

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

JSX как бы скрывает чистую картину ООП. По сути, он скрывает то, что происходит под капотом.

Совсем не так. JSX/DSX - это просто другой синтаксис для точно такой же вещи (семантика та же). В случае JSX теги XML просто создают компоненты React (так же, как вы можете сделать это в Pure Javascript). В случае DSX теги XML просто создают виджеты Flutter (так же, как вы можете сделать это в Pure Dart). Синтаксис другой, но он генерирует точно такое же, поэтому он идентичен под капотом.

Примечание. React был разработан для веб-разработчиков, а веб-разработчики привыкли к синтаксису html. Вот почему JSX так популярен среди веб-разработчиков.

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

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

// Using JSX to express UI components.
var dropdown =
  <Dropdown>
    A dropdown list
    <Menu>
      <MenuItem>Do Something</MenuItem>
      <MenuItem>Do Something Fun!</MenuItem>
      <MenuItem>Do Something Else</MenuItem>
    </Menu>
  </Dropdown>;

render(dropdown);

Лично я считаю, что чистое ООП больше подходит для больших проектов.

Как так? (учитывая, что использование JSX/DSX или Pure Javascript/Dart под капотом генерирует точно такое же).

@cbazza

Я использовал react-native почти год и понятия не имел, что элементы JSX — это объекты, которые создаются, пока я не начал с Flutter/Dart. С моей точки зрения, он скрывает картину ООП, хотя, как вы сказали, семантически он делает то же самое под капотом!

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

@кларктанк ,

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

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

(Заранее извиняюсь за стену текста.)

Как человек, который не использовал ни React-Native, ни Flutter достаточно долго, чтобы считать себя окончательным источником того, что «лучше» — необработанный Dart или JSX/DSX, эту ветку проблемы было довольно интересно читать. Однако есть пара вещей, на которые я хотел бы поставить свои 0,02 доллара.

Для начала я поймал себя на том, что согласен с разными людьми в отношении того, чем на самом деле является JSX и какую пользу он приносит разработчикам. Прежде всего, JSX был разработан как форма «динамического HTML», которую можно было встроить в существующий код Javascript. Это незаменимо для веб-платформ на основе JS, таких как React, поскольку позволяет веб-разработчикам чисто и эффективно взаимодействовать с DOM без необходимости бороться с ужасным нативным способом (или чуть лучшим способом jQuery). Кроме того, по самой своей природе JSX поощряет разработку пользовательского интерфейса, который можно легко отделить от базовых данных, способствуя хорошо организованной структуре проекта. В такой среде JSX — это инструмент для повышения производительности, и мне кажется, что с этим практически невозможно поспорить.

Как этот абзац относится к React-Native, так это то, что, несмотря на то, что это платформа для мобильной разработки, она является прямым потомком React. Таким образом, почти весь синтаксис и парадигмы изначально создавались с учетом веб-разработки. Это сделано по замыслу — вся фишка RN в том, что вы можете «создавать кроссплатформенные мобильные приложения с помощью React», поэтому при его использовании _supposed_ похоже на веб-разработку. Приложения RN также преимущественно написаны на Javascript, поэтому включение JSX является естественным. JSX помогает в разработке RN почти по тем же причинам, что и в веб-разработке. (Я действительно думаю, что это одна из основных причин того, что, по крайней мере, в RN подход JSX используется намного чаще, чем нативный подход. Сама RN просто _чувствует_ себя как веб-платформа, поэтому более естественный для Интернета подход неизбежно уходит в прошлое. стать преобладающим.)

С другой стороны, у Flutter нет такой философии дизайна. Он задуман как чисто нативное кроссплатформенное решение, и хотя в нем говорится, что он был вдохновлен React-Native, он больше похож на нативное настольное или мобильное приложение, чем на веб-приложение. Он также работает с использованием Dart, а не Javascript, что с точки зрения интеграции чего-то вроде JSX является важным фактором. Во-первых, в то время как функции JS DOM могут быть ужасно многословными (как из-за дизайна функции, так и из-за самого языка JS), Dart как язык гораздо больше способствует чистому декларативному коду пользовательского интерфейса, в то время как Flutter по большей части хорошо справляется с этой задачей. сохраняя конструкторы пользовательского интерфейса краткими. Во-вторых ( как указал @sandangel ), Dart - это язык со статической типизацией, поэтому природа JSX, разработанного для языка с динамической типизацией, такого как JS, столкнется с проблемами в тех случаях, когда, например, конструктор пользовательского интерфейса требует Виджет определенного типа, единственное решение которого только добавляет многословия. Лично мне это кажется решением, которое со временем неизбежно приведет к тому, что DSL станет раздутым и сложным в обслуживании, поскольку он должен учитывать растущее число вариантов использования, присущих системе, для которой она не предназначалась. используется для.

Таким образом, я действительно не понимаю, как JSX/DSX может принести пользу производительности разработки Flutter, помимо личных предпочтений. Оба синтаксиса в целом примерно эквивалентны по многословности, и если кто-то теряет многословие в конкретных случаях, это компенсируется ясностью (например, закрывающие теги XML). Это в значительной степени сводится к тому, переходит ли кто-то во Flutter из веб-ориентированного фона (React/RN, Angular и т. д.) или из собственного фона (Java/Kotlin/Swift, WPF/UWP и т. д.), который определит, какой подход, который они предпочли бы. Даже в одной только этой ветке есть много пользовательских историй, которые говорят, что сначала они крайне скептически относились к JSX, но после нескольких месяцев использования изменили свое мнение на «без него не обойтись». (Хотя циничная часть меня хочет указать, что то же самое вполне может случиться с ними для родного подхода Dart, если они дадут ему шанс.)

При всем при этом я не могу согласиться с тем, что команда Flutter должна официально поддерживать DSX в качестве альтернативы нативным конструкторам пользовательского интерфейса. Хотя это совершенно нормально в качестве стороннего решения (и все реквизиты @cbazza для его фактической реализации), оно не совсем соответствует основной природе Flutter как платформы, не основанной на веб-технологиях. Таким образом, больше возможностей для тех, кто хочет использовать DSX в своих собственных проектах, но я бы согласился с тем, что существует множество других более важных вещей, на которые команда Flutter могла бы и должна тратить свое время.

Теперь, когда ЭТО было сказано, хотя я не очень согласен с официальной поддержкой DSX, я все же думаю, что должен быть официальный формат пользовательского интерфейса _какого-то_ вида. Как отметил @birkir , почти каждая крупная нативная платформа пользовательского интерфейса, будь то настольная или мобильная, имеет формат пользовательского интерфейса в дополнение к прямому подходу на основе кода (и большинство из них в любом случае предварительно обработаны для подхода на основе кода). Наличие отдельных файлов пользовательского интерфейса и файлов логики всегда было рекомендуемым способом использования шаблона MVVM (что, кстати, всегда раздражало меня в JSX). Поэтому я бы сказал, что у Flutter есть что-то подобное — вместо встроенного формата DSL UI он должен иметь отдельный формат UI, который предназначен для перехода в свой собственный файл вдали от кода Dart.

В соответствии с этим ходом мыслей я на самом деле проделал некоторую работу в прошлые выходные в этом направлении. Если бы мне позволили немного помолчать, я разработал проект, который я назвал «FLUI», который является моей попыткой показать, как может выглядеть такой формат . Вместо того, чтобы использовать существующий DSL (или модифицированную версию), я разработал совершенно новый, вдохновленный YAML, и я изо всех сил старался максимально приблизиться к «ощущению» макета Flutter-constructor-подхода. Конечно, это _очень_ ранняя_ реализация, поэтому я не ожидаю, что у нее не будет большого количества проблем, но я включил исходный код сценария процессора (написанного на C#/.NET Standard), чтобы люди могли играть с ним, если они хотят. :)

Как пользователь React/RN и Flutter, я категорически не согласен с идеей «DSX».

DSX ничего не принесет. JSX используется в реакции, потому что синтаксис JS ужасен. Но в случае с Flutter создание виджетов очень просто.

Классический:

Widget build(BuildContext context) {
  return Center(
    child: Text("foo"),
  );
}

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

Единственная жалоба, которую вы могли бы иметь с текущим синтаксисом: «Трудно понять, где находится закрывающая скобка виджета».

Но опять же, плагин dart для официально поддерживаемых IDE решает эту проблему. Так что, когда мы откроем предыдущий код, скажем, vscode, мы увидим

Widget build(BuildContext context) {
  return Center(
    child: Text("foo"),
  ); // Center
}

Что касается «Трудно отличить случайный код от кода пользовательского интерфейса», правила реагирования применимы и к флаттеру:

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

Если вы будете следовать этому шаблону, вы никогда не попадете в ситуацию, когда не сможете отличить пользовательский интерфейс от всего остального.
Это еще более верно, если следовать чему-то вроде шаблона BLoC; которые строго обеспечивают разделение бизнеса и пользовательского интерфейса.

JSX используется в реакции, потому что синтаксис JS ужасен

Очень самоуверенное заявление и просто не соответствует действительности.

render() {
  return React.createElement(Container, { padding: EdgeInsets.all(20.0) },
    React.createElement(Text, { style: { color: Colors.black } },
      'foo'
    )
  );
}

Widget build(BuildContext context) {
  return Container(
    padding: EdgeInsets.all(20.0),
    child: Text(
      'foo',
      style: TextStyle(color: Colors.black)
    ),
  );
}

render() {
  return (
    <Container padding={EdgeInsets.all(20.0)}>
      <Text style={{ color: Colors.black }}>foo</Text>
    </Container>
  );
}

Widget build(BuildContext context) {
  return (
    <Container padding={EdgeInsets.all(20.0)}>
      <Text style={TextStyle(color: Colors.black)}>{'foo'}</Text>
    </Container>
  );
}

Очень самоуверенное заявление и просто не соответствует действительности.

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

Реагировать без JSX:

• 133 символа, включая 3 скобки, 3 скобки, 3 : , 4 , и 11 пробелов.
• React.createElement написано дважды

JSX:

• 104 символа, с 2 круглыми скобками, 3 квадратными скобками, 1 : , 4 <> и 5 пробелами
• Container и Text написано дважды

Дарт:

• 99 символов, 2 скобки, 4 : , 3 , и 4 пробела
• Без повторения

Что касается символов, очевидным победителем здесь является синтаксис дротика.

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

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

Несколько примеров, которые плохо конвертируются в JSX:

Не всегда children :

Scaffold(
  appBar: AppBar(),
  body: Container(),
)

OR

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

const конструктор самого виджета

const Padding(
  padding: const EdgeInsets.all(4.0),
)

дженерики

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

позиционный реквизит:

Text("foo")

Именованный конструктор

Positioned.fill(
  child: Container(),
);

строители (dart не поддерживает тип объединения, поэтому children не может быть одновременно виджетом и функцией)

Builder(
  builder: (context) => Container(),
)

@rrousselGit

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

-1------------------------------------------------------
В Дарте:

Scaffold(
  appBar: AppBar(),
  body: Container(),
)

OR

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

В DSX:

<Scaffold
  appBar={<AppBar/>}
  body={<Container/>}
/>

OR

<SingleChildScrollView>
  <Container
    height={100.0}
  />
</SingleChildScrollView>

-2------------------------------------------------------
В Дарте:

const Padding(
  padding: const EdgeInsets.all(4.0),
)

В DSX:

const Padding(
  padding: const EdgeInsets.all(4.0),
)

-3------------------------------------------------------
В Дарте:

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

В DSX:

<NotificationListener<ScrollNotification>
  onNotification={(foo) {

  }}
  child={child}
/>

-4------------------------------------------------------
В Дарте:

Text("foo")

В DSX:

<Text ["foo"]/>

-5------------------------------------------------------
В Дарте:

Positioned.fill(
  child: Container(),
);

В DSX:

<Positioned.fill>
  <Container/>
</Positioned.fill>

-6------------------------------------------------------
В Дарте:

Builder(
  builder: (context) => Container(),
)

В DSX:

<Builder
  builder={(context) => <Container/>}
/>

Но тогда аргумент о более легком переходе от реакции к флаттеру недействителен. Поскольку JSX радикально отличается от вашего прототипа:

<MyAppBar>
    <title:Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    </title:Text>
</MyAppBar>

И ни один из ваших примеров здесь или по вашей ссылке на самом деле не упрощает код и не улучшает читабельность.

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

В качестве примечания, есть гораздо лучшее решение для вашего разделения интересов. Это файл шаблона
У вас может быть файл xml/yaml рядом с вашим виджетом. А затем используйте потрясающие инструменты для генерации кода, которые предоставляет Dart.

Я бы предпочел:

// main.dart
import 'package:flutter/material.dart';

part 'main.g.dart';

class MyState extends StatefulWidget {
  <strong i="14">@override</strong>
  _MyStateState createState() => _MyStateState();
}

class _MyStateState extends State<MyState> {
  <strong i="15">@override</strong>
  Widget build(BuildContext context) {
    return $myStateStateTemplate(theme: Theme.of(context));
  }
}

в сочетании с

// main.xml
<strong i="19">@theme</strong> ThemeData

<Container  color={@theme.cardColor} />

который затем с помощью пользовательского генератора кода генерирует следующий файл дротика:

part of 'main.dart';

Widget $myStateStateTemplate({ThemeData theme}) {
  return Container(
    color: theme.cardColor,
  );
}

Конечный результат даже лучше, чем "DSX" для разделения пользовательского интерфейса и логики. Это также лучше для потенциальных генераторов пользовательского интерфейса. И это намного проще реализовать с помощью built .

Поскольку JSX радикально отличается от вашего прототипа:

Действительно !!! Единственным радикальным моментом в этих дискуссиях была реакция скептиков.

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

Вы можете написать это так:

<MyAppBar>
    <title:Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    </title:Text>
</MyAppBar>

or

<MyAppBar>
    <title:Text ['Example title'] style={Theme.of(context).primaryTextTheme.title}/>
</MyAppBar>

or

<MyAppBar
    title={<Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    <Text>}
/>

or

<MyAppBar
    title={<Text ['Example title'] style={Theme.of(context).primaryTextTheme.title}/>}
/>

Хм, вы, кажется, путаете «разделение интересов» с «разделением технологий». Эти вещи очень разные; вы разделяете код дротика и код разметки в разных файлах, это просто «разделение технологий» и не дает никаких преимуществ «разделения задач». Беспокойство здесь вызывает компонент/виджет, который аккуратно инкапсулирует повторно используемый код, не имеет значения, что внутри этого компонента/виджета используются разные технологии.

Кроме того, рекомендуемое вами разделение технологий сильно уступает JSX/DSX, который использует основной язык для всех своих императивных конструкций (для циклов, вызовов функций, операторов if и т. д.).

После большого количества кода и примеров, размещенных здесь ( особенно ), я пришел к выводу, что JSX добавляет гораздо больше ценности JS в отличие от DSX и Dart. Но одна особенность, с моей точки зрения, очень важна: закрывающие теги. Нравится:

<SingleChildScrollView>
  <Container
    height={100.0}
  />
</SingleChildScrollView>

уменьшает НАМНОГО когнитивную сложность в глубоких структурах, как здесь, в отличие от:

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

Но хорошо, если вы используете это так:

<Scaffold
  appBar={<AppBar/>}
  body={<Container/>}
/>

есть небольшая прибыль.

Как указано в заголовке этого билета, DSX похож на JSX, но не идентичен JSX.

Вы пропустили мое «Но тогда аргумент о более легком преобразовании реакции на флаттер недействителен».

Половина аргументов в пользу DSX заключается в том, что «JSX популярен в React, нам это тоже нужно здесь». Но вы предлагаете что-то отличное от JSX (и более сложное).
Другая половина посвящена отделению пользовательского интерфейса от кода; что может сделать и файл шаблона.

Кроме того, рекомендуемое вами разделение технологий сильно уступает JSX/DSX, который использует основной язык для всех своих императивных конструкций (для циклов, вызовов функций, операторов if и т. д.).

Не правда. Вы можете сделать if и прочее внутри файла шаблона. Посмотрите на шаблоны cshtml или angular.

Дело в том, что файл шаблона, если у вас уже есть парсер для него, может быть полностью реализован для флаттера менее чем за неделю.
Будь то yaml, xml, cshtml или html с директивами.

В то время как DSX потребует много работы.

@Bessonov Недавно они добавили виртуальные комментарии к поддерживаемым IDE, чтобы имитировать закрывающий тег.

Итак, в вашем vscode вы увидите следующее:

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ), // Container
) // SingleChildScrollView

Преимущества закрытия тегов. Без необходимости их вводить

@rrousselGit

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

Да, я видел это в процитированном комментарии. Но это не то же самое. Это приводит к смещению выравнивания и нарушению потока чтения. И это не помогает мне в других IDE и текстовых процессорах.

Дело в файле шаблона

ИМХО шаблоны страдают синдромом NIH. Я не говорю, что подход к смешиванию PHP и HTML является правильным способом сделать это. Но React показывает с помощью JSX, как это можно сделать лучше.

@rrousselGit

Вы пропустили мое «Но тогда аргумент о более легком преобразовании реакции на флаттер недействителен».

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

Половина аргументов в пользу DSX...

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

Не правда. Вы можете сделать if и прочее внутри вашего файла шаблона. Посмотрите на шаблоны cshtml или angular.

Дело в том, что файл шаблона, если у вас уже есть парсер для него, может быть полностью реализован для флаттера менее чем за неделю.
Будь то yaml, xml, cshtml или html с директивами.

В то время как DSX потребует много работы.

Наоборот, DSX реализует только 2 xml-преобразования, а все остальное получает бесплатно от языка хостинга. Представьте себе усилия по повторной реализации возможностей Dart в вашем новом языке шаблонов. Нет, спасибо, я возьму Дарт.

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

То же самое относится и к текущей реализации дротика.

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

1. Создание виджета отличается от React

В React это библиотека, которая занимается созданием компонентов. JSX хорош, потому что он говорит: «Не беспокойтесь о том, как все работает. Мы делаем все для вас».

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

И, в продолжение этой логики:

2. Люди могут думать, что <Foo /> делает что-то особенное, чего нет у new Foo()

<Foo /> в методе кажется особенным. Похоже, он делает что-то постороннее, встроенное в фреймворк. Что верно в реакции, где компоненты завернуты в React.Element .
Это приводит к реакции на <Foo /> != new Foo() и не имеет прямого доступа к Foo .

Это не относится к флаттеру и может вызвать путаницу.

Также :

<Foo>
  <Bar />
</Foo>

В ответ, если Foo никогда не использует своего дочернего элемента, то экземпляр Bar никогда не создается. А экземпляр Foo создается после возврата метода render .
Во время флаттера все наоборот. И Bar , и Foo создаются сразу.

Это потенциально может привести к тому, что разработчики React будут создавать неоптимизированный флаттер-код.

3. В целом Dart/flutter — это не JS/react

Если мы добавим JSX в дротик, я уже увижу проблемы с объединением типов или смогу сделать
return foo && <Component /> или предстоящий асинхронный рендеринг в React.
Оправданный фразой «у нас уже есть JSX, так что мы тоже можем его получить!»

Я бы предпочел проприетарный синтаксис или вообще никакого синтаксиса, чтобы не реализовывать последнюю функцию JSX/react в dart.

4. JSX делает некоторые особенности дротика неясными

Небольшой пример: Scaffold требует для appbar PrefferedSizeWidget .
Если бы мы создали Scaffold с помощью JSX, люди ожидали бы, что вы можете заменить любой данный JSX другим. что неправда

Я имею в виду, это делает очень неясным, почему мы можем делать

<Scaffold
  appbar={<AppBar />}
/>

но нет

<Scaffold
  appbar={<Container />}
/>

@rrousselGit

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

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

1. Создание виджета отличается от React

Для меня это не имеет значения, потому что это всего лишь деталь реализации, концептуально, когда вы видите какой-то XML, в React это компонент, во Flutter это виджет.

1. Люди могут думать делает что-то особенное, чего не делает new Foo()

Я думаю, что люди довольно быстро поймут, что Dart/DSX — это не Javascript/JSX.

1. В общем, Dart/flutter — это не JS/реакция.

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

Если мы добавим JSX в dart, я уже увижу проблемы с объединением типов или смогу сделать return foo && <Component /> или предстоящий асинхронный рендеринг в реакции.
Оправданный фразой «у нас уже есть JSX, так что мы тоже можем его получить!»

Мы не добавляем JSX в Dart, мы добавляем DSX, он отличается, но имеет сходство с JSX, и знакомство с ним — это огромная вещь.

Я бы предпочел проприетарный синтаксис или вообще никакого синтаксиса, чтобы не реализовывать последнюю функцию JSX/react в dart.

Итак, исходя из этого, почему вы используете Dart? он очень похож на Java, но отличается от него; черт с ним, давайте отбросим все эти ключевые слова и концепции Java и придумаем что-то отдаленно похожее на Erland, что вы можете программировать только одной рукой, выполняя движение крендель-йоги на вершине горы Эверест ;)

1. JSX делает некоторые особенности дротика неясными

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

@cbazza Я часами читал ваши сообщения и очень ценю ваши усилия по этому вопросу. Но я думаю, что (отчасти) легко закончить спор. Помните, что Flux был официальным решением для управления состоянием для React, но теперь все используют Redux? И сколько навигационных библиотек есть для react-native? Просто создайте репозиторий DSX и позвольте разработчикам реагировать.

@rrousselGit

Я никогда раньше не видел синтаксис part / part of в Dart, и у меня возникли проблемы с поиском документации по нему. Это то, что официально поддерживает Dart/Flutter? Я бы хотел использовать что-то подобное во FLUI.

@cbazza

Вы продолжаете ходить по кругу с оправданием DSX. DSX - это не JSX. DSX похож на JSX. DSX должен быть знакомым синтаксисом для разработчиков React. DSX — это просто синтаксический сахар для Dart. Люди узнают, что DSX — это не JSX. (И так далее.)

Хотя я понимаю, что вы пытаетесь сделать со всеми этими объяснениями, я думаю, что тот факт, что вы должны продолжать их делать, раскрывает серьезную проблему, касающуюся природы DSX в целом, и это также вопрос, который поднял rrouselGit . Даже когда вы продолжаете говорить, что DSX — это _не_ JSX, люди, которые найдут его, будут думать, что это так, и это проблема. JSX и люди, которые его используют, происходят из экосистемы, которая на фундаментальном уровне концептуально отличается от Dart/Flutter. Таким образом, разработка функции для «знакомства» не обязательно является хорошей идеей. Одна из наиболее очевидных причин этого, как было указано, заключается в том, что люди собираются попробовать что-то вроде этого:

Widget build(BuildContext context) {
    return isDialogVisible && <Widget>...</Widget>;
}

Поскольку они исходят из Javascript/JSX, они ожидают, что этот синтаксис будет работать в DSX. Когда это не так, это становится точкой когнитивного диссонанса, который может на самом деле _вредить_ их интересу не только к DSX, но и к Flutter в целом. Знакомство полезно, когда оно используется как средство, помогающее людям освоить что-то новое, но это может быть обоюдоострый меч — когда 90% функций одинаковы, оставшиеся 10% могут только расстраивать и раздражать.

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

Пока писал это, мне пришла в голову еще одна вещь. В этой ветке было несколько сторонников JSX, которые хвалили JSX, говоря, что подход «разделения задач» к дизайну пользовательского интерфейса — это действительно единственный способ, которым они когда-либо снова рассмотрят возможность разработки пользовательского интерфейса. Если это так, то почему React является единственным рыночным фреймворком, который его использует? Как нативные, так и кроссплатформенные платформы мобильных приложений застряли со своими раскадровками, файлами XML, файлами XAML и другими подобными DST определения пользовательского интерфейса. Даже другие популярные JS-фреймворки, такие как Angular и многообещающий Vue, по-прежнему используют подход «разделения технологий». Разработчики React говорят, что JSX — это путь будущего, но я еще не видел, чтобы он появился где-либо, кроме как в React, в фреймворке, который получил бы реальную поддержку.

@andrewackerman

part / part of — это существующая функция дротика. Он каким-то образом объединяет два файла в один. Обычно используется для генерации кода.

Есть несколько реальных сценариев, в которых используется такая техника. Например, json_serializable , который генерирует метод $# toJSON 3$#$ и фабрику fromJSON для классов на основе их свойств.

part / part of сами по себе ничего не делают. Самое интересное, когда вы комбинируете его с чем-то вроде source_gen .

@sunnylqm

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

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

@andrewackerman

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

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

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

Если это так, то почему React является единственным рыночным фреймворком, который его использует? Как нативные, так и кроссплатформенные платформы мобильных приложений застряли со своими раскадровками, файлами XML, файлами XAML и другими подобными DST определения пользовательского интерфейса.

Просто сделайте временную шкалу, и вы увидите эволюцию разработки пользовательского интерфейса. Разработка Android и iOS с использованием их нынешних способов началась более 10 лет назад, поэтому в ней используются методы 10-летней давности (абсолютно императивные методы). Методы разработки реактивного пользовательского интерфейса (декларативные) начали появляться в Интернете около 8 лет назад. React появился 5 лет назад, и это был первый фреймворк Reactive, органично сочетающий технологии с JSX. Vue теперь является новейшей платформой Reactive, которая поддерживает старые методы «разделения технологий», но также поддерживает JSX. На мобильных устройствах Flutter является последним, и он использует методы Reactive framework, такие как React, и он может использовать преимущества DSX так же, как Vue использует преимущества JSX. Vue убивает Angular, потому что предоставляет выбор разработчикам и не слишком самоуверен.

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

Разработчики React говорят, что JSX — это путь в будущее,

Это !!!

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

Vue использует JSX

@cbazza

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

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

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

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

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

Vue использует JSX

Я использую Vue уже почти год, и за это время я просмотрел большое количество репозиториев проектов с открытым исходным кодом, чтобы увидеть, как выполняются разные вещи. Хотя я никоим образом не считаю себя мастером Vue, я скажу, что ни в одном из них я никогда не видел, чтобы JSX действительно использовался — люди, похоже, массово предпочитают подход .vue (шаблон -script-styling) по сравнению с подходом render+JSX. Я даже сам не знал, что Vue даже поддерживает JSX (по крайней мере, через плагин babel), пока после вашего ответа я не покопался в документации Vue и не обнаружил крошечный фрагмент информации о нем в разделе функций рендеринга .

Но это не имеет отношения к моему общему мнению. Vue по-прежнему является фреймворком Javascript. Флаттера, безусловно, нет. Таким образом, есть много причин, по которым JSX является новейшей лучшей вещью в среде, ориентированной на Javascript, которая не будет преобразована в Dart + Flutter, многие из которых уже были рассмотрены в этой теме.

Это !!!

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

Vue использует JSX

Vue spec имеет широкий спектр применений. JSX просто «там». Но это не доминирующий синтаксис
Вы можете подключить JSX к Angular, если хотите. Хотя никто не делает

Разработчики React говорят, что JSX — это путь в будущее,
Это !!!

Большой кандидат на будущее — веб-компоненты. И они используются непосредственно в html, аналогично тому, что вы найдете в Angular или наиболее распространенной форме Vue.

@andrewackerman

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

Кто сказал что-нибудь о ручных действиях? Разве я не ясно дал понять, что пытаюсь добиться полной бесшовной интеграции с IDE (наилучший пользовательский опыт для разработчиков).

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

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

что я скажу, так это то, что ни в одном из них я никогда не видел, чтобы JSX действительно использовался - люди, похоже, массово предпочитают подход .vue (template-script-styling) подходу render + JSX.

JSX — это новое дополнение, поэтому для его распространения потребуется время, но важно понять, что Vue принимает другие подходы, не заставляя разработчиков использовать «правильный и единственный способ», которым все должно быть сделано во Vue.

Vue по-прежнему является фреймворком Javascript. Флаттера, безусловно, нет.

Хорошо, так что вместо JSX вы используете DSX с Flutter.

@rrousselGit

Большой кандидат на будущее — веб-компоненты.

Веб-компоненты — это зомби, мертвые, но все еще живущие; они так же широко распространены, как кенгуру в Канаде. Я мог бы продолжать несколько дней, но чтобы не отвлекаться...
https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/

@cbazza

Кто сказал что-нибудь о ручных действиях? Разве я не ясно дал понять, что пытаюсь добиться полной бесшовной интеграции с IDE (наилучший пользовательский опыт для разработчиков).

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

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

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

DSX, с другой стороны, разрабатывается сегодня вами и горсткой людей. Вы красноречиво рассказывали о том, что он может и будет делать, но все, что мы на самом деле _видели_, это небольшая горстка специально созданных фрагментов кода и ваше слово, что они были сгенерированы транспайлером. Люди, которые даже хотят попробовать его и предложить возможные изменения или улучшения, не могут этого сделать, поэтому у них нет причин поддерживать ваши усилия, кроме «Yay JSX!».

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

JSX — это новое дополнение, поэтому для его распространения потребуется время, но важно понять, что Vue принимает другие подходы, не заставляя разработчиков использовать «правильный и единственный способ», которым все должно быть сделано во Vue.

JSX находится во Vue уже почти 2 года. И в отличие от самого Vue, JSX — это уже существующая технология, которая не нуждается в представлении, особенно для людей, знакомых с React. Если бы JSX собирался покорить мир Vue.js, я не могу не чувствовать, что он уже сделал бы это. (Особенно, если это указывает на то, что столько людей требуют JSX во Flutter, как вы утверждаете.)

Хорошо, так что вместо JSX вы используете DSX с Flutter.

JSX и DSX — это одна и та же синтаксическая концепция. Проблема в том, что если JSX был построен на динамическом языке со слабой типизацией, таком как JavaScript, то DSX строится на статическом языке со строгой типизацией, таком как Dart. Это означает, что DSX придется учитывать множество проблем, которых JSX не пришлось решать, если это будет что-то иное, чем нишевая реализация «JSX для Flutter», и потребуются некоторые _гениальные_ модификации, чтобы заставить DSX действительно работать. не делая его слишком раздутым, чтобы оправдать заявление о том, что он визуально более лаконичен.

И чтобы ответить на опровержение «DSX — это просто Dart, если DSX не может что-то сделать, просто используйте Dart», то мое встречное опровержение будет состоять в том, что мне придется продолжать возвращаться к Dart всякий раз, когда я сталкиваюсь со сценарием, которого DSX не делает. t handle, то почему бы мне просто не использовать Dart все время?

И чтобы ответить на опровержение этого чтения «вы можете, если хотите, DSX — это просто вариант», то вы действительно недооцениваете себя. Даже если это действительно будет просто «вариант», все равно нужно внести что-то, что убедит людей использовать его. Вы сами сказали, что DSX — это не JSX, поэтому люди, которым нужен только JSX, не получат того, что хотят. Это означает, что должны быть какие-то материальные причины, помимо «JSX-подобной привлекательности», чтобы люди захотели его использовать.

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

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

Несколько не по теме, но я хотел бы отметить, что веб-компоненты действительно многообещающе смотрят в будущее, даже если их поддержка добавляется медленнее, чем tar. Подумайте об этом так: React делает то, что он делает, потому что он по сути реализует идею веб-компонентов только в Javascript. Представьте, насколько лучше было бы, если бы эти функции поддерживались браузером и выигрывали от производительности без песочницы и без необходимости работать через манипуляции с DOM? (Конечно, может пройти еще 20 лет, прежде чем мы узнаем, но все же...)

@andrewackerman

Извини, чувак, у меня нет времени бесконечно спорить и повторять то, что я сказал раньше, снова и снова; мы все равно не придем к соглашению, так что удачи вам с FLUI.

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

Онлайн-транспилятор DSX работает с февраля 2018 года, и любой может его использовать, поэтому нет необходимости верить мне на слово. Нажмите «Компилировать», и он скомпилирует то, что написано на левой панели, и поместит результаты на правую панель. Откройте отладчик, и вы увидите записанный AST.
https://spark-heroku-dsx.herokuapp.com/index.html

Проблема в том, что если JSX был построен на динамическом языке со слабой типизацией, таком как JavaScript, то DSX строится на статическом языке со строгой типизацией, таком как Dart.

Это не имеет большого значения, как концепция ООП (объектно-ориентированное программирование) и синтаксис для «классов». Это почти идентично бестиповому Javascript или типизированному Dart; то же самое можно сказать об операторе «если», «для» и т. д.

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

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

@cbazza

Извини, чувак, у меня нет времени бесконечно спорить и повторять то, что я сказал раньше, снова и снова; мы все равно не придем к соглашению, так что удачи вам с FLUI.

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

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

Онлайн-транспилятор DSX работает с февраля 2018 года, и любой может его использовать, поэтому нет необходимости верить мне на слово. Нажмите «Компилировать», и он скомпилирует то, что написано на левой панели, и поместит результаты на правую панель. Откройте отладчик, и вы увидите записанный AST.

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

(Хотя я укажу, что возиться с онлайн-песочницей — это не то же самое, что тестировать транспайлер в более практичной среде.)

Это не имеет большого значения, как концепция ООП (объектно-ориентированное программирование) и синтаксис для «классов». Это почти идентично бестиповому Javascript или типизированному Dart; то же самое можно сказать об операторе «если», «для» и т. д.

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

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

Опять же, это 100 человек, которые проголосовали за проблему на основании «Учитывайте JSX-подобный синтаксис внутри кода дротика». Они проголосовали, потому что хотят _JSX_, и, как вы так стремились указать, DSX — это не JSX. Так зачем еще им использовать DSX? Потому что встроенное XML-подобное объявление пользовательского интерфейса — это «будущее»? Опять же, я просто не вижу этого.

Мы уже рассмотрели JSX во Vue, который не получил никакого распространения, но есть также две альтернативы React, упомянутые в статье о веб-компонентах, на которую вы ссылаетесь: Inferno и Preact. Насколько я могу судить, они оба не произвели никакого фурора в мире разработки веб-приложений на основе JS, несмотря на то, что изначально поддерживают синтаксис, подобный JSX. Я действительно думаю, что людям нужно долго и пристально смотреть на то, почему именно людям нравится JSX в React, потому что, судя по всему, это просто не из-за самого JSX. Если на _этот_ вопрос можно будет ответить, то мы сможем двигаться вперед к «будущим» инновациям, а не просто внедрять одну функцию из той библиотеки, которая нам понравилась, во все остальные, по нашему личному мнению, она должна быть.

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

@andrewackerman

Проблема в том, что если JSX был построен на динамическом языке со слабой типизацией, таком как JavaScript, то DSX строится на статическом языке со строгой типизацией, таком как Dart.

Извините, но это не проблема. Более того, в этом нет никакого смысла. Кроме того, мы используем JSX с TypeScript.

@escamoteur абсолютно!

@escamoteur Я с тобой в этом. _100._

@Бессонов

Извините, но это не проблема. Более того, в этом нет никакого смысла. Кроме того, мы используем JSX с TypeScript.

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

@andrewackerman
Как вы думаете, почему это имеет значение? JSX — это способ описания интерфейса. Он сам по себе независим от языка. Смотри сюда . Это не JavaScript. Но почему это нельзя сделать с помощью JSX? (Кроме того, нет реализации этого (пока))

И... знаете... флоу тоже из фейсбука:

Flow — это статическая проверка типов для JavaScript.

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

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

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

Да, количество ненависти здесь просто эпическое, просто подумайте об этом:
Открытых тикетов 3587, если отсортировать их "палец вниз" получится
1 (этот) с 57 "большими пальцами вниз"
3586 (другие билеты) с 1 или менее "палец вниз"

@Бессонов

Как вы думаете, почему это имеет значение? JSX — это способ описания интерфейса. Он сам по себе независим от языка. Смотри сюда. Это не JavaScript. Но почему это нельзя сделать с помощью JSX? (Кроме того, нет реализации этого (пока))

Это способ описать пользовательский интерфейс _в Javascript_ (отсюда и часть названия «JS»). И нет, поскольку это встроенный DSL, он _не_ зависит от языка. И даже если бы это было так, это все равно не делает его «лучшим выбором», поскольку существует множество действительно не зависящих от языка DSL, которые были бы ужасно неадекватными для объявлений пользовательского интерфейса.

И... знаете... флоу тоже из фейсбука:

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

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

Я использовал JSX, и хотя у меня есть личное мнение о нем, я намеренно исключил его из обсуждения. На самом деле, если бы вы читали мои предыдущие комментарии, вы бы знали, что я хвалил JSX за революцию в разработке пользовательского интерфейса в React. Если не считать некоторых слегка второстепенных комментариев, которые я сделал о проникновении JSX на рынок в целом, мои аргументы касались именно JSX _in Flutter_. И по этой теме нет никакой практической основы для определения эффективности DSX, поэтому все, что мы можем сделать, это изучить, как JSX был реализован в других местах, и это исследование не сулит ничего хорошего.

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

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

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

Вы не сделаете успешный продукт исключительно с помощью чистой похвалы. Он также должен противостоять критике и учитывать ее. Люди, которые приходят и говорят: «Боже мой, да пожалуйста, сделайте DSX», хотя и воодушевляют, но не помогают. В этой ветке было несколько человек, которые высказали вполне обоснованную критику DSX как в отношении его первоначального дизайна, так и в отношении концепции в целом. И по большей части ко многим из этих критических замечаний еще предстоит обратиться напрямую, поскольку общее отношение к ним остается пренебрежительным.

Единственное, чего я боюсь, так это того, что вся эта безусловная любовь к JSX мешает людям объективно относиться к DSX. Я понимаю, почему вы, ребята, хотите что-то вроде JSX во Flutter, и я могу понять — мое мнение, что Flutter нуждается в выделенном UI DSL, привело меня к созданию Flui. Но если говорить о DSX позволено только тем, кто может сказать о ней только хорошее, то она _будет_ провалена.

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

Команда Dart заявила, что у них другие приоритеты. И профессиональная сторона JSX вызвалась сделать свою собственную реализацию DSX.

Может быть, нам просто нужно иметь несколько репозиториев с открытым исходным кодом, предлагающих разные решения (пусть даже едва работающие). Например, DSX или шаблоны.
А затем рассмотрите возможность перенаправления из файла readme или awesome_flutter Flutter в эти репозитории. И если есть что-то, что блокирует реализацию DSX, создайте еще одну проблему со спецификой.

Тогда позвольте сообществу делать свою работу.

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

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

Разница здесь в том, что теперь мы могли бы ответить следующим образом:

«Пока мы не планируем реализовывать это в dart/flutter. Но вы можете взглянуть на альтернативы сообщества [здесь] и [там] или прочитать [этот выпуск]».

и закрыть вопрос как дубликат.

Одно место для комментариев и голосов, и оно здесь. Запрос на JSX-подобную функциональность не исчезает, и тикет открывается, потому что ему нужна поддержка инструментов Flutter (компилятор и IDE VS Code), и я обновил запрос тикета этой информацией (первый комментарий). Если об этом начнет просить огромное количество людей, это даст команде Flutter стимул вкладывать в это ресурсы.

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

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

Большой нет для этого, я действительно думаю, что только 1 язык - это большой выигрыш, синтаксис jsx будет иметь больше вещей, таких как отделение xml от js и т. д. ... Не очень хорошо.

это мое мнение.

Это самая длинная и бессмысленная проблема Github, которую я когда-либо видел.

@cbazza Хорошая работа 👍
ДСС + 1

@BarryYan , спасибо

Пожалуйста, избегайте подобных комментариев, будь то "+1" или "Спасибо".
Это отправляет электронное письмо всем подписчикам без ничего интересного.

Пожалуйста, избегайте подобных комментариев, будь то "+1" или "Спасибо".
Это отправляет электронное письмо всем подписчикам без ничего интересного.

Ничего интересного для вас!!!
Пожалуйста, не говорите людям, что они могут сказать или сделать, и сосредоточьтесь только на том, что можете сказать или сделать вы.

@cbazza

Чувак, это элементарный этикет. Любое новое сообщение в этой ветке отправляется по электронной почте всем, кто на него подписан, поэтому неприлично публиковать комментарии, которые не способствуют обсуждению, потому что они беспричинно раздражают людей. Основные реакции, такие как «+1» и «Спасибо», можно выразить простым жестом «большой палец вверх», так что просто сделайте это.

При этом, если эта ветка действительно превратилась в спор о том, должен ли кто-то или не должен публиковать сообщение «+1», это большой красный флаг, что все конструктивные обсуждения официально умерли, и ее действительно следует закрыть (возможно, навсегда). в этот раз).

@andrewackerman ,

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

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

После всех ваших писаний вы не добавили никакой ценности DSX, поэтому мне неинтересно вести с вами дискуссию на эту тему. Однако ваш мотив очевиден: продвигайте FLUI, одновременно раскручивая DSX.

Скажите, а у вас есть ответы на собственные вопросы применительно к FLUI? Давайте немного обсудим FLUI?

@cbazza

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

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

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

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

После всех ваших писаний вы не добавили никакой ценности DSX, поэтому мне неинтересно вести с вами дискуссию на эту тему. Однако ваш мотив очевиден: продвигайте FLUI, одновременно раскручивая DSX.

Я прошу _you_ защитить свою позицию. Вы неоднократно говорили, что JSX/DSX — лучшее/будущее, но еще не объяснили, как и почему. Несколько человек выразили обоснованную озабоченность по поводу DSX, но вместо того, чтобы решить их, вы отмахиваетесь, прикрываясь контраргументом «если вам это не нравится, не используйте его». Мой «мотив» состоит в том, чтобы заставить вас ответить на вопросы, которые необходимо задать относительно _любого_ технического проекта, в первую очередь о том, почему люди должны использовать его, а не альтернативы. (И, как я уже объяснял ранее, знакомство не является достаточной причиной.)

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

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

Скажите, а у вас есть ответы на собственные вопросы применительно к FLUI? Давайте немного обсудим FLUI?

FLUI — это не DSX — он не должен отвечать на все вопросы, которые я задавал вам относительно DSX, потому что многие из них относятся к дизайну DSX. Это не значит, что у него нет собственного набора вопросов, на которые нужно ответить, и нет, у меня нет всех этих ответов. Вот почему я ценю критическую дискуссию — FLUI/DSX не выстоят перед судом общественного мнения, если они не выживут, когда их пару раз разгребут в пух и прах. Однако это не подходящее место для обсуждения FLUI. Если вы хотите подробно обсудить FLUI, у проекта есть собственная доска объявлений , так что не стесняйтесь писать там.

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

andrewackerman Хорошая работа 👍
+ 1

@andrewackerman

Молодец

Чувак, ты получаешь комплимент от @jstansbe , который передает гораздо больше информации, чем большой палец вверх и большой палец вниз в ответ на комплимент?

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

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

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

Для меня очевидно, что вы не очень разбираетесь в JSX, вы действительно не понимаете, как он работает. Поэтому вместо того, чтобы удваивать ставку, просто признайте это, и я объясню это более подробно. Например, JSX и DSX выполняют только следующие 2 преобразования (упомянутые несколько раз ранее):

(1)
<A property="a" />
    becomes
new A(property: a)

(2)
<A property="a">
  <B />
  <C />
</A>
    becomes
new A(property: a, children: <Widget>[new B(), new C()])

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

Обратите внимание выше на (2), что преобразование жестко запрограммировано <Widget> , и это не всегда так, поэтому теперь вы можете указать это, если это необходимо, как обсуждалось ранее. Посмотрите на преобразования, и теперь все символы берутся из источника или могут быть указаны, поэтому в будущем не будет каких-то серьезных магических ошибок.

в то время как вы критикуете любого с любой формой противоположного мнения.

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

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

Но в том-то и дело, что я хотел, чтобы команда Flutter реализовала DSX, но затем я сделал это, поэтому им нужно было реализовать общие вещи, которые не зависят от DSX, и DSX не единственный бенефициар. Движок браузера js поддерживает исходные карты, которые позволили экосистеме новых языков в браузере транспилироваться в js; это позволило создать Dart !!! и некоторые другие (Coffeescript, Typescript, Reason и т. д.). Dart может сделать то же самое сейчас и извлечь выгоду из экосистемы, которую он помогает поднять, все лодки поднимаются.

Я прошу вас отстаивать свою позицию.

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

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

Я бы использовал DSX, потому что предпочитаю, как пробелы или табуляции, определение типа до или после имени переменной. Нет смысла бороться за это, просто примите тот факт, что у людей разные предпочтения; существует более 1 редактора программирования, верно?

знакомство не является достаточной причиной

Просто ваше мнение, почему мы используем операторы «если» почти во всех языках, оператор «для», «класс», а теперь и «asyn/await».

Однако это не подходящее место для обсуждения FLUI. Если вы хотите подробно обсудить FLUI, у проекта есть собственная доска объявлений, так что не стесняйтесь писать там.

Очень хорошо, теперь ты заслужил мое уважение.

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

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

приглушите свое эго, прекратите интерпретировать критику как личные нападки и ответьте на важные вопросы.

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

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

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

Чувак, ты получаешь комплимент от @jstansbe , который передает гораздо больше информации, чем большой палец вверх и большой палец вниз в ответ на комплимент?

Вы, видимо, не уловили сарказма, присущего его комментарию. (Он буквально сделал все, что я сказал не делать.) Хотя это забавный троллинг, который я могу оценить, здесь он не уместен. И если, случайно, он был искренен, то прошу прощения за ехидство, но моя точка зрения остается в силе - такой комментарий здесь _по-прежнему_ неуместен.

Для меня очевидно, что вы не очень разбираетесь в JSX...

Возможно, мой отказ от ответственности в моем самом первом комментарии к этой теме подсказал вам?

... вы действительно не понимаете, как это работает.

Вы приравниваете меня к тому, что у меня нет большого опыта работы с JSX, и я вообще не знаю, как это работает? Хотя я никогда не работал над каким-либо серьезным проектом React, я сделал свою долю работы. Я прекрасно понимаю, как это _работает_.

Все остальное обрабатывается основным языком, например: как он обрабатывает импорт компонентов с одинаковыми именами; ответ: принимающий язык.

И это имеет смысл в случае, когда язык разметки и основной язык различны. В JSX язык разметки разработан как _расширение_ основного языка. Таким образом, JSX был разработан как расширение JS, и именно поэтому он работает так, как работает. DSX — это реализация JSX для Dart.

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

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

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

Во-вторых, если вы делаете что-то гораздо более сложное, чем if s и for s в своем коде пользовательского интерфейса (которые представляют собой конструкции, которые легко обрабатываются во многих решениях для разметки), то я бы сказал, что это признак того, что в вашем дизайне что-то не так. В соответствии с принципами проектирования MVC/MVVM, если вы включаете сложную логику в свои конструкции пользовательского интерфейса, это потенциальный признак вонючего кода, и вам в любом случае следует серьезно подумать о редизайне.

(Это не означает, что вы _не можете_ написать декларативный пользовательский интерфейс в стиле MVVM с использованием JSX, но это просто то, что создает проблемы для небольшой объективной выгоды. Зачем использовать то, в чем вы _можете_ написать код, соответствующий стандартам, когда вы можете использовать что-то, что затрудняет написание кода, который _не является_?)

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

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

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

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

Движок браузера js поддерживает исходные карты, которые позволили экосистеме новых языков в браузере транспилироваться в js; это позволило создать Dart !!!

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

Я бы использовал DSX, потому что предпочитаю, как пробелы или табуляции, определение типа до или после имени переменной. Нет смысла бороться за это, просто примите тот факт, что у людей разные предпочтения; существует более 1 редактора программирования, верно?

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

Вы разрабатываете инструмент, который намереваетесь использовать другие люди, поэтому вам нужны аргументы, выходящие за рамки «некоторым людям это может понравиться», чтобы убедить себя. Если вы не можете выразить это словами _почему_ они должны использовать его вместо чего-то другого, то почему вы верите, что они это сделают? И что может побудить вас _гарантировать_, что они будут при разработке набора функций DSX?

Просто ваше мнение, почему мы используем операторы «если» почти во всех языках, оператор «для», «класс», а теперь и «асинхронный/ожидающий».

Во-первых, эти ключевые слова (помимо async/await ) стали общеупотребительным лексиконом программирования из-за огромной популярности таких языков, как C и BASIC, в течение нескольких десятилетий. Как я уже упоминал ранее, JSX далеко не доказан в своей долговечности — он существует уже 5 лет и до сих пор не видел сколько-нибудь значительного использования за пределами React, несмотря на то, что опция доступна.

Во-вторых, есть большая разница между знакомством и условностью. if , while , for , struct , class , enum , try/catch/finally , async/await ... все это отличные способы вербального представления концепции. Есть причины защищать использование этих ключевых слов помимо того, что они просто знакомы людям — они имеют концептуальный смысл. (Конечно, это не означает, что они являются константами. Некоторые языки делают if ... then . Некоторые делают if ... elif , в то время как другие делают if ... else if , а третьи делают if...endif Некоторые делают foreach , другие делают from И так далее, и тому подобное.)

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

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

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

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

Прочитайте любую книгу о дизайне продукта. Первая глава всегда посвящена созданию заявления, манифеста, слогана, чего-либо осязаемого и выражаемого простым языком, описывающего, что представляет собой продукт и почему люди должны о нем заботиться. Есть причина, по которой наиболее распространенный совет, который дают предпринимателям-любителям, — это сделать «презентацию в лифте», что-то, что четко и кратко сообщает о продукте и розыгрыше за 30 секунд или меньше. Если вы не можете кратко объяснить, почему люди должны использовать ваш продукт, это признак того, что он страдает от кризиса идентичности. Если человек, разрабатывающий продукт, не может адекватно реагировать на критику, то это производит впечатление недоверия к собственному продукту. Обе эти вещи являются большими красными флажками для инвесторов.

В этой ситуации продуктом является DSX, а инвесторами являются разработчики, рассматривающие возможность его использования. Единственные люди, которых вы поддерживаете, — это люди, которые, по-видимому, безоговорочно поддержали бы все, что содержит «JSX» в описании. Каждый другой человек в этой теме, которого я видел, спрашивал, что вы делаете, ушел, казалось бы, неубежденным после вашего ответа.

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

Но опять же, возможно, вы исключение.

Хорошо, этот разговор вышел далеко за рамки тех дискуссий, которые мы считаем приемлемыми в сообществе Flutter, поэтому я собираюсь заблокировать эту ветку и закрыть ошибку. Пожалуйста, прочитайте https://flutter.io/design-principles/#conflict-resolution , чтобы узнать больше о том, как мы ведем себя здесь.

Следующим шагом, если кто-то захочет внести свой код для решения этой проблемы, будет разработка схемы сборки системной интеграции, чтобы мы могли работать с генерацией кода с помощью Gradle, Xcode, горячей перезагрузки и интеграции с существующими приложениями. Если кто-то заинтересован в работе над этим, пожалуйста, не стесняйтесь обращаться ко мне. В противном случае я ожидаю, что это то, над чем мы будем работать в начале следующего года. Как только у нас будет механизм для этого, такие решения, как DSX, будет легко интегрировать в экосистему Flutter. Мы можем даже найти решения, которые должны быть интегрированы по умолчанию. Тем временем мы также работаем над улучшением синтаксиса Dart, чтобы посмотреть, сможем ли мы сделать выражения пользовательского интерфейса еще проще для написания.

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