cc @lukechurch

sethladd 2017年08月14日

@cbazzaなぜこれが必要なのか詳しく説明していただけますか？たぶん、今日と比較してどのように見えるかの例を示しますか？

Hixie 2017年08月15日

さて、「 https://flutter.io/widgets-intro/#basic-widgets 」の「Basicwidgets」の例は次のようになります。

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/>}
  />);
}

cbazza 2017年08月15日

👍47 👎45

この構文はどうですか？：

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(),
  ));
}

Hixie 2017年08月15日

👍42 👎31 ❤1

うーん、少し改善されましたが、あまり良くありません...
XMLを使用して達成されることは次のとおりです。
（1）「子供」と「子供」のものはもうありません
（2）サードパーティツールによる操作（解析、分析、再生成）が簡単
（3）マークアップとプログラミングの切り替えが簡単に検出されることに注意してください。つまり、XML内にはコードを区切るための「{}」があり、コード内には「また、すべての「スタイル」のものをメイン構造から分離します。
私はこれが基本的にReactの方法を完全に支持していることを知っていますが、とにかくあなたはそこの半分にいます;）

cbazza 2017年08月15日

👍24 👎10

cc @kasperl

sethladd 2017年08月15日

（1）「子供」と「子供」のものはもうありません

なぜそれが望ましいのか、私にはよくわかりません。「子供」と「子供」は特別ではありません。たとえば、ListTileについて考えてみます。どうしますか？ IconButtonの「icon」またはMaterialAppの「home」は、名前を付けたいが、Expandedの「child」ではないのはなぜですか。 3つはすべて、ウィジェットオブジェクトを取得するための任意の引数です。「子供」と「家」には魔法のようなものは何もありません。

（2）サードパーティツールによる操作（解析、分析、再生成）が簡単

Dartコードを解析、分析、および再生成できます。しかし、私たちはそれをもっと簡単にすべきだということに同意します。今後数年間で、Dartチームがこのためのより優れたAPIを提供することを願っています。

（3）マークアップとプログラミングの切り替えが簡単に検出されることに注意してください。

なぜそれが望ましいのですか？つまり、なぜこれが「プログラミング」としてカウントされるのでしょうか。それはすべてただの表現です。

つまり、XML内にはコードを区切るための「{}」があり、コード内には「

違いがよくわかりません。

また、すべての「スタイル」のものをメイン構造から分離します。

本当に必要な場合は、今日Flutterでこれを行うことができます。XMLの場合と同じように、スタイルを変数に入れるだけです。

Hixie 2017年08月15日

👎12 👍11

なぜそれが望ましいのか、私にはよくわかりません。「子供」と「子供」は特別ではありません。たとえば、ListTileについて考えてみます。どうしますか？ IconButtonの「icon」またはMaterialAppの「home」は、名前を付けたいが、Expandedの「child」ではないのはなぜですか。 3つはすべて、ウィジェットオブジェクトを取得するための任意の引数です。「子供」と「家」には魔法のようなものは何もありません。

ボイラープレートが少なく、構造に継承されているため、言う必要はありません。

なぜそれが望ましいのですか？つまり、なぜこれが「プログラミング」としてカウントされるのでしょうか。それはすべてただの表現です。

これは、（2）に関連しています。これは、ツールメーカー、特にGUIビルダーの作業が、Dartを完全に解析する必要がないため、はるかに簡単になるためです。ただし、コードの読み取りも容易になります。

違いがよくわかりません。

XMLの形式は非常に単純なので、「{}」を見ると、dartで式を計算していることがわかります。反対の場合も同じです。ダーツコードを読んでいると、次のように表示されます。）オブジェクト階層がXMLマークアップから作成されていることがわかります。

cbazza 2017年08月16日

👍9

また、最終的な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},
             />}
          />

cbazza 2017年08月16日

👍15 👎6

ボイラープレートが少なく、構造に継承されているため、言う必要はありません。

しかし、なぜいくつかのプロパティだけのために？また、ListItemのように子スロットが2つある場合をどのように処理しますか？ 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が0、1、または複数の子を取ることができるのに対し、Centerには正確に1つの子が必要であることをどのように明確にしますか？誰かがこれをした場合はどうなりますか？：

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

これは、（2）に関連しています。これは、ツールメーカー、特にGUIビルダーの作業が、Dartを完全に解析する必要がないため、はるかに簡単になるためです。

ただし、Dart解析APIがあれば、Dartを完全に解析する必要はありません。つまり、解析したいものを解析し、残りを残します。また、実際にはXMLではないため、実際に解析する方が簡単かどうかもわかりません。下記参照。

ただし、コードの読み取りも容易になります。

ここのXMLyバージョンが読みやすいとはまったく確信していません。いくつかのビルド関数を読んだら、ネストされたコンストラクター構文にすぐに慣れます。

XMLの形式は非常に単純なので、「{}」を見ると、dartで式を計算していることがわかります。

しかし、実際にはXMLではありませんよね？これはXMLの変種です。明確に定義された解析ルールはありますか？たとえば、これは有効ですか？

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

Dartを解析せずに、最初の「}」が属性式の終わりではないことをどのようにして知ることができますか？

反対の場合も同じです。ダーツコードを読んでいると、次のように表示されます。）オブジェクト階層がXMLマークアップから作成されていることがわかります。

今日、 newキーワードも表示されているので、これを知っていますか？または、実際、上記の新しいマークアップの提案では、大文字の単語が表示されます。これは本当にXMLの利点ですか、それともDartよりもXMLに精通していますか？

また、最終的なXMLプロセッサでは、オブジェクトを親の属性に渡すことを避け、代わりに次のように子タグを作成します。

私はあなたがここで何を提案しているのか本当にわかりません。私の知る限り、これは整形式のXMLではありません。あなたが提案している構文が正確に何であるか、そしてそれがどのように機能するかについて詳しく説明できますか？たとえば、「Text」コンストラクタは消えたようです。プロセッサはそれをどのように知っていますか

テキストウィジェットを作成しますか？ <pi = "37">防御的または攻撃的に聞こえたらごめんなさい。 :-)これは何度か出てくるトピックですが、実際にこの件について議論する人がいなかったので、この会話はリクエストの背後にある理由を教えてくれるのに非常に役立ちます。私の議論の口調を否定的なものと見なさないでください。ここでのあなたの意見に非常に興味があります。</ p>

Hixie 2017年08月16日

👍24 👎7

ほら、あなたは私が言うことすべてを混ぜ合わせていて、この会話はどこにも行きません。法的に言えば、あなたは「証人をだましている」のです。

JSXが人気の理由を知りたい場合は、「reactチュートリアル」をグーグルで検索してください。過去2年間、Reactに関するすべての記事でJSXが使用されています。 Reactでコンポーネント階層を作成する元の方法（Flutterの現在の方法と同等）は、JSXが推奨される方法（ベストプラクティス）になったため、二度と言及されることはありません。

https://facebook.github.io/react/tutorial/tutorial.html
https://facebook.github.io/react-native/docs/flatlist.html

もう1つの興味深い点は、TypescriptがJSXも採用していることです。
https://www.typescriptlang.org/docs/handbook/jsx.html

XML解析（「{}」を適切にスキップするための追加のコードを含む）が、Dartのようなプログラミング言語を完全に解析するよりも桁違いに単純であることを理解できませんでした。それは事実です。ツールビルダーが開発にDartを使用することを想定していますが、そうではありません。Intellijは、DartをサポートするIDEでKotlinとJavaを使用している可能性があります（これらは言語解析に特化しているため、特別なケースです。他のすべての人は完全に苦労します。別の言語からDartを解析します）。

XMLを別の言語の中に入れることについて私が気に入っているのは、XMLがプログラミング言語とは非常に異なるため、2つの言語を認知的に分離できることです。ソースファイルをスクロールするだけで、コードと宣言型マークアップを簡単に確認できます。マークアップを装ったダーツコードではそれを達成できません。

完全に指定されていないものを選ぶのはやめましょう。それに対するあなたの疑問はすべて答えられました。JSXでそれがどのように処理されたかについてもっと学ぶだけです。私はここでこれをする時間がありません。

cbazza 2017年08月16日

👍29 👎12

防御的または攻撃的に聞こえる場合は、お詫び申し上げます。これは何度か出てくるトピックですが、実際にこの件について議論する人がいなかったので、この会話は、リクエストの背後にある理由を教えてくれるのに非常に役立ちました。私の議論の口調を否定的なものと見なさないでください。ここでのあなたの意見に非常に興味があります。

返信する必要はありません。ここでコメントしているのは、何らかの方法で決定や設計を行う前に解決しなければならない問題について透明性を確保するためです。これは基本的には単なるソクラテスの対話です。あなたの参加は大歓迎ですが、確かにあなたはあなたの提案を擁護することがあなたの責任であると感じるべきではありません。

JSXが「ホット」であることは間違いありません。 Reactでは、非JSX構文は、この問題で提案されている代替構文（現在のコードのように見えますが、「new」および「const」キーワードがないもの）よりもはるかに劣っています。私が理解しようとしているのは、JSXがReactで「ホット」であるのと同じ理由がFlutterに当てはまるかどうかです。

TypeScriptがJSXを実行することに関して、2012年に私はE4Hを指定する取り組みに携わり、それ以前にもE4Xがありました。両方の努力が死んだ。したがって、JSXと他の構文について、人々がどのようなものであるかを正確に理解することが重要です。

XMLの解析は簡単ではありません。一種のXMLを解析しますが、中かっこを使用すると、どういうわけか簡単ではありません。ある種のXMLであるが、中括弧を使用して、他の言語に埋め込まれているものを解析するのはさらに簡単ではありません。ただし、実装がどれほど簡単かは、おそらく1回か2回実装され、それを実行するライブラリが再利用されるため、大したことではありません。（私はHTMLの解析の仕様の記述に深く関わっており、XMLの同様の作業にも関わっています。また、Dartのパーサーを実装したので、マークアップ言語とプログラミング言語の解析が実際にどれほど難しいかについてはかなり良い考えがあります。は。）

XMLを別の言語の中に入れることについて私が気に入っているのは、XMLがプログラミング言語とは非常に異なるため、2つの言語を認知的に分離できることです。ソースファイルをスクロールするだけで、コードと宣言型マークアップを簡単に確認できます。マークアップを装ったダーツコードではそれを達成できません。

しかし、なぜそれができることが有益なのでしょうか？

ビルド関数が存在するFlutterアプリをスクロールすると、非常に明白です（これらは巨大なネストされた式です）。「コード」から分離することが重要な「宣言型マークアップ」についてはどうですか？

完全に指定されていないものを選ぶのはやめましょう。それに対するあなたの疑問はすべて答えられました。JSXでそれがどのように処理されたかについてもっと学ぶだけです。私はここでこれをする時間がありません。

私の知る限り、JSXは私が求めていたものを処理しません。たとえば、Reactには子スロットの概念がありません。私が見つけた最も近いものは、JSに切り替えてから、その中でJSXに戻すことで実行されることです。したがって、プログラミング言語とマークアップ言語の両方を解析できる必要があります。

Hixie 2017年08月16日

👍14 ❤1

私が理解しようとしているのは、JSXがReactで「ホット」であるのと同じ理由がFlutterに当てはまるかどうかです。

はい、まったく同じことがここでも当てはまります。それがあなたが持っている唯一のオプションなので、現在の方法はあなたによく見えます。人々に2番目の選択肢を与えると、同じことが起こります。

E4Xが死んだかどうかは関係ありません。なぜなら、永遠に生きるものは何もないからです。私はActionScriptをE4Xで頻繁に使用しており、Adobeはそこで素晴らしい仕事をしたと思いました。ある意味で、FlutterはFlexアプリを搭載したAdobeFlashの新しいバージョンです。

（私はHTMLの解析の仕様の記述に深く関わっており、XMLの同様の作業にも関わっています。また、Dartのパーサーを実装したので、マークアップ言語とプログラミング言語の解析が実際にどれほど難しいかについてはかなり良い考えがあります。は。）

マークアップ言語の解析は、命令型プログラミング言語の解析と比較して簡単であることがわかります。

しかし、なぜそれができることが有益なのでしょうか？

コードの読みやすさとシンプルさにより、他にも多くのメリットがもたらされます。

ビルド関数が存在するFlutterアプリをスクロールすると、非常に明白です（これらは巨大なネストされた式です）。「コード」から分離することが重要な「宣言型マークアップ」についてはどうですか？

巨大なネストされた式で、構造を簡単に確認できますか？この構造は、GUIビルダーなどの他のツールで交換可能に簡単に操作できますか？つまり、Adobe Flex Builderを使用してウィジェットをドラッグアンドドロップし、UIに接続してから、コードビューに切り替えて、必要なものを編集してから、GUIモードに切り替えて、ウィジェットの操作を続けます。プログラマーが「巨大なネストされた式」の内部に入り、GUIエディターが期待する構造に従わない有効なダーツコードを作成する場合、これを簡単に行うことはできません。問題のない固定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>,

ダーツバージョンよりも長く見えますが、すべてを同じ行数に配置することもできました。とにかくこれらのXMLノードを展開および折りたたむためにIDE /エディターが「+」および「-」を提供できるものです。

FlutterをReact開発者に馴染みのあるものにすると、Flutterに多くの新しいユーザーを引き付けるチャンスがあります。

cbazza 2017年08月17日

👍17 👎12

E4Xが死んだかどうかは関係ありません。なぜなら、永遠に生きるものは何もないからです。

それが死んだかどうかは問題ではありません、それがそれが死んだ理由です。それは人々が望んでいた解決策を提供しなかったので、それは死にましたか？実装の問題で死にましたか？特許の問題で死んだのですか？早すぎましたか？遅すぎる？過去の経験から教訓を学ぶことが重要だと思います。 JSXが成功したのにE4XとE4Hが失敗したのはなぜですか？

私が興味深いと思うのは、Flutterを初めて使用する人は、マークアップ言語とアニメーションGIFの2つを求めることがよくあるということです。それから3か月経っても、彼らはまだアニメーションGIFを求めていますが、マークアップ言語は求めていません。これは、Dartでビルドメソッドを作成することに慣れたら、マークアップ言語が実際には必要ないためである可能性があります。彼らはまだマークアップ言語を望んでいるが、省略を回避しているので、もう尋ねないでください。どちらを選択するかを理解する価値があります。そうしないと、（どちらの方向でも）間違った選択に労力を費やすリスクがあるからです。

巨大なネストされた式で、構造を簡単に確認できますか？

はい、少なくともXMLと同じくらい簡単です。個人的には、XMLは非常に冗長であり、構造がわかりにくくなっています。しかし、これはあなたが慣れていることに関するものだと思います。

（仮想の「終了タグ」コメントを挿入するIDEも実験しているため、実際に記述しなくても構造を確認できます。）

マークアップ言語の解析は、命令型プログラミング言語の解析と比較して簡単であることがわかります。

私の経験では、宣言型と命令型は、言語の構文解析がどれほど簡単かを判断する際に重要な区別ではありません。（たとえば、HTMLは「宣言型」ですが、これまで扱った中で最も複雑な言語の1つである可能性があります。）

コードの読みやすさとシンプルさにより、他にも多くのメリットがもたらされます。

これが主な利点である場合、これは私たちがテストできるものです。 HTML、React、iOSコード、Androidコード、Flutter、コマンドラインアプリなどの作成に慣れているエンジニアを組み合わせて、それぞれにさまざまな構文を提示し、彼らがどう思うかを説明してもらうことができます。結果のUIは次のようになります。次に、どの構文が最良の結果を得るかを測定できます。 @InMatrixは、アニメーション作業が終了した後に見ることができるものです。

この構造は、GUIビルダーなどの他のツールで交換可能に簡単に操作できますか？

はい、少なくとも原則として。 Dart式をXMLやJSON、またはその他の構造化言語に機械的に変換するのは比較的簡単です。構文を変換するだけで、実際の情報は同じです。個人的には、GUIエディターを作成している場合は別の構文に変換せず、Dartから直接メモリ内のデータ構造に解析します。

プログラマーが「巨大なネストされた式」の内部に入り、GUIエディターが期待する構造に従わない有効なダーツコードを作成する場合、これを簡単に行うことはできません。問題のない固定XML構造を使用します。

重要なのは、Dart式とまったく同じ「任意の有効なダーツコード」を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を意味しました。私はあなたの提案した構文が問題に取り組むための完全に有効な方法であることに同意します。

Hixie 2017年08月17日

👍10

私は、この製品がAdobeに存在していた過去数年間、XMLマークアップとActionScriptを組み合わせたAdobeのFlexSDKに取り組みました。 UIを定義するためのマークアップの魅力は理解していますが、いくつかの欠点も覚えています。

Flexアプリケーションのビジュアルは、マークアップとコードの観点から定義できます。私が覚えているように、コードは大規模な実世界のアプリで支配的である傾向がありました。マークアップとコードの複雑なハイブリッドとして定義されたアプリにとって、読みやすさは必ずしもメリットではありません。
「FlexBuilder」IDEは、マークアップとコードによって定義されたアプリをサポートする必要がありました。これにより、IDEの構築と保守が困難になりました。開発者はそれをActionScriptツールと見なす傾向がありました。
XML「コンパイラ」の進化と維持は、エンジニアのチームをフルタイムで忙しくさせていた大きな負担でした。コンパイラとツールキットをロックステップに保つと、SDK全体の進化が遅くなりました。

何年も経ちましたが、詳細を思い出せなくなりました。しかし、私の全体的な印象は、マークアップとコードの組み合わせでUIを定義することは、せいぜい混合バッグであるということです。

HansMuller 2017年08月17日

👍10 ❤1

それが死んだかどうかは問題ではありません、それがそれが死んだ理由です。それは人々が望んでいた解決策を提供しなかったので、それは死にましたか？実装の問題で死にましたか？特許の問題で死んだのですか？早すぎましたか？遅すぎる？過去の経験から教訓を学ぶことが重要だと思います。 JSXが成功したのにE4XとE4Hが失敗したのはなぜですか？

E4XはAdobeFlash / Flex内でのみ使用されていたActionScriptでのみ実装され、Adobeがプロジェクトを強制終了したために死亡しました。代わりに、アドビは、ロックインやエコシステムの崩壊の可能性がある単一のソースプロバイダーが存在しないオープンスタンダードに向けて方向を変えました。

私が興味深いと思うのは、Flutterを初めて使用する人は、マークアップ言語とアニメーションGIFの2つを求めることがよくあるということです。それから3か月経っても、彼らはまだアニメーションGIFを求めていますが、マークアップ言語は求めていません。これは、Dartでビルドメソッドを作成することに慣れたら、マークアップ言語が実際には必要ないためである可能性があります。彼らはまだマークアップ言語を望んでいるが、省略を回避しているので、もう尋ねないでください。どちらを選択するかを理解する価値があります。そうしないと、（どちらの方向でも）間違った選択に労力を費やすリスクがあるからです。

さて、私があなたに2つのことを尋ね、あなたが3か月以内にどちらもしなかった場合、最初のことの代替案がある場合、あなたの応答性と以前の配信パフォーマンスを考えると、まったく不可能なことだけをあなたに尋ねます。

（仮想の「終了タグ」コメントを挿入するIDEも実験しているため、実際に記述しなくても構造を確認できます。）

ちょっとおかしいですが、前に述べたXMLの終了タグを付けるのは冗長すぎるようなものです。

これが主な利点である場合、これは私たちがテストできるものです。 HTML、React、iOSコード、Androidコード、Flutter、コマンドラインアプリなどの作成に慣れているエンジニアを組み合わせて、それぞれにさまざまな構文を提示し、彼らがどう思うかを説明してもらうことができます。結果のUIは次のようになります。次に、どの構文が最良の結果を得るかを測定できます。 @InMatrixは、アニメーション作業が終了した後に見ることができるものです。

確かにそれを先に進めることができます。「React（JSXを使用）を実行すると、単に戻らない」ことがわかると思います。経験豊富なReact開発者を調査し、JSXが悪いと思うかどうか、そしてそれが行われるべきではなかったかどうかを尋ねます。あなたの道を示して、彼らがJSXをあなたが持っているものに置き換えたいかどうか彼らに尋ねてください。それを行う前に、ドアを閉めて場所をロックしてください。これらの開発者は自分たちのものをつかんで、最も近い出口に向かって疾走するだけだからです。

重要なのは、Dart式とまったく同じ「任意の有効なダーツコード」をXML構造に入れることができるということです。

もちろんですが、GUIビルダーの場合、これはバイトのブロックであり、タッチする必要がなく、簡単にスキップできます。原則としてではなく、設計/コードの互換性を実質的に可能にします。

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>

cbazza 2017年08月17日

👍7 👎5

私はAdobeFlexBuilderを拡張的に使用しました...

開発者はそれをActionScriptツールと見なす傾向がありました。

はい。ただし、デザインビューからコードビューに、またはその逆に切り替えることがよくありました。
画面を開始するには、デザインビューに移動し、ドラッグアンドドロップを使用してウィジェットをレイアウトし、最初の静的画面を生成します。次に、コードと静的データを追加して画面に入力し、本番環境に対応したもののように見える何かが実行されていることを人々に示すことができます。生産性は素晴らしかった。開発が進むにつれて、フロントエンドをバックエンドに接続し、ActionScriptコードの量が増え、コード全体を支配しましたが、リリース時に近い場合でも、デザインビューを使用して、掘り下げることなくUIを微調整することがよくありました。コード。

しかし、私の全体的な印象は、マークアップとコードの組み合わせでUIを定義することは、せいぜい混合バッグであるということです。

今日の世界ではありません。命令型言語はPythonの哲学で進化し、開発に最適です。 Reactの登場により、マークアップ（XML）が埋め込まれた宣言型手法が主流になりました。そして、JSONが推奨されるテキストベースのデータ形式になりました。

cbazza 2017年08月17日

E4XはActionScriptでのみ実装されました

E4XはECMA標準でした。 Mozillaはしばらくの間それを出荷しましたが、その後削除しました（ブラウザベンダーにとっては非常に珍しい動きです）。他のブラウザベンダーは、それを実装することを望んでいませんでした。（ただし、他の新しいECMA機能を実装しました。）E4Hを使用すると、ブラウザーベンダーはE4Hの実装に関心がなくなりました（ただし、私が発明した他の多くの機能を実装しました）。

さて、私があなたに2つのことを尋ね、あなたが3か月以内にどちらもしなかった場合、最初のことの代替案がある場合、あなたの応答性と以前の配信パフォーマンスを考えると、まったく不可能なことだけをあなたに尋ねます。

それは1つの可能な理論です。しかし、人々は他にも多くのことを求める傾向があり、彼らが求めるものの多くは実装され、アニメーションGIFの回避策もあるので、これが状況を完全に説明するかどうかはわかりません。

ちょっとおかしいですが、前に述べたXMLの終了タグを付けるのは冗長すぎるようなものです。

それはそう。これはオプションのIDE機能であり、コードに書き込む必要がないため、冗長性が問題になるかどうかに大きな違いがあります。

... ListView ..。

GUIエディターはこのマークアップをどのように処理しますか？このためのUIを視覚化する方法がよくわかりません。

Hixie 2017年08月18日

👍1

これは、このリクエストに対する反論である可能性があります。また、マークアップが必要な場合は、いくつかの洞察を念頭に置いておく必要があります。マークアップを追加すると、GWTでいくつかの課題が発生することを強く感じています。別のAPIが通過するのを見たくありません。

UIの構築に関して、他のいくつかのフレームワークがこの移行を経ているのを見てきました。このようなマークアップは、ツールに最適です。これまでのところ、IDE開発者にとっては天国です。誰が何をするかという責任を分離する方が簡単です。私はそれがより良くできると思いますが。

GWTはこのように始まり、Javaを使用してUIを構築しました。次に、UiBinderが登場しました。ここでは、仕様を使用してxmlマークアップでUIを構築できます。その後、ツールであるEclipseプラグインは、xmlマークアップでUIを生成することができました。 Androidもそれを行っているので、要点を詳しく説明する必要はありません。だから私が見たことが起こったのですが、マークアップはUIIDE開発者にとって素晴らしい働きをします。しかし実際には、マークアップは時間への莫大な投資であり、実際のプログラムに移行するための複雑なツールが追加されています。そして、ツーリングは常に最後に来ます。その間、すべてが現実に現れますが、2つの世界があります。すべてを行う2つの興味深い方法。 1つはデフォルト言語で、もう1つはマークアップ言語です。だから私は今日GWTをサポートしています。ドキュメントを作成するときは、Java用とUiBinderXMLマークアップ用の2回作成する必要があります。ですから、本当の質問は、マークアップの道を進みたいのであれば、質問する必要があると思います。それは、旅に値する複雑さの追加です。

JSXは、HTMLとjavascriptで行っていることをブレンドしたい他の問題を解決することを目的としていると思います。マークアップ仕様の追加された複雑さが、マークアップを使用してUIを作成するニーズに適しているとは思えません。特に、ターゲットとしてドキュメントマークアップ言語が実際にない場合。少なくとも日常のユーザーにとってはそうではありません。

ポジティブなことに。私は工具に取り組むのが好きです。したがって、マークアップ言語が非常に役立つことがわかります。マークアップを使用すると、ASTの記述と変更がはるかに簡単になります。

しかし、繰り返しになりますが、あなたが仕事に十分な心を持っているならば、あなたが何をするかは本当に重要ではありません。結局のところ、開発者がAPIを使用してアプリケーションをより速く作成できれば、牽引力を得ることができます。しかし、エンジニアリングチームにはどのようなコストがかかります。

本当の問題は、UIをより速く構築するにはどうすればよいかということだと思います。ツールはダーツを書くことができ、仲介者のマークアップをスキップできると思います。そして、私の目的は、それが価値がないと言うことではありませんが、道路が通った場合のすべての面でのコストを実際に数えます！

branflake2267 2017年08月18日

👍13

E4XはECMA標準でした。 Mozillaはしばらくの間それを出荷しましたが、その後削除しました（ブラウザベンダーにとっては非常に珍しい動きです）。他のブラウザベンダーは、それを実装することを望んでいませんでした。

アドビだけがE4Xを完全に擁護し、開発者の支持を得ていたと思います。ブラウザベンダーは、常にブラウザに何かを追加したり、ブラウザから削除したりしています。 GoogleはMathMLサポートを削除しませんでしたか？

それは1つの可能な理論です。しかし、人々は他にも多くのことを求める傾向があり、彼らが求めるものの多くは実装され、アニメーションGIFの回避策もあるので、これが状況を完全に説明するかどうかはわかりません。

これがReactとJSXについてです。 ましたが、しばらくの間Reactを開発するまで、Reactがテーブルにもたらすものを十分に理解していません。他のすべてのフレームワークに対する1日。

GUIエディターはこのマークアップをどのように処理しますか？このためのUIを視覚化する方法がよくわかりません。

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

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

私は\を表します長方形として、そしてその子/子が他のウィジェットの場合、その中に長方形を配置します。
この場合の子は関数であるため、「編集不可/コード」という長方形を配置するだけで、このウィジェットがコードから作成されていることをユーザーに通知できます。この場合、関数は関数の浅いラッパーであると簡単に推測できます。ウィジェットと単にそれを提示します。関数が浅い関数ラッパーであり、その中にリストアイテムウィジェットの長方形（\この場合）。

cbazza 2017年08月18日

👎7 👍6

しかし実際には、マークアップは時間への莫大な投資であり、実際のプログラムに移行するための複雑なツールが追加されています。

私が求めているのは、Dartコンパイラにこれらの単純な拡張機能を追加して、開発者が必要に応じてこのXML構造を使用して記述できるようにすることだけです。古い方法は引き続き機能し、これを行うために必要な作業の量はまったく大きくありません。実際に、babel.jsコンパイラがJSXを実行するのに何行のコードが必要かを確認できます。私は、数千行ではなく数百行を話しているのです（チェックしたばかりです）。

そして、ツーリングは常に最後に来ます。その間、すべてが現実に現れますが、2つの世界があります。すべてを行う2つの興味深い方法。 1つはデフォルト言語で、もう1つはマークアップ言語です

確かに、Reactはこのようなものであり、それはまったく問題ではありません。

ドキュメントを作成するときは、Java用とUiBinderXMLマークアップ用の2回作成する必要があります。

マークアップはコード内にあるため、Reactにはありません。

旅の価値がある追加の複雑さです！

絶対に、それはあなたが開発者を最新の技術で訓練し、彼らがあなたの会社を去る危険を冒すべきかどうかの議論のようなものです。より大きなリスクは、彼らを訓練されていない状態に保つことです。したがって、最新の技術を採用する必要があります。そうしないと、取り残されるリスクがあります。

Reactは、UI / UXを開発するための最新の技術で旅をリードしています。それは開発者との途方もない牽引力を持っています。あなたの最大のリスクは、Reactバーを満たさないことです。

JSXは、HTMLとJavaScriptで行っていることをブレンドしたい他の問題を解決することを目的としていると思います

JSXはHTML専用ではなく、React NativeはXMLマークアップからビュー（Flutterウィジェットなど）を生成します。

本当の問題は、UIをより速く構築するにはどうすればよいかということだと思います。

UI / UXをより良く構築する方法に似ています。より良い意味：より速く、より高品質（コードとUI / UX）、スムーズなデザイナーと開発者の相互作用など。

ちなみに、開発者ツールで行われた本当に素晴らしい仕事。「フラッタードクター」は最高でした!!!
私は今ガスで料理をしていて、危険なほど創造的である可能性があります;）

cbazza 2017年08月18日

👎5 👍5

ここで提起された読みやすさの質問に答えたかっただけですが、読みやすさは私たちが考慮する必要のある多くの要因の1つにすぎないことを理解しています。

コードの読みやすさとシンプルさにより、他にも多くのメリットがもたらされます。

これが主な利点である場合、これは私たちがテストできるものです。 HTML、React、iOSコード、Androidコード、Flutter、コマンドラインアプリなどの作成に慣れているエンジニアを組み合わせて、それぞれにさまざまな構文を提示し、彼らがどう思うかを説明してもらうことができます。結果のUIは次のようになります。次に、どの構文が最良の結果を得るかを測定できます。 @InMatrixは、アニメーション作業が終了した後に見ることができるものです。

コードの可読性を経験的に研究する方法は確かにあり、第4四半期の計画の時期になると、より真剣に議論することができます。このような調査を有用なものにするために、Flutterプログラミングのコンテキストで開発者にとってどのような種類の読み取りタスクが重要であるかを定義する必要があります。ビルドメソッド全体を読み取り、結果のUIがどのようになるかを理解するだけでなく、読みやすさは、ダーツファイルでのビルドメソッドの識別、中括弧の照合、インラインコメントの読み取りなどの小さなタスクにも影響します。

これらのより狭い範囲のタスクのいくつかをサポートするために、最初にエディターでUIの機能強化を試すことができます。これは通常、マークアップ言語を導入して維持するよりも安価です。 VSコードのクロージングラベル機能は、そのようなUI拡張機能の1つであり、対処しようとしているブレースマッチングの問題をどれだけうまく解決できるかを理解する必要があります。このスペースには、まだ試したことのないオプションがたくさんあります。たとえば、別のフォントや背景色を使用してビルドメソッドを表示し、開発者がそれを残りのコードから精神的に分離できるようにすることができます。

私が重要だと思うもう1つのことは、巨大なビルドメソッドを作成せず、フレームワークの構成の性質を利用するように人々を促す方法です。ビルドメソッドが画面の高さよりも高い場合、DartまたはXMLに関係なく、読みにくくなります。

InMatrix 2017年08月21日

👍1

私が重要だと思うもう1つのことは、巨大なビルドメソッドを作成せず、フレームワークの構成の性質を利用するように人々を促す方法です。ビルドメソッドが画面の高さよりも高い場合、DartまたはXMLに関係なく、読みにくくなります。

ビルドメソッドだけではありません。 buildメソッドがウィジェットツリーを構築するために呼び出すのは、他のすべてのメソッドです。 Reactでは、小さなメソッドを使用してサブツリーピースを構築し、それらを大きなツリーに呼び出すのが非常に一般的です。

また、JSXを使用するWebStormでは、各XMLノードに+/-があり、ノードと子を展開/折りたたんで、画面の高さよりも大きい構造を読みやすくすることができます。

cbazza 2017年08月21日

Flutterで私たちが見つけた1つのことは、大きなビルドメソッドはパフォーマンスに優れていないということです。私たちは、ビルドメソッドを小さな再利用可能なウィジェットに分解するように人々に勧めています。特に、Flutterでは、他のメソッドの結果からビルドされたビルドメソッドを持つことは、簡単にするのではなく、むしろお勧めできないアンチパターンのようなものです。（これは最近の認識の一部であるため、多くの例やウィジェットはまだこれをうまく行っていません。）

Hixie 2017年08月21日

私たちは、ビルドメソッドをより小さな再利用可能なウィジェットに分解することを人々に奨励しようとしています。

それは本当に再利用可能なウィジェットになるのでしょうか、それとも単にラッパー/複合ウィジェットになるのでしょうか？再利用可能であるということは、少なくとも2つの使用インスタンスが必要であることを意味します。

https://flutter.io/catalog/samples/basic-app-bar/のAppBarは非常にユニークであるため、再利用可能なコンポーネントとは言えません。これはラッパー/複合コンポーネントであり、これらの場合、UIのその部分を構築するためにローカルメソッドを使用しないのはなぜですか？もっと多くのことができれば、ラッパー/複合コンポーネントに配置するのが理にかなっていると思います。

Flutterで私たちが見つけた1つのことは、大きなビルドメソッドはパフォーマンスに優れていないということです

パフォーマンスについて言及したので、アニメーションループでビルドメソッドを駆動すると、スムーズなアニメーションのパフォーマンスに問題が発生します。特にビルドメソッドがユーザーコードであることを考慮すると、ビルドメソッドが1秒間に60回以上呼び出されることは望ましくありません（たとえば、非常に長いループが発生し、アニメーションがスキップされる可能性があります）。 Flutterの初心者である私は、おそらくそれを間違えました。

cbazza 2017年08月21日

https://flutter.io/catalog/samples/basic-app-bar/のAppBarは非常にユニークであるため、再利用可能なコンポーネントとは言えません。

比較的小さいので大丈夫です。

パフォーマンスに関しては、これはこの問題ではややトピックから外れているため、話し合いたい場合は新しい問題を提出してください（または、flutter-devに電子メールを送信するか、スタックオーバーフローに投稿してください）。

Hixie 2017年08月22日

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

nsuper 2017年11月20日

この問題が埋もれてしまうのを見るのはおかしいです。私の意見では、Flutterがウィジェットを作成するためのJSXのような構文を実装することは成功または失敗になります。

私は単にターゲットオーディエンスを理解していません。多くのiOSおよびAndroid開発者はネイティブに反応するように動いています。それは、市場シェアを獲得する絶好の機会のようです。

関係者には、React Nativeを試して、私たちが話していることを確認することをお勧めします。

birkir 2017年12月11日

👍14 👎6

FlutterでJSXを少し見逃しません。これは、あちこちでいくつかの小さな利益のためにフレームワークとツールを肥大化させるだけです。

zoechi 2017年12月11日

👍18 👎5

@birkir私はこの問題について100％あなたと一緒です。 Flutterに最適なJSXの欠如により、Flutterは古くて錆びたように見え、1990年代のテクノロジーのように感じられます。実際、誰もが何らかの形でJSXを採用しているようです。最新のものは人気のあるVue.jsフレームワークです。

cbazza 2017年12月11日

👍10 👎9

+1

ghulamMustafaRaza 2017年12月11日

@zoechi JSXでのこれまでの経験は何ですか、実際に使用したことがありますか、それとも見ただけですか？皆さんはJSXを過小評価していて、あちこちでわずかな利益が得られると言っていると思います。ユーザーがいない場合、製品はありません。

birkir 2017年12月12日

👎3 👍3

@birkirここでは、JSXについて多くの興奮が見られますが、ほとんど主観的な読みやすさを除けば、FlutterがそのようなDSLを使用することで何が得られるかをわざわざ説明する人はいないようです。

より多くの機能は通常、フレームワークを改善するのではなく、フレームワークを占有するだけです。
それらを実装すると、他の領域から欠落している多くのリソースも消費します。欠落している機能により、実際に特定のアプリケーションを実装できなくなります。

したがって、FlutterがJSXのようなものを入手することに興奮している場合は、説得力のある議論を書くために時間とエネルギーを費やす必要があります。
他の人もそれを持っているので何かを追加するだけで、おそらくそこにある最も弱い議論です。

また、Dartを改善して、Flutter UIコードの記述の冗長性を減らし、JSXのケースをさらに弱める計画もあります。

それで、あなたの説得力のある議論は何ですか？

zoechi 2017年12月12日

👍13 👎2

本当！！！「Flutterが何を得るのかをわざわざ説明する人はいないようです...何とか何とか何とか」。
このスレッドを完全に読んでいませんか？あなたの注意力はJSXの知識よりも大きいですか？

あなたたちはNIH症候群に苦しんでいます（ここでは発明されていません）。「優れた芸術家はコピーし、優れた芸術家は盗む」、平凡な芸術家は、まあ、あなたのように振る舞います。

JSXのサポートは比較的単純であり、新しい顧客（React Nativeモバイル開発者）をプラットフォームに引き付けるのに非常に役立つという事実だけで、皆さんが目にすることのない簡単なことです。プラットフォームにとっては大胆ではありません。

cbazza 2017年12月12日

👎24 👍6

議論するときは建設的な口調を保ってください。

mit-mit 2017年12月12日

👍21

他の人が持っているので機能を追加することは弱い議論です。わかった。
フラッターにホットリロードがあるのはなぜですか？それはどこから来ましたか？イエス様。

どうして私たちはあなたたちに確固たる議論を提供できなかったのですか？ プロジェクトの牽引力と開発者の誘致が私たちの最大の理由です。

理由2、読みやすさ：

https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/demo/cupertino/cupertino_buttons_demo.dart vs https://gist.github.com/birkir/e921158239c324ab95bb0b174383a562

理由3、 GUIビルダー。 READMEの最初の行を引用します。

開発者とデザイナーがiOSとAndroid向けの最新のモバイルアプリを構築するのに役立つ新しいモバイルアプリSDK。

ベータ版に到達する前に、FlutterがPolymerと同じウサギの穴を下って行くのを見たくありません。

birkir 2017年12月12日

👍12 👎4 ❤2

プロジェクトの牽引力と開発者の誘致

関係はまだ不明です。

理由2、読みやすさ：

Dartコードを読みやすくすることは、私にとってより良い目標のようです。

理由3、GUIビルダー。 READMEの最初の行を引用します。

私が覚えている限り、Dartコードを使用することでそれを防ぐ理由はないということはすでに上で述べました。

zoechi 2017年12月12日

👍9 👎2

あなたの反論は本当にその考えを却下することはできませんね？

関係はかなり明確です。プロジェクトが人気になることが目標でない限り？
素晴らしい！ JSXの読みやすさに近いでしょうか？そのようなことについての現在の提案は何ですか？
それができると述べられました。現在利用可能なGUIビルダーにJSXサポートを適応させることは、はるかに簡単になります。

birkir 2017年12月12日

👎4 👍3

FlutterUIコードの記述をより冗長にするためにDartを改善する計画もあります

現在の方法でいくつかの改善が行われる可能性があることを認めていただき、ありがとうございます。
そのような提案の詳細を提供してください。最善の策は、フィードバックを得るためにReactNativeコミュニティと対話することです。

cbazza 2017年12月12日

😄1

いくつかのDart言語機能のリクエストにより、コードがより短く/読みやすくなる可能性があります。

Dart 2のオプションのnewおよびconst
どこでも名前付き引数を許可するという提案の議論のためのメタ問題---これにより、 child引数を持つウィジェットが名前付き引数をスキップできるようになる可能性があります。
- 引数の数が可変-これにより、 children引数を持つウィジェット（行や列など）がこの名前付き引数とそのリスト宣言をスキップできるようになります。

これらの変更により、コードは次のようになります。

  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
  }

a14n 2017年12月13日

👍15 😕3

この会話は熱くなっています。私は皆に私たちの行動規範を読むことを勧めたいと思います：
https://flutter.io/design-principles/#conflict -resolution
誰もが敬意を持って生産的に貢献できる方法を検討している間、私はこの会話を数日間締めくくります。

Hixie 2017年12月13日

👍4

UIを構築するための構文は、モバイル開発エクスペリエンスの非常に重要な部分であることは誰もが知っています。今のところ、構文は少し冗長です。マージンを追加するためだけにnewを実行する必要があります。 margin: new EdgeInsets.symmetric(horizontal: 4.0) 、もっと簡単な方法があると思います。

KotlinチームがAndroid開発者のために行ったようなDSLを構築することは可能でしょうか？これは、AndroidUIを構築するためのDSLであるAnkoと呼ばれます。

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

簡潔な構文は、コードを読みやすく保守しやすくするのに役立ち、構築作業を楽しくすることもできます。それは重要です。決定を下す前に、Flutterチームが真剣に見積もりを行ってください。私たちは皆、Flutterが今後数年間でより大きな成功を収めるのを見るのが大好きです。

xinthink 2017年12月23日

👍4 ❤1

XMLのような構文をFlutterに導入しないでください。

私はAndroidJavaで1年以上プログラミングした後、クロスプラットフォームのツールセットを探し始めました。
私はReactNativeから始めて、次にReactを試しました。 JSX構文は、JavaScriptでもHTMLでもないため、あまり好きではありませんでした。
Flutterを試してみると、始めるのがはるかに簡単であることがわかりました（おそらく、主にJavaのバックグラウンドが原因です）。

XML構文がフラッターに追加されるのを見たくない理由のいくつかを考えます：

学ぶべきもう一つのこと-代わりに先物を学ぶために費やすことができます; P
コンテキスト切り替え-XMLとコードの間でコンテキストを切り替えていますが、これは不要な認知的負荷です。
午前中にJavaで、午後にPythonでプログラミングした日がありました。 Reactを使用すると、Javascript、Babel、JSX、HTML、CSSなどを1つのコードベースで理解する必要がある場合があります。
FlutterでXMLが不要な理由は、dartがXML属性をかなりうまく置き換える名前付き引数を持っているためです。
Dartには非常にクールなdartfmtがあり、コードを簡単にインデントできます。

Androidとの比較

とにかくプログラマティックな方法を学ぶ必要がありますが、なぜ別の方法を追加するのですか？
androidのXMLレイアウトは、デバイスに変更を表示するのに高速ですが、Flutterでの実行はとにかく実質的に瞬時であるため、XMLを追加してもその利点はありません。
Android XMLとプログラムによる組み合わせにより、XMLスニペットを膨らませたり、プログラムでXMLツリーに挿入したりするなどの複雑さが増します。
Flutterでのインスタント実行は非常に高速であるため、XMLモデルがどのように表示されるかを視覚化する必要はありません。キーを押すだけで、変更をすぐに確認できます。
プログラムによるレイアウトの問題によるエラーは、XMLのレイアウトの問題とは異なるため、理解する必要のある2つのセットがあります。

さらに一歩進んで、pubspec.yamlを削除し、それをpubspec.dartに置き換えて、dartコードで構成します。

Rockvole 2018年01月19日

👎5 👍5

開発者がページを視覚的にレイアウトすることの難しさに不満を持っている場合は、ドラッグアンドドロップでテーマとデザインページを視覚的に設定できるレイアウトデザイナーを作成することをお勧めします。次に、編集することを意図していないFlutterコードを生成しますが、アプリの作成に使用できるクラスを作成します。

Android XMLのように双方向編集（XML /レイアウト）である必要はありませんが、後で使用するためにレイアウトを保存するだけです。それを変更する必要がある場合は、コードを再生成し、（うまくいけば）いくつかの引数を変更するだけです。

Rockvole 2018年01月19日

私はこの会話が古く、かなり熱くなっていたことを知っていますが、ここで起こっていると私が考えることに数行を落としたいと思います。

フラッターは新しいです。それは物事を行うための完全に新しい方法です。はい、それは反応パラダイムから借用しました。ただし、同じ手順に従う必要があるという意味ではありません。フラッターのチームの目的は、開発者をネイティブのリアクションからフラッターに引き付けることではなく、開発者が興味を持ってくれる可能性のある新しいものを構築することだけだと思います。Googleはそれを社内で使用してから世界と共有し、それ。私は@Hixieとコメントを共有し、UIを構築するのはJSXと何ら変わりはありません。はい、純粋なダーツを正しくするためにもう少し冗長です。ただし、実際にはコードのデバッグがはるかに簡単になります。

マークアップ言語やJSX、またはテクノロジーの上にあるものに反対する理由は、プラットフォームからの作業が大幅に増えるためです。 UI用のマークアップ言語を作成することは喜ばしいことですが、非常に多くの開発者がプラットフォームに取り組んでいて、それを機能させるために泣き叫び、髪を引っ張っています。もう1つの観点は、JSXがJavascriptコミュニティで機能したことです。これまでのところ、その主な目的は、開発者にとって物事を簡単にし、トレードオフを心配しないことです。誤解しないでください。とにかくHTMLはマークアップであるため、Web用のReact（JSX）は天国で行われた一致でした。しかし、React Nativeの場合は、リポジトリ内のすべてのコードを調べて、それを機能させるために実行する必要がありました。 JSXをフラッターに追加するには、新しい機能を追加するときに、膨大な作業と2つのことを考慮する必要があります。また、子パラメータとconstおよび新しいキーワードを削除できるようにするためだけに？私は、コードで実際に何が起こっているのかを知り、何が起こっているのかを制御できる方が、オーバーヘッドを追加するだけの魔法の構文よりも好きです。

それが私の意見です。新しい巨大な議論を始めたくない。 JSXはreact / javascriptコミュニティで機能したため素晴らしいのですが、Dart / flutterの場合、ReactNativeから開発者を引き付けるためにJSXを追加するのは少しやり過ぎだと思います。

うわー、ブログ投稿xDを書いた可能性があります

franzsilva 2018年01月19日

👍4 😄1

@Rockvole 、

学ぶべきもう一つのこと-代わりに先物を学ぶために費やすことができます; P

学ぶことは、現在の再帰的なオブジェクト構築の怪物をより単純にし、日常のReact Native開発者に馴染みのあるものにするので、人々はそれを学ぶことを好むだろうと思います。

コンテキスト切り替え-XMLとコードの間でコンテキストを切り替えていますが、これは不要な認知的負荷です。

問題ではありません。コンテキストスイッチはありません。プログラミングUI / UXをよりクリーンにする環境の一部にすぎません。

次に、編集することを意図していないFlutterコードを生成します

なぜだめですか？その時はあまり役に立ちません。

cbazza 2018年01月19日

@franzsilva

ネイティブの反応から開発者を引き付けてフラッターに来ることは、フラッターのチームの目的ではないと思います

本当！！！ React Nativeが支配的であり、クロスプラットフォームツールを使用するモバイル開発者の総数が限られていることを考えると、FlutterはReact Nativeの人々を引き付けることなくホームランヒットになることができると本当に思いますか？

はい、純粋なダーツを正しくするためにもう少し冗長です。ただし、実際にはコードのデバッグがはるかに簡単になります。

それは正しい記述ではありません。単なるjavascriptコードであるJSXコードのデバッグは、簡単でも難しいものでもありません。同じです。

マークアップ言語やJSX、またはテクノロジーの上にあるものに反対する理由は、プラットフォームからの作業が大幅に増えるためです。

プラットフォームにどれだけの作業が配置されたかを誰が気にしますか？開発者は、コードの可読性と生産性を向上させる最新の技術を求めています。新しいものがより良い代替手段を提供するとき、開発者は古くて時代遅れの技術を使いたがりません。

私は、コードで実際に何が起こっているのかを知り、何が起こっているのかを制御できる方が、オーバーヘッドを追加するだけの魔法の構文よりも好きです。

これはナンセンスです。JSXで何が起こっているかを正確に知っています。これは、ほぼ1対1に変換する小さな小さなレイヤーですが、多くの利点を提供します。私に言わせれば、コンパイル時間のオーバーヘッドはごくわずかです。

JSXはreact / javascriptコミュニティで機能したため素晴らしいのですが、Dart / flutterの場合、ReactNativeから開発者を引き付けるためにJSXを追加するのは少しやり過ぎだと思います。

JSXはDart / Flutterにも最適です。それは決してやり過ぎではありません。 JSXがDart / Flutterで機能しない理由はありますか？コード化してリリースした場合、Dart / Flutterの開発に適していないのはなぜですか？

cbazza 2018年01月19日

👎3 👍3 ❤2

@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,
    ),
  );

これらの_正確な_セマンティクスをどのように表現することをお勧めしますか？

Hixie 2018年01月19日

  // 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,
    ),
  );

Hixie 2018年01月19日

👍7 ❤2

Babel.jsには、このすてきな小さなWebサイトがあり、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％ 20world！％3C％2Fdiv％3E％3B％0A％7D

DSXとDartで同等の処理を行います。概念実証として、どれくらいの時間がかかるか見てみましょう...

cbazza 2018年01月19日

🎉6

これが@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>
);

読みやすさを向上させることが目的であれば、将来のダートはスペードで勝つと思います。

何がタグに変わるか（おそらくWidgetのみ）、または必要な/許可される子要素の数を知るために、ドキュメントを確認する必要があります。

JavaScriptからHTMLを出力することが目標である場合、JSXは中立的な立場として非常に理にかなっています。 1日の終わりにタグが必要な場合、 React.createElement('div', null, 'foo')は<div>foo</div>よりもはるかに悪いためです。

あなたの目標が... DartからDartオブジェクトのツリーを出力することであり、Dartコンストラクターの適切にフォーマットされたツリーが完全に（おそらくもっと）読みやすい場合、XMLを迂回する意味がわかりません。そして私はAndroidから来るそれらのXMLを見逃していません。

jayjun 2018年01月22日

👍19 ❤2

XMLを使用することで可能になります...話をするだけで5か月が経ちましたが、今はそれについて何かをしているので、少し時間を取ってください（私にはフルタイムの仕事があり、週末には約4時間しか余裕がありません）。

cbazza 2018年01月22日

🎉3

ちょうどこのスレッドを見つけました。両側で興味深いものです。 Flutterに興味を持っているReact開発者として、私が言及していない他のいくつかの議論があります（私はすべてのコメントを簡単にざっと読んだだけですが）。

タグ宣言を閉じると、子とプロパティの理解が深まります。残念ながら、UIは深くネストされている可能性があり、明確なタグと不明なタグがあると、子を明確にして解析するのに役立ちます。また、コンポーネント間でコードを移動し、何かが適切でない場合（たとえば、前の終了タグ）を非常に宣言的に確認することもできます。これは、ネストされた複数の）の場合は注意が必要です。
コンストラクター内にネストされた複数のコンポーネントが表示されたときの最初の直感的な反応は、「コールバック地獄」へのフラッシュバックをもたらします。 JSが良くなり始めたのは非常に辛い時代でしたが、それに戻ると少し後退したように感じます。
＃2に関連して、残念なことに、人々に切り替えるように説得する必要があります（または少なくとも試してみる必要があります）。多くの人がReact / React Nativeを使用しており、さらにHTML / JSを使用しています。 Reactの問題点のいくつかを具体的に対象とする、シンプルでほとんど構文的に馴染みのあるチュートリアル/ガイドを作成することは、少し疲れている人にとっては非常に説得力があるかもしれません。

tehfailsafe 2018年01月25日

👍14

ReactがWeb開発者コミュニティで人気を博した主な理由の1つは、JSXのサポートでした。

このような素晴らしい機能のリクエストに「反対票」が表示されるのは本当に残念です。読みやすさが向上し、採用が促進されます。

これがOpenJavaScriptとDartの大きな違いだと思います。 JavaScriptは真にオープンソースですが、Dartでのリクエストはこのように会話を始め、最終的には反対票で意欲を失います。

新しいアイデアのためのより多くの余地を作ろう！

sanketsahu 2018年02月01日

👍14 👎3 ❤1

@jayjunすごいですね！どこかでやってみてもいいですか？

sanketsahu 2018年02月01日

@sanketsahusoftすぐに私のバージョンを試すことができるようになるので、心配しないでください。@ jayjunよりも優れています。

クイックアップデート：2週間前に、UIが正常に機能しました。先週末、パーサーが完全に機能し、トランスパイラーの半分が機能しました。今週末、スーパーボウルを避ければ、それを終わらせたいと思っています;）

私は頑固さのような厚い肌とラバを持っているので、私はこれらの反対票にさえ気づいていません、しかしそれらを指摘してくれてありがとう。

カルロス。

cbazza 2018年02月01日

🎉7 👍2

これは、終了タグを見失う問題に役立ちますか？
アイデア：自動生成された終了タグ

Rockvole 2018年02月01日

@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 2018年02月01日

@abarth 、あなたがした興味深いことは、式が別のタグである場合に式の外観を単純化する3番目の属性の可能性を追加することでした。
JSXには次のものがあります。
1- <tag attrib=""/>または<tag attrib=''/>
2- <tag attrib={}/>
あなたは別のものを提案しました：
3- <tag attrib=<anotherTag.../>/>
JSXでは、次のように記述する必要があります。
<tag attrib={<anotherTag.../>}/>

cbazza 2018年02月01日

@cbazzaええ、3番目のケースはFlutterで非常に一般的であるため、余分な{のネストをスキップするのは理にかなっています。

abarth 2018年02月01日

@abarthああ、でも私はcssのようなスタイルを使ってそれらのほとんどを不要にしています!!! トランスパイラーは、これらのcssのようなスタイルを適切なFlutter呼び出しに拡張します。タグ付けの構造が大幅に改善され、InVision、Figma、Atomicなどのデザイナーツールからスタイルを簡単にインポートできるようになりました。

cbazza 2018年02月01日

👍1

@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 2018年02月02日

@jayjun 、はい、それは問題ではありません。トランスパイラーは単純なXMLプロセッサーであり、式（{}内のすべて）の解析に関しては、テキストBLOBになるため、逐語的に書き出されます。

cbazza 2018年02月02日

@xinthink

KotlinチームがAndroid開発者のために行ったようなDSLを構築することは可能でしょうか？

多くの人がFlutterでKotlinを使いたいようです。正直なところ、私にはわかりません。なぜ開発者はDartの車輪の再発明を決めたのですか？

私の謙虚な意見では、FlutterはJSXを必要としません。 FlutterはDartではなくKotlinを選択する必要がありました。 Kotlinを使用すると、すぐに使用できる美しい構文で複雑なUIロジックを記述でき、巨大なコミュニティ、本番環境に対応したツール、Android開発でのバトルテストが可能になります...

ただ言って。

stanmots 2018年02月07日

Kotlinは素晴らしいです、私はファンですが、iOSでは動作しません.....実際には動作しますが、まだリリースされていません（現在のプレリリース段階）。
UI / UXの開発には、AnkoDSLではなくJSXの方が好きです。宣言型マークアップを命令型コードから視覚的に分離でき、コンポーネントを非常に簡単に組み合わせることができるという事実が気に入っています。

cbazza 2018年02月07日

Dart、Kotlin、Swiftにはすべて類似点があります。
https://sethladd.github.io/swift-is-like-kotlin-and-kinda-like-dart/

私はすきです：

あなたがJavaから来た場合、Dartはより馴染みがあります。
Dartのスキルを活用して、Webページを作成できます。これはアプリを作成するときに役立ちます。Web上で機能を作成して（そしてWebViewに表示して）、より意味のある機能を作成できます（クイック管理ページや製品リストなど）。グーグルインデックスを作成する必要があります）。
Dartは最初からjavascriptにコンパイルするために構築されましたが、後で言語に追加するのは簡単ではないと思います。

これらは基本的に、私がKotlin / Swift / ReactよりもDartを選んだ理由です。

_グーグルでダートとスイフトをサポートするという決定は私を混乱させますが、新しいフクシアOSは私を混乱させます。_

Rockvole 2018年02月07日

👍2 🎉1

あなたがJavaから来たのなら、Dartがもっと馴染みがあるかどうかはわかりません。私はJavaから来ましたが、KotlinやSwiftに問題はありません。基本的に型宣言は逆になり、PascalとActionScriptで使用されていたので特に新しいものはありません。

はい、Dartを使用してWebページを作成することはできますが、それについてはあまり取り上げられていません。 Web上でうまく機能している他の言語はTypeScriptだけです。これは、最も人気のある上位3つのWebフレームワークとうまく統合されているためです。

React on theWebで利用できるさまざまな構文を見てください。
https://github.com/Workiva/over_react#fluent -style-component-consumption
どちらのDartバージョンもJSXに対抗するチャンスはありません!!!

TypeScriptはJavascriptにコンパイルするように設計されており、そのためにはDartよりも優れています。 JSXもサポートしています。
ダートは四方八方から圧迫されています。 Swiftには勢いがあるので、赤ちゃんと一緒にFuchsiaOSでサポートするのが賢明です。

cbazza 2018年02月07日

試作品までどれくらいかかりますか？使いたい！

私はしばらくの間Reactを使用しましたが、JSXは私の生産性を10倍に高めました。これは物議を醸す問題ではありません。他のチームは、これがより良いと正しく判断したので、Flutterを使用しないのはなぜですか？（レトリック：私はスレッドを読みました...（facepalm））

yuriy-manifold 2018年02月10日

私は今週末に取り組んでいますが、新しいアイデアで範囲を拡大し続けているので、今週末に何かを出すことができればと思います。

私が実験している興味深いことのいくつか：
1）子タグにxml名前空間を使用して、親に正しいDart名前付き引数を挿入します。
2）プロパティのようなスタイルをより適切に整理するためのスプレッド演算子。これにより、マップ内のxmlの外部で定義/グループ化してから、通常のReactのもののようにタグに取り込むことができます。
3）CSSからフラッタースタイルを生成するstyleCSSプロパティ。

（1）と（2）はジェネリックなので、すべてのDartFlutterコードで機能します。
（3）はFlutterウィジェット（コンテナ、テキストなど）ごとに特化されており、現時点ではこれら2つのみを実行しています。

cbazza 2018年02月10日

👍2

@ yuriy-JSで何かが機能したからといって、それがDartにとって良いアイデアであるとは限りません。
上記の議論を読んだことがあれば、実際には物議を醸していることがわかります。
2つの言語が1つよりも優れている理由がわかりません。

zoechi 2018年02月11日

👍7 👎2

JSで何かがうまくいったからといって、それがDartにとって良いアイデアであるとは限りません。

JSXは、言語に関係なく、リアクティブフレームワークでのUI / UX開発のための素晴らしいアイデアです。もっと自由な時間があれば、JSX for LogoであるLSXを出すでしょう;）

2つの言語が1つよりも優れている理由がわかりません。

iOSをObjective-CとSwift（2言語）でプログラムできます
AndroidをJavaとKotlin（2言語）でプログラムできます
..。

cbazza 2018年02月11日

👍2 😕1 👎1

私はまだJSXを支持する議論を見ていません。
上記の議論には、「より良い」、「生産性が向上する」などの議論のみが含まれていますが、特にJSXのようなものとの違いを減らす計画された言語変更を考慮すると、純粋なDartコードよりも実際に優れている理由や方法についての議論はありません。
純粋なDartコード。

@cbazza

iOSをObjective-CとSwift（2言語）でプログラムできます
AndroidをJavaとKotlin（2言語）でプログラムできます

それはJSXの議論とどのように関連していますか？それはどのように利点と見なすことができますか？
SwiftはObjectiv-Cの後継であるため、iOSで使用できます。
Kotlinは、Javaの大幅な改善と見なされているため、Androidで使用できます。
JSXがDartに取って代わるべきだとあなたが主張しているように聞こえます。それは私にはあまり意味がありません。

zoechi 2018年02月11日

👍7 👎2

@zoechi

それはJSXの議論とどのように関連していますか？それはどのように利点と見なすことができますか？
SwiftはObjectiv-Cの後継であるため、iOSで使用できます。
Kotlinは、Javaの大幅な改善と見なされているため、Androidで使用できます。
JSXがDartに取って代わるべきだとあなたが主張しているように聞こえます。それは私にはあまり意味がありません。

あなたは実際にそれを言いましたが（JSXは現在の方法よりも洗練された改善です）、間違った結論に達しました（JSXがDartに取って代わります）。

cbazza 2018年02月11日

@cbazzaそれはほとんど同じです

プレーンダートに対する実際の利点は何ですか？

「JSXは巧妙な改善です」は決して説得力がなく、議論ではありません。
それは（再び）それを裏付ける議論のない個人的な意見です、
上記の他のプロJSX引数と同様です。

あなたが良い議論を提供する気がなければ、誰かがあなたの提案を検討することを期待することはできません。

JSXのようなものをDartに追加すると、FlutterツールとIDEで非常に多くの作業と複雑さが発生します。あなたはそれを見ることを検討するために他の人に適切な議論を提供する必要があります。

zoechi 2018年02月11日

👍4 👎1

@zoechiは、「良い」引数を要求する壊れたレコードのように聞こえます。以前はたくさんのことが与えられていましたが、あなたはそれを取得できませんでした。これはOKです、「それぞれに」。

JSXのようなものをDartに追加すると、FlutterツールとIDEで非常に多くの作業と複雑さが発生します。あなたはそれを見ることを検討するために他の人に適切な議論を提供する必要があります。

実際には、私の仕事はほとんど準備ができていて、週末にしか仕事をしていなかったことを考えると、ほとんど時間がかかりませんでした。

繰り返しになりますが、DSXは、現在の方法を変更しないため、人々が使用するかどうかを選択できる巧妙な改善であり、他の人（React開発者）がすぐに慣れ親しむ代替手段を提供するだけです。

cbazza 2018年02月11日

👍5 👎3

@cbazza

たくさん与えられました

あまり。真実かどうかは別として、一般的な主張です。
他の人が確認できるような追加の詳細は提供されませんでした。

実は、私の仕事はほとんど準備ができています

すごい。そうすれば、Flutterチームが何かをする必要がなくなり、問題を解決できます; p
これには、FlutterでサポートされているすべてのIDEでのオートコンプリートと構文チェックのサポートが含まれていますか？

zoechi 2018年02月11日

👎2

すごい。そうすれば、Flutterチームが何かをする必要がなくなり、問題を解決できます; p

;）

これには、FlutterでサポートされているすべてのIDEでのオートコンプリートと構文チェックのサポートが含まれていますか？

ほとんどのIDEはすでにXMLとJSXをサポートしているので、私のマイナーな追加を追加するのは難しくありません。

cbazza 2018年02月11日

JSX構文がAngularDartでもっと評価されるのではないかと思いますか？「より良い」というよりは、慣れ親しんだ状況のようです。 JSX構文は、おそらくWeb開発者にとってより自然に感じられます。

ある日、色を強調するさまざまなコードを使用するだけでも、プログラミングが厄介だと感じることは知っています。

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

Rockvole 2018年02月11日

はい、Angularの人々はJSXに非常に慣れていますが、React Native開発者もそうです。これは、モバイル開発用です。 JSXは確かに現在のFlutter開発者には採用されませんが、この2番目の選択肢は新しい開発者をFlutterに引き付けるでしょう。それは確かです。

上記の記事はそれを非常に間違っていました。JSXなしのReactは基本的に存在せず、すべてのリアクティブWebフレームワークでは、DSL上でマークアップとプログラミングを混在させることができます。

cbazza 2018年02月11日

時間が来ました...
オンラインDSXトランスパイラーを発表できることを大変うれしく思います。
https://spark-heroku-dsx.herokuapp.com/index.html

cbazza 2018年02月12日

👍10 🎉4 ❤2 😕2

トランスパイラーcbazzaとの素晴らしい仕事
JSXでフォローしやすいのは、終了タグです。私が前に述べたアイデア：
アイデア：自動生成された終了タグ

あなたの最初の例では、（将来のDartでオプションのnewを削除した）のフラッターコードを与えるでしょう：

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;

Rockvole 2018年02月12日

@cbazzaコミュニティとそのようにUIを構築したい人々のためにあなたの仕事に感謝しますが、Flutterでそのようなものを使用することを強制されないことを本当に望んでいます：-（（（

zoechi 2018年02月12日

👍8 👎2 😄1

Flutterの初心者ですが、Reactにかなり精通しているので、私にはいくつかの点が際立っていました。

状態管理モデルはほとんど同じです
ウィジェット/コンポーネントの仮想レンダリングツリーはほとんど同じです
状態とコンポーネントモデルを知っているので、Dartの詳細とプラットフォームAPIを除いて、基本的に今すぐアプリを作成する準備ができていると感じていますが...
スタイリング言語はつまずきです。 https://flutter.io/web-analogs/を参照していますが、動作させるために必要なインポート（EdgeInset？Color？）や、クラスインスタンスの代わりにプリミティブを使用する必要がある場合を理解するのは簡単ではありません。
@cbazzaのDSXコンバーターのCSSパーサーは、Flutterモデルで同等のレイアウトを理解するのに非常に役立ちます。

JSXについて：

Flutterパターンをサポートするために新しいJSX構文を発明する必要はないと思います。このスレッドの構文の問題のいくつかは、高階コンポーネント（コンポーネントクラスを構築する関数）やレンダリング小道具（関数を引数として取るコンポーネント、関数は要素を返す）などの新しい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に対する最良の議論は、ダートが議論に名前を付けたということでした。
要素に複数の子があるのか、1つの子があるのかを知ることが重要なのはなぜですか？たぶん、「フラグメント」構造はそのAPIを明確にすることができます。

alexkrolick 2018年02月12日

AngularやReactなどの経験を持つFlutterの初心者として、通常のDartの方法、およびDart2.0の多くの方法がこのDSXよりも優れていると私は今でも思っています。これは、一部のXMLやCSS風のパラメーターよりも理にかなっています。 🤷‍♂️

tenhobi 2018年02月12日

👍3 🎉1

@cbazza 2番目のデモ例では、ダーツの391（両方ともスペースなし）と比較して466文字です。私にはそれは視覚的に肥大しているように見えます。私はそれのセマンティクスを学ぶ必要がありますが、通常のDartコードでは学ぶ必要はありません。そして、汎用プログラミングパラダイムをどのように使用するか（if、forEachなど）がわかりません。

選択肢があれば、現在のモデルを使い続けます。

b-strauss 2018年02月12日

👍3

誰もが両方の構文を比較することについて独自の主観的な意見を述べているだけですが、1つの事実に同意する必要があります。それは非常に物議を醸す機能です。愛と憎しみがありますが、ほとんどの意見は、プレーンダートに対するJSXの有用性について意見が分かれています。

いずれにせよ、1.0リリースの前にこの機能をサポートすることをFlutterチームに依頼するのはまったく不合理だと思います。 UIを構築する現在の方法は、すべての人にとって素晴らしいとは思えないかもしれませんが、それは機能します（そして、いくつかの意見ではうまく機能します）。

人々が今JSXのような構文を本当に望んでいるのなら、コミュニティ主導の努力が進むべき道のように思えます。そして、Flutterチームが1.0以降のリリースでそれを検討するとき、それはケースを作るのに役立ちます（またはそうではありません）。

個人的には、次の議論に強く同意します。JSXがReact（マークアップ言語を使用してUIを既に構築している）で機能するためではなく、Flutterで自動的に機能します。

lukaspili 2018年02月12日

👍8 🎉1

@tehfailsafe

素晴らしいニュースは、これがFlutterチーム（このスレッドに基づいている可能性は低い）によって採用されたとしても、誰もそれを使用することを強制されないということです。それはオプションです。なぜそれがとても感情的にチャージされているのか理解できないので、一部の人々はあなたが好きではない構文でコードを書くのを好むかもしれません...

私は他の人が好きか嫌いかは気にしません。しかし、私は自分のアプリケーションを進めるのに役立つ機能に関心があります。リソースは限られており、適切なビデオ/ストリームプレーヤー、ネイティブの子ビュー、およびいくつかのベクターグラフィック形式が必要です。

たとえば、現在ReactとReact Nativeでは、JSXなしでアプリケーション全体を作成できます。これは単なるオプションです。 JSXなしのReactは次のようになります。
[...]
JSXバージョンよりもかなり面倒で、ほとんど誰も使用していません。おそらくそれが、Reactから来ている私たちの何人かが、このスタイルを再び行う必要を回避する可能性を高く評価する理由です。

これは、Webがそのようなシステム用に設計されていないためです。 HTMLのような静的マークアップ言語があり、それを「ダイナマイズ」したい場合は、その上で動作する必要のあるシステムを発明する必要があります。最終的には、基盤となるプラットフォームによって制約される構造になります。
（https://gbracha.blogspot.de/2014/09/a-domain-of-shadows.htmlを参照）

一方、Flutterにはマークアップ言語がありません。あまりダイナミックで表現力のないものにリソースを投資する理由はまだわかりません。

b-strauss 2018年02月12日

👍6

それに同意しない人がJSXの有無にかかわらずReactを使用したかどうか知りたいです。皆さんに試してみることをお勧めします。そのため、この議論は理論的ではありません。最初の浅い学習曲線の後、それは非常に自然になります（そして、終了タグを使用すると読みやすくなるため、文字数だけではありません）。長期的には生産性を向上させるFlutterのような、新しいことを学ぶことと何ら変わりはありません。そして、私はそれがすべての人のためではないことに同意します、それがそれがオプションである理由です。
私たちはお互いの最善の利益を念頭に置いていることを覚えておくことが重要だと思います-ものを作りやすくすることです。このトランスパイラーは役立つと思いますし、公式のサポートがあれば採用しやすくなります。

また、ありがとう@cbazza :)

yuriy-manifold 2018年02月12日

@ yuriy-多様体

ここで、JSXReactが従来のReactよりも優れていることを疑う人はいないと思います。しかし、私が言ったように、そのソリューションは、基盤となるプラットフォームのプロパティに関連する問題のために作成されました。 Flutterにはこれらのプロパティはありません。

問題は「JSXはReactに役立ちますか？」ではありません。問題は、「JSXのようなものはFlutterに役立ちますか？」です。

答えはノーだと思います。

b-strauss 2018年02月12日

👍10

考慮すべき他のいくつかのことがあります：

レイアウト仕様をアプリコードから分離することで、コードをより将来にわたって利用できるようになります。たとえば、このDart 2構文の提案は、アップグレード可能なプラグマに従ってJSXのような不可知論的な形式からDartコードに変換された場合、 buildメソッドに影響を与えません。
レイアウトをマークアップとして定義すると、レンダリングエンジンを（ステートフル/仮想化）ウィジェットエンジンから分離することが可能になり、ReactとReactDOMおよびReact Nativeとの関係により、ウィジェットを新しいプラットフォームに移植しやすくなる可能性があります。
マークアップ形式を定義すると、Sketchやその他のデザインツールなどから既存のレイアウトをFlutterに簡単に移植できます。

alexkrolick 2018年02月12日

トランスパイラーcbazzaとの素晴らしい仕事

@ Rockvole 、ありがとう。

コミュニティやそのようにUIを構築したい人々のためにあなたの仕事に感謝しますが、Flutterでそのようなものを使用することを強制されないことを本当に望んでいます：-（（（

@zoechi 、ありがとう。はい、それはJSXを愛する人々が使用するための単なる別のオプションです。それがあなたのクールなことではない場合は、あなたがしているように続けてください、そこでは何も変わりません。

Flutterパターンをサポートするために新しいJSX構文を発明する必要はないと思います。

@alexkrolick 、はい、名前付きパラメーターにレンダリングプロップを使用できますが、位置パラメーターについては何もできません。重要なのは、トランスパイラーに何もハードコーディングして、すべてで機能するようにしたくないということでした。

AngularやReactなどの経験を持つFlutterの初心者として、通常のDartの方法、およびDart2.0の多くの方法がこのDSXよりも優れていると私は今でも思っています。これは、一部のXMLやCSS風のパラメーターよりも理にかなっています。

@tenhobi 、それなら素晴らしい使い方ですが、DSXはすべての人に適しているわけではありません。

選択肢があれば、現在のモデルを使い続けます。

@ b-strauss、これは代替品ではなく、JSXが好きな人のためのオプションです。

愛と憎しみがありますが、ほとんどの意見は、プレーンダートに対するJSXの有用性について意見が分かれています。

@ lukaspili 、DSXはJSXを愛するReact Nativeの人々のためのものです。その利点がわからない場合は、使用しないでください。 DSXとプレーンダートではありません。それはDSX対JSXであり、2が近いほど良いです。

素晴らしいニュースは、これがFlutterチーム（このスレッドに基づいている可能性は低い）によって採用されたとしても、誰もそれを使用することを強制されないということです。それはオプションです。なぜそれがとても感情的にチャージされているのか理解できないので、一部の人々はあなたが好きではない構文でコードを書くのを好むかもしれません...

@tehfailsafe 、聞いてくれてありがとう!!! React Nativeの人々を本当に幸せにする何かへのそのような巨大な抵抗がなぜ頭に釘を打ったのか、あなたは頭に釘を打ちました。

私は他の人が好きか嫌いかは気にしません。しかし、私は自分のアプリケーションを進めるのに役立つ機能に関心があります。リソースは限られており、適切なビデオ/ストリームプレーヤー、ネイティブの子ビュー、およびいくつかのベクターグラフィック形式が必要です。

@ b-strauss、React NativeファンがFlutterに移動すると、これらの他の必要なことを手伝ってくれるたくさんの人々がいるでしょう。優先度1は、React Nativeからマインドシェアを盗み、ReactNativeの人々が移動できるようにすることです。

一方、Flutterにはマークアップ言語がありません。あまりダイナミックで表現力のないものにリソースを投資する理由はまだわかりません。

@ b-strauss、DSXはプレーンダートよりも「ダイナミック性が低く」「表現力が低い」のはどうですか？ DSXはダートです。トランスパイラーを試してみませんでした。

@ yuriy-多様体、ありがとう。

問題は「JSXはReactに役立ちますか？」ではありません。問題は、「JSXのようなものはFlutterに役立ちますか？」です。

@ b-strauss、もちろんそうです。現在のFlutter開発者には役立ちませんが、ツールからCSSを出力できる設計者には非常に役立ち、ReactNativeプラットフォームに精通している人々には非常に役立ちます。

@alexkrolick 、非常に良い観察。

cbazza 2018年02月13日

@cbazza

これは代替品ではなく、JSXが好きな人のためのオプションです。

わかりました...そのような影響はありませんが、前に述べたように、フラッターアプリを作成する必要があるため、現在不足している機能があります。

React NativeファンがFlutterに移動すると、これらの他の必要なことを手伝ってくれるたくさんの人々がいるでしょう。優先度1は、React Nativeからマインドシェアを盗み、ReactNativeの人々が移動できるようにすることです。

それで、フラッターチームは疑わしいもののために機能を保留にし、Web開発者の特定のサブセットの一部を引き付けるかもしれないし引き付けないかもしれないと提案しますか？

DSXは、プレーンなダートよりも「ダイナミック性が低く」「表現力が低い」のでしょうか。 DSXはダートです。トランスパイラーを試してみませんでした。

すべてのDSLは、定義上、GPLよりも表現力が劣ります。 DSXを使用して、ウィジェットを条件付きで非表示にするにはどうすればよいですか？コレクションを反復処理して、すべての要素をウィジェットにマップするにはどうすればよいですか？スイッチの使い方は？ここで、GPLにすでにある構成の構文とセマンティクスを作成する必要があります。では、なぜそもそもDSLを発明するのでしょうか。

もちろんそうです。現在のFlutter開発者には役立ちませんが、ツールからCSSを出力できる設計者には非常に役立ち、ReactNativeプラットフォームに精通している人々には非常に役立ちます。

それは問題ではありませんでした... DSLが現在解決できない問題は何ですか？あなたはそれがより良いと言い続けます、なぜそれはより良いのですか？ DSXがJSXの人々を引き付けることは間違いありません。私は人々が違うものが好きではないことを知っています。そして、親しみやすさが唯一の議論のようです。では、CSSを使用してみませんか？
JavaScriptを使ってみませんか？ダートよりも多くの人がこれらの使い方を知っています。

慣れることを唯一の目的として他のことに基づいてシステムを設計する場合、実際には革新的ではありません。

b-strauss 2018年02月13日

@ b-明確にするために、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でも知っている限り、スイッチは式ではないため、インラインで使用することはできません。ウィジェットツリーの外にいる場合は、通常どおりスイッチを使用できます。

alexkrolick 2018年02月13日

それで、フラッターチームは疑わしいもののために機能を保留にし、Web開発者の特定のサブセットの一部を引き付けるかもしれないし引き付けないかもしれないと提案しますか？

@ b-strauss、React NativeはWeb開発ではなく、Flutterの主な競争相手であるクロスプラットフォームのモバイル開発です。はい、JSXは光源のようなもので、多くのReactNative開発者を引き付けます。私は2017年8月にこの機能を要求しましたが、話が多すぎてアクションが少なすぎました。

すべてのDSLは、定義上、GPLよりも表現力が劣ります。 DSXを使用して、ウィジェットを条件付きで非表示にするにはどうすればよいですか？コレクションを反復処理して、すべての要素をウィジェットにマップするにはどうすればよいですか？スイッチの使い方は？ここで、GPLにすでにある構成の構文とセマンティクスを作成する必要があります。では、なぜそもそもDSLを発明するのでしょうか。

あなたは完全に間違っています。良いニュースは、私もかつて間違っていたことです。ほとんどの（すべてではありませんが）DSLはマークアップでプログラミング構造を再作成しようとします（そしてそれはそれほど強力ではありません）、JSXはマークアップをプログラミングにもたらします（ホスト言語を最大限に活用します）。違いは変革的です。あなたのすべての質問への答えは、それがダートであるため、基本的にダートでそれを行う方法を使用することです。 '{}'の間にあるものはすべて、spread演算子を除いてDartコードです。すべてダーツ式ですが、式を返す無名関数を使用することもできます。トランスパイラーにあるように、タグ（\）はウィジェットの新機能です（newText（））。

DSLは、現在解決できない問題をどのように解決しますか？

ゼロと1を使用できるのに、なぜDartを使用するのですか？コンピューティングの問題を解決するために必要なのはそれだけではありませんか？

あなたはそれがより良いと言い続けます、なぜそれはより良いのですか？

私は前に私の理由を述べました、そしてここでそれらを繰り返すことはしません。 JSXの人々は私に同意しますが、「それぞれに」同意します。

DSXがJSXの人々を引き付けることは間違いありません。私は人々が違うものが好きではないことを知っています。そして、親しみやすさが唯一の議論のようです。では、CSSを使用してみませんか？
JavaScriptを使ってみませんか？ダートよりも多くの人がこれらの使い方を知っています。

はい、CSSを使用すると、設計者と開発者のワークフローが容易になります。 DSXはそれをサポートしています。 Javascriptに対するDartの利点は、実行速度（パフォーマンス）です。

慣れることを唯一の目的として他の何かに基づいてシステムを設計する場合、実際には革新的ではありません。

あなたは間違った偏見に満ちているので、おそらくあなたはあなたの潜在能力を最大限に発揮することができません。心を開いて、さまざまなことを試してください。

cbazza 2018年02月13日

@alexkrolick 、詳細ありがとうございます。

cbazza 2018年02月13日

@cbazza

あなたは間違った偏見に満ちているので、おそらくあなたはあなたの潜在能力を最大限に発揮することができません。心を開いて、さまざまなことを試してください。

今すぐこの号の購読を解除します。ここやどこかで私に言及しないでください、thx。

b-strauss 2018年02月13日

👎1

@ b-strauss

申し訳ありませんが、私はあなたの気持ちを傷つけるつもりはありませんでした...私は自分の欲求不満を管理しようとしている間あなたを優しく案内しようとしていました。結局のところ、私たちはすべて人間です。

cbazza 2018年02月13日

@cbazzaメールを送っていただけませんか。 [email protected]

Hixie 2018年02月13日

すでに古いスレッドでこの提案をしましたが、それでも重要なポイントだと思います

new/constを使用する必要をなくしたIMHOは、すでに多くのことを助けました。ダーツフォーマットでツリーをフォーマットする方法に本当に問題があります。以下と比較して、IMHOのツリー構造を十分に強調していません。

    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,
                    ),
          ),

escamoteur 2018年04月25日

👍1

JSXのような構文を使用したくないフラッターをシンプルにする目的に同意し、複数のウィジェットに分割するという概念もサポートしますが、MVCの時代がjqueryに戻ったように感じさせます。後でパディング、境界線、中央のレイアウトを備えた単純なウィジェットがあったようなシナリオでは、多くの「}」記号が読みやすさに深刻な影響を及ぼします。ただし、これは不可欠なウィジェットであり、分割したくないので、便利です。解決？私の英語は下手ですが、自分の考えを表現するように一生懸命頑張っています。

woodstream 2018年04月26日

主は私たちすべてを助けてくださいます。

わかりました、これはどこにも行きません。誰もがすぐにサイドを切り替えようとしているようには見えません。ここでは間違いなく何らかの妥協点に到達する必要があります。もちろん、「pro-DSX」と「anti-DSX」には、リモートで満足のいく妥協点はありません。これは苛立たしい認識です。位置をより互換性のあるものにするために、位置を再構成することはできますか？

ghost 2018年04月26日

@naiveaiguy 「彼ら」はDSXを持つことができます。
Flutterチームがそれを実装しない場合、それはオープンソースイニシアチブである可能性があります。
これは、現在のような純粋なダートアプローチが機能しなくなるという意味ではありません。
両方の世界が共存できます。

zoechi 2018年04月26日

👍9

@zoechiにとても同意しているので、彼らは共存できます...それで、これは古いスレッドで解決されたと思いました

MichaelSowah 2018年04月26日

@lrhn

皆さん、礼儀正しく建設的になってください。ここでは非常に主観的なスタイルについて話し合っているので、誰もが自分の好みをどれほど気に入っても、本質的に他の人より優れているとは考えられません。既存の構文と提案された構文で見られる長所と短所をリストしてください。ただし、すべての人が同じように見ているわけではないことを忘れないでください。それはまったく問題ありません。

ブラボー、それは絶対にそれです。

Reactでは4つの方法でそれを行うことができます（そして私は今日他の2つの方法について知りました!!!）

（1）JSXを使用できます（私が好きなものです）
https://reactjs.org/docs/introducing-jsx.html

（2）元の方法を使用できます（Flutterに似ています）
https://reactjs.org/docs/react-without-jsx.html

上記のリンクの最後に、2つの有望なコミュニティプロジェクトについても言及しています

（3）React.jsマークアップのハイパースクリプト構文
https://github.com/mlmorg/react-hyperscript

（4）ハイパースクリプトの簡潔な構文。
https://github.com/ohanhi/hyperscript-helpers

選択肢があるのは良いことです、それが黒である限りあなたが好きな色でフォードを手に入れることができた時代は終わりました:)

cbazza 2018年04月26日

@naiveaiguy現在のアプローチとDSXがある場合、なぜそれがあなたにとって問題になるのですか？
（それは私があなたの反対票から導き出したものです）

zoechi 2018年04月26日

@naiveaiguy 「彼ら」はDSXを持つことができます。
Flutterチームがそれを実装しない場合、それはオープンソースイニシアチブである可能性があります。
これは、現在のような純粋なダートアプローチが機能しなくなるという意味ではありません。
両方の世界が共存できます。

私はこれに完全に同意します。すぐに使えるソリューションではなく、プラグイン可能なソリューションである必要があると思いますが。動作する標準が1つあるが、追加の機能でエクスペリエンスをカスタマイズできることは、優れたパラダイムです。そうすることで、Flutterチームは（私が信じている）より関連性の高い問題に焦点を合わせ続けることができ、コミュニティはさまざまなツール/ソリューションを試すことができ、DSXまたは現在の代替案に関するより多くのデータと経験について話し合うことができますメタ。

選択肢を持つことは良いことです、あなたがあなたがどんな色でもフォードを手に入れることができた時代は終わりました
それが黒である限り好きだった:)

確かに。ただし、Dart / Flutterを別のJS / Webフロントエンドエコシステムにしたくないということには誰もが同意できると思います。 Flutterはまだベータ版であり、主観的なものに対して2つの基準を設定する必要があります。

Reactでは4つの方法でそれを行うことができます（そして私は今日他の2つの方法について知りました!!!）

Reactはそれらを参照していますが、ほとんどはコミュニティ主導です。中途半端です。現在、公式にサポートされているのは2つだけですReact.createElementとJSXウェイで、もう一方のラッパーです。 JSXの価値はその文脈で悪名高いですが、ここではそれほど明確ではありません。これを念頭に置いて、1つの公式標準と、関連する場合はいつでもDSXを参照するドキュメントを用意することで途中で満たすことができますか？

Flutterチームは、開発者がアプリを構築することを本当に妨げる機能の欠如に焦点を当てるべきだと思います。マップのサポートを追加することさえできず、カメラ機能の開発に2週間かかる場合、マネージャーにFlutterを推奨することはできません。

覚えておいてください、私はDSXのドアを永遠に閉じているわけではありません。たぶんそれはUI構築のソリューションになるでしょうが、その決定を下すにはコミュニティがそれを実験する必要があります。

emalamela 2018年04月27日

👍6

@zoechi個人的には、Flutterの現在の状態で、2つのアイデアが共存できるとは思いません。この性質の分割をこれほど早く奨励するべきではありませんが、現時点では、唯一の妥協点のようです。

ghost 2018年04月27日

@naiveaiguy

個人的には、Flutterの現在の状態で2つのアイデアが共存できるとは思いません。この性質の分割をこの早い段階で奨励するべきではありません。

なぜ共存できないのか、具体的に教えてください。（DSXが単なる糖衣構文であるという事実、または@emalamelaが「現在の方法の単なるラッパー」と言っているように）。

また、まったく同じものに異なる構文を提供するのが早すぎるのはなぜですか？私は基本的に、なぜこれを遅らせる必要があるのか、現在まだ存在しない将来は何が違うのかを尋ねています。

@emalamela

ただし、Dart / Flutterを別のJS / Webフロントエンドエコシステムにしたくないということには誰もが同意できると思います。

個人的には、Dart / Flutterでできることを制限することはしません。市場/コミュニティに決めさせてください。基本的に、作成されたものが付加価値をもたらさない場合、人々はそれを使用せず、それは死にます。それが人気になった場合、それはコミュニティがそれを有用であると感じ、それを評価したからです。今すぐ勝者と敗者を選ぶ必要はありません。

cbazza 2018年04月29日

👍5

私がFlutterを試してみるのを妨げているのは、彼らがJSXを使用しないことを選択したという事実だけです。
IMHO JSXは、コンポーネント階層を表現するための最良の選択です

edaloicaro18 2018年05月01日

👍13 👎6 ❤3 🎉2

Flutterについて聞いたので、試してみたかったのですが、構文を見た瞬間にそれを考えてもすぐに停止しました。これは残念なことです。これは素晴らしい技術である可能性が高いからです。製品を構築します。

私は過去2。5年間、React / React Native開発を行ってきました。UIの記述に関して、JSX構文が提供する生産性を犠牲にして、多くの質問があります。 Flutterについてすべてを学び、そのような機能がすぐにサポートされるときに切り替える価値があるかどうかを調べるために時間を費やすことを真剣に検討したいと思います。

このためにFlutterが失っている潜在的な採用者/ユーザー/開発者の数を想像することすらできませんが、今後数か月以内に再訪する予定です。

sonaye 2018年05月09日

👍3

このためにFlutterが失っている潜在的な採用者/ユーザー/開発者の数を想像することすらできませんが、今後数か月以内に再訪する予定です。

ええ、44 ~~Mio~~は、賛成するのに十分重要だと感じました：D

zoechi 2018年05月09日

😄1

ええ、44歳は賛成するのに十分重要だと感じました：D

'upvote'でソートすると、この機能リクエストは3131のオープンチケットのリストの7番目にリストされます。

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

cbazza 2018年05月09日

👍3

@cbazzaこの機能に異議を唱えたくはありませんが、「xを実行しないと、恐ろしくyが発生する」などのコメントはばかげています。

zoechi 2018年05月09日

👍5

私は過去2。5年間、React / React Native開発を行ってきました。UIの記述に関して、JSX構文が提供する生産性を犠牲にして、多くの質問があります。 Flutterについてすべてを学び、そのような機能がすぐにサポートされるときに切り替える価値があるかどうかを調べるために時間を費やすことを真剣に検討したいと思います。

@sonaye

生産性についてお話しましたが、JSXの代わりにFlutterのパターンを使用した場合の生産性の低下を明確に示す例を挙げていただけますか？この例は、上記の例をコーディングできるように十分なJSとDartを知っていることに基づいて作成する必要があります。それを考慮に入れなければ、プログラミング言語も比較していると思いますが、これは同じ議論ではありません。

'upvote'でソートすると、この機能リクエストは3131のオープンチケットのリストの7番目にリストされます。

@cbazza

それはまた最も反対されたものです。それはかなり物議を醸しています。

emalamela 2018年05月09日

😄1 👍1

@emalamela 、

それはまた最も反対されたものです。それはかなり物議を醸しています。

この機能要求は現在の方法に代わるものであり、現在の方法を変更しないため、論争はまったくないはずです。 JSX / DSXが気に入らない場合は、今日と同じようにプログラミングを続けてください。

いわゆる論争が存在するのは、FlutterチームがコミュニティがDSXを適切に実行できるようにするための作業を行う必要があるためです。 Flutterツール（コンパイラー、アナライザー、IDEサポートなど）がソースマップを使用した前処理をサポートしている場合、DSXはずっと前に行われ、サードパーティの開発者による他の言語の革新/アイデアも行われた可能性があります。

cbazza 2018年05月09日

👍1

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のUIの構造についてすぐに明確なアイデアを得ることができます（数秒かかります）。メンタルモーダルは非常に視覚的です。第二に、使いやすさ。 JS / Dartや基盤となるAPIについて何も知らなくても、JSXを使用できると私は主張します。これは、プログラミングを学んでいる人や、私のチームの一員である人に非常に適しています。デザイナーはUIをコーディングできるようになりました。

アプリケーションの説明は完全に宣言的です（表現力だけでなく）。何百ものコンポーネントを含む大規模なプロジェクトで作業する場合、UIを説明するこの方法は、大きな違いを生みます（実際に評価するには試してみる必要があります）。 JSXを最初に見たときも好きではありませんでした。一度使用すると、ちょうどいい感じになりました。これからUIを説明したいのですが、これは、インターフェイスの構築に取り組む方法における明らかなブレークスルーでした。

それは、コードの行数を減らすことではなく、「構文糖衣構文」を使用することでもありません。人間のためのツールを構築することでもあります。私はまた、誰もがJSXを使うべきだという議論に反対しています。これはばかげています。混乱を少なくして作業を高速化できるツールを使用します。多くの場合（私を含む）、JSX（またはFlutterの場合はDSX）だけです。

sonaye 2018年05月10日

❤8 👍7

私はReactから来て、初めてFlutterを試しています。フラッターチームがJSX構文を持っていないのは本当に奇妙です、私は真剣に意味します！ JSの世界では、JSXはすべてのReact-alternativesで非常に普及しています。 JSXは開発者にとって非常にフレンドリーです。コミュニティの成長を支援できるように、このできるだけ早く実装してください。

rajaraodv 2018年05月11日

👎4 👍3

この号のコメントの量を探すだけで、JSX（この場合はDSX）が重要であることがわかります。

JSXは、試してみるまで自分が好きだとは知らないものです。コードにマークアップを含めるのは最初は奇妙ですが、その後は素晴らしいものになります。

すでにフラッター/ダーツを知っている人には不要のようです、私はそれを理解しています。しかし、ダーツに触れたことがない人（私のように）にとって、JSXは最初からずっと簡単であり、それがポイントです。より多くの人が来て、もっとたくさんの素晴らしいものを作り始めたいのなら、ツールはもっと簡単である必要があります。

そして、 @ eseidelGoogle （https://youtu.be/h7HOt3Jb1Ts?t=2m41s）が他の人に言ったように、「Flutterは単一のコードベースでiOSとAndroidに書き込む方法です。私たちはそれを速くて簡単にするようにしています[。 ..]フラッターはハードウェアに至るまで話し合います[...]私たちは非常に階層化されたアプローチを採用しているため、必要なだけ、または多くのことを行うことができます。[...]ツールへの投資はたくさんあります。」

JSXを実装してください。

flasd 2018年05月11日

👍3

私はダーツのファンであり、reactのヘビーユーザーでもあります。私はいつもDartterserを見つけ、JSXよりも保守しやすいと思っています。したがって、JSX / DSXは、コミュニティの方法で実装できる可能性があり、おそらく実装する必要があると思います。

jarontai 2018年05月11日

👍4

@rajaraodv Flutterがリアクティブスタイルフレームワークとして宣伝されているからといって、それが単なるReactJSのフレーバーであるとは限りません。
ほとんどのコメントから、人々は新しい何かが彼らがすでに知っているものと同じではないことを受け入れるのに苦労しているという印象を受けます。

Flutterを現在の状態でしばらく使用してから、「個人的な好みのため」や「より良いため」ではなく、 JSX / DSXがプレーンなDartよりも優れていると考える理由を適切に説明することができます。。

zoechi 2018年05月11日

👍7 👎1

@zoechi 、あなたは何かが欠けています：Flutterのドキュメントによると、FlutterはReactからインスピレーションを得ています。
多分それは私の問題だけです。 Dart 2の構文であっても、UIコードを読むのに苦労していると実感しています。

JonathanSum 2018年05月11日

👍3

フラッターはReactNativeからインスピレーションを得た

「言語がJSではなくFlutterと呼ばれることを除いて、すべてが同じである」とはどういう意味かわかりません。

UIコードを読むのに苦労していると実感しています

そして、あなたはそれに対する唯一の想像できる解決策はDSXであると主張しますか？

Flutterは1.0でさえなく、IDEサポートは時間の経過とともに向上する可能性があると考えましたか？

クイックフィックス（ "wrap xxx"）やラベルのクローズなど、コードエディターでFlutter IDEのサポートを改善するために、最近行われた最初の小さな手順のみがありました。

開発者のエクスペリエンスを向上させる可能性は無限にあり、このディスカッションのほとんどは次のようなものです。
「Flutterはまだ完璧ではないため、DSXが必要です」
通常、DSXがそれを解決または改善する方法または理由についての具体的な議論はありません。

zoechi 2018年05月11日

👍4

@zoechi 、

Flutterを現在の状態でしばらく使用してから、「個人的な好みのため」や「より良いため」ではなく、JSX / DSXがプレーンなDartよりも優れていると考える理由を適切に説明することができます。。

繰り返しになりますが、Plain DartまたはDSXは単にスタイルの問題であり、どちらが優れているかを主張する意味はありません。それは個人的な好みであり、人々はどちらかを選ぶ理由があります。

React Worldで起こったことは、JSXを使用すると、元に戻らないということです。他の人が上で述べたように、あなたはしばらく使用した後にJSXに夢中になります。 JSXはReact'sWorld（Typescript、Vue）以外の人にも採用されており、Flutterに最適です。

そして、あなたはそれに対する唯一の想像できる解決策はDSXであると主張しますか？

コミュニティが必要としているのは、Dartツール（コンパイラ、アナライザ、IDEなど）に組み込まれたソースマップサポートを備えた一般的な前処理機能です。これにより、DSXまたはそれ以上のものをコミュニティで開発し、Flutter（デバッガ、オートコンプリート）に完全に統合できます。完了など）。

開発者のエクスペリエンスを向上させる可能性は無限にあり、このディスカッションのほとんどは次のようなものです。
「Flutterはまだ完璧ではないため、DSXが必要です」
通常、DSXがそれを解決または改善する方法または理由についての具体的な議論はありません。

確かに、このチケットは一般的な「開発者エクスペリエンスの向上」に関するものではありません。これは非常に具体的であり、FlutterでJSXサポートを取得することについてです。コミュニティは、単純なダートウェイの代替としてDSXを望んでいます。

cbazza 2018年05月11日

私はこれを使っている自分を見ることができません（しかし、私はそれを試してみるつもりです）。これが特効薬だとは思いませんが、熱意が非常に高いので、やりがいがあります。

コミュニティが彼らが望むものを構築できるようにするために、グーグルは言語の障害を取り除くべきだと思います。

Rockvole 2018年05月11日

👍2

GoogleのFlutter / Dartチームの外部の誰かがDart / Flutter用にJSXのようなものを書くことを妨げる障害を私は知りません。誰かが試みているなら、私はそれらのバグを見たいです。（この非常に長いバグのすべての単語を読んでいないことを認めているので、上記のコメントでそれらを見逃している可能性もあります。）:)

ありがとう！そのような熱意を見てうれしいです！

eseidelGoogle 2018年05月11日

👍1

@eseidelGoogle 、

Intellijおよび/またはVSCode（Dart-Codeを使用）は、どのようにしてブレークポイントを設定し、.dsxファイルからコードをステップスルーできますか？（つまり、これは.dartファイルではありません）。 .dsxファイルからのオートコンプリート機能はどうですか（.dartファイルの場合と同様）？

あなたはツールに多くの投資をしましたが、ツールはDart / Flutterにシームレスに移行する新しい言語（DSXなど）の前処理（ソースマップを使用）をサポートしていません。

トランスパイラーは利用可能ですが、それを完全に統合する簡単な方法はありません。
https://spark-heroku-dsx.herokuapp.com/index.html

PSこのチケットはコメントの半分にすぎません!!!
https://github.com/flutter/flutter/issues/15922

cbazza 2018年05月11日

👍1

@cbazzaそのコンパイラのリポジトリはどこかにありますか？たとえそれが完璧でなくても、コードを共有し、コミュニティをハッキングに参加させるのは素晴らしいことです。

jonahwilliams 2018年05月11日

@ jonahwilliams 、DSXトランスパイラーコードはリリースされていません。それは時期尚早だからです。
2つの手書きの同等のファイル（.dsxと.dart）を使用するだけで、ブレークポイント、ステッピング、オートコンプリートなどの前処理機能をテストできます。

ツールが何らかのソースマップを使用した前処理をサポートしたら、それをトランスパイラーに追加してブロックを解除できます。これはまた、他の人が彼らの心の欲望を実験することを可能にするでしょう。

cbazza 2018年05月11日

私はFlutterに取り組んでいませんが、他の人に利益をもたらすために特定のツールを要求するのは不合理なようですが、ツールを統合したい初期のソースコードや例をリリースすることも拒否します。

価値のあることとして、私はあらゆる種類の前処理フックを提供する言語やツールキットを知りません-おそらくそれは単純ではなく単純であるため、言語と構文の周りには多くのコーナーケースと仮定があります。

ソースマップ（https://pub.dartlang.org/packages/source_maps）を生成した場合、IDEで少なくともいくつかの基本的なサポートを取得することは、Dart / Flutterとは関係なく、非常に簡単だと思います。しかし、繰り返しになりますが、これは、ツールが何を実行し、どのように機能するかを知らなくても、すべて推測です。

matanlurey 2018年05月11日

👍3

@matanlureyは、ソースマップを介した前処理をサポートする、特定のトランスパイラーに依存しない一般的なメカニズムです。これは、将来考えられる言語をサポートすることを目的とした機能です。 Chromeブラウザ/デバッガはそれを非常にうまくサポートしており、JSに変換される任意の言語をデバッグできます。

テストのために、ソースマップの使用方法を示すための簡単な種類のトランスパイラーを思い付くことができます。たとえば、元のファイルのすべての行の間に空白行があるDart / Flutterコードを生成する簡単なトランスパイラーを記述します。（.d2 => .dart、.d2はDart / Flutterファイル、out .dartファイルには元のファイルのすべての行の間に空白行が含まれます）。

はい、テストファイルのソースマップの生成に取り組むことができます。

cbazza 2018年05月12日

👍1

Flutterは現在、NativeScript、ReactNative、Android、Web、および同様のXMLレイアウトに慣れている他の開発者を喜ばせようとすることに消極的です。彼らにはもっと重要なことがあるので、解散して眠りましょう。

woodstream 2018年05月12日

👍6 😕1

私は、JSX構文のエイミーの支持者が嘆き続ける前にFlutterで実際に作業するのに数日を費やすことを望みました。私はXamlベースのシステムから来ましたが、すぐにそれに慣れました。実際に試してみてください。

escamoteur 2018年05月12日

👍3

@escamoteur
ねえ、escamoteur。私はフラッターを学ぶのに多くの時間を費やしていないと思いますか？
flutter.io/tutorials/layout/の「ウィジェットのパッキング」セクションの最後で、チュートリアルで提供されたコードが機能しません。
フラッター問題ブロックでこの問題について言及しましたが、誰もこれを気にかけたくありません。

Dartコード：main.dart
https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/main.dart
Pubspec：pubspec.yaml
https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/pubspec.yaml
https://flutter.io/tutorials/layout/

JonathanSum 2018年05月12日

@JonathanSumあなたのコメントからこの問題のトピックへの関連はありますか？

zoechi 2018年05月12日

@zoechi
escamoteurは、JSX構文の提案者が、嘆き続ける前に、Flutterで実際に作業するのに数日を費やすことを望んでいると述べました。
このコメントは、私たちが本当に多くの日をFlutterで作業してきたことを示しており、JSXのリクエストは本当に私たちの心からの気持ちです。

JonathanSum 2018年05月12日

👍2

Group Dart： 「Dartの構文ははるかに優れており、JSX / DSXはあまり良くありません」
グループJSX / DSX： 「JSX / DSX構文ははるかに優れており、Dartはあまり良くありません」

これを見るのは私だけじゃないの？双方は、彼らの立場に賛成と反対の有効なポイントを作ります。ここで失われているのは、 @ cbazzaが批判されただけでなく、それについても何かをしたということだと思います。 Flutterに利益をもたらすために、Web devs / react / react-nativeとflutterのギャップを埋めようとしています。

そして私の2セント...フルスタック開発者として、私は幅広い言語とアプローチの経験を持っています... JSXはコードを書くための私のお気に入りの方法の1つであり、ダーツに代わる構文があることを願っています。。そして、現在の構文が悪いと言っているのではなく、JSXスタイルを好むというだけです。

jstansbe 2018年05月17日

👍3

グループJSX / DSXからのこの引用に同意しない必要があります

ダーツは良くない

ダートは非常に優れた堅牢な言語であり、誰もその言語を散らかしていません。議論はダートについてではなく、ほとんどのUI開発者が今日すでに使用しているその上にある合成レイヤーであり、Flutterにそのようなものを組み込むことを提案しています。

AndroidにはXMLレイアウトがあります。
iOSにはストーリーボードXIB（XML）があります
GTK +にはPangoなどのXMLがあります。
QtにはQML（YAMLのような）があります
XamarinにはXAMLがあります

これらのフレームワークと言語のほとんどには、ビューをコントローラーロジックから分離するUIマークアップ言語があります。次に、Reactにはさまざまなアプローチ（ここで提案しています）があり、ユーザーの成長と人気の点でRNが現在飛んでいることに同意する必要があると思います。私は間違っているかもしれませんが、主にJSXが原因です。

..。

Flutterチーム/ユーザーからこの種のフィードバックを得る必要があるのは本当にクレイジーな提案ですか？

birkir 2018年05月18日

👍2

@birkirとそれらすべてが多くの問題を引き起こしますFlutterには\ o /がありません
別の言語は必要ありません。
同じ言語でも、Flutterでビューを分離することができます。

zoechi 2018年05月18日

👍6 👎5

@birkirこのスレッドはDartと構文について100％です。

議論はダートについてではなく、ほとんどのUI開発者が今日すでに使用しているその上にある合成レイヤーであり、Flutterにそのようなものを組み込むことを提案しています。

つまり、Dartについてではありません...しかし、FlutterはレイアウトにDart以外のものを使用する必要がありますか？ Dartは十分ではないと言っているようですが、これはDartとは何の関係もないと主張していますか？

現時点では重要ではないと思います。Flutterチームは（JSX / DSXアプローチのリクエストに関して）このフィードバックを確認しており、元のパスを継続したいと考えています。私はそれをよりうまく処理できると思いますが、彼らがソリューションを作成するコミュニティに反対しているようには見えません。

別のクロスプラットフォームオプションがあることを嬉しく思います... Appleは次に何かを提供するのでしょうか？そして多分彼らは私たちの多くがreact / react-nativeについて好きなものを見るでしょう？彼らが何か料理をしているならIDK。

jstansbe 2018年05月18日

Flutterチームは（JSX / DSXアプローチのリクエストに関して）このフィードバックを確認しました。

ここで何をしたいのかわからないため、このバグはまだ開いています。私たちは、人々がそれらをどのように使用しているかを確認するために、実験（cbazzaなど）を熱心に調べています。ある時点で、このようなcodegenツールのビルドシステムにフックを提供することを計画していますが、これは近い将来に行う可能性はありません。長期的には、ここで学んだことを利用して、ダートの言語としての発展に影響を与えたいと考えています。これは、E4X / H4X / JSX / DSXのようなものをDart自体に追加することを意味する場合があります。あるいは、実際には誰もそれを使用しないことを知るので、何もしません。あるいは、誰もが何か違うものを必要としているので、codegenフックとcbazzaのようなカスタムパッケージが答えです。まだわかりません。

Hixie 2018年05月18日

👍9

@ jstansbe -Appleは、クロスプラットフォームはiPhone、iPad、MacOSを意味すると考えています。彼らは、クロスプラットフォームを構築するよりも、壁に囲まれた庭の上に砲塔を追加する可能性が高いです:)

Rockvole 2018年05月18日

😄4

他の方法でウィジェットをインデントしてフォーマットすることが可能である場合よりも、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に似たさまざまなウィジェットに気付くには、左から右に表示するだけで済みます。

要素（ウィジェット）属性には新しいウィジェットよりも多くのインデントがあるため、コードをより明確に理解して確認できるようになります

さまざまなIDEでこの形式の自動インデントを作成できれば素晴らしいと思いますが、今は手作業でこれを行っています。

cocodrino 2018年05月21日

👍4 👎2

ここですべてのコメントを読み、私の友人（ネイティブモバイルアプリ開発者、java / kotlin / objective-c / swiftみんな）と個人的に話し合った後、私の観察：

人々は2つのことを求めています、

__読みやすさと書きやすさの向上__。いくつかの構文ノイズ（括弧、セミコロン、 new 、 child 、 children ）が混在する深いネストは、現在のコーディング方法では煩わしいものです。
__コードとは別のスタイル/デザイン__。視覚的な分離は読み取り（スタイルを命令型コードと一目で区別する）に適しており、実際の分離はツール（IDEとレイアウトエディターなど）に適しています。

また、主に意見の異なる2つのグループがあります。

問題を解決するために別の複雑さを導入することなく、現在の構文を改善します。
この方向ですでにいくつかの改善がありました。たとえば、Dart2.0のオプションのnew 、 const 、および提案されたvirtual "closing tag" comments機能。
問題を解決するために追加のマークアップ言語（JSXのようなまたはXMLのような）を導入します。

現在、どちらが優れているかを簡単に判断することはできません。したがって、コミュニティに最初に実験を行わせ、後で最終決定（受け入れるか拒否するか）を行わせるだけです。

hooluupog 2018年05月21日

👍3

@hooluupog仮想終了タグのコメントは、しばらくの間、IntelliJ、AS、VSCodeですでに機能しています

zoechi 2018年05月21日

👍4

@Hixie

ここで何をしたいのかわからないため、このバグはまだ開いています。私たちは、人々がそれらをどのように使用しているかを確認するために、実験（cbazzaなど）を熱心に調べています。

現在Flutterにシームレスに埋め込むことができないため、人々は私の実験を使用できません。ですから、それは人々が可能性を見ることができるだけである外部/オンライン実験のままです。

ある時点で、このようなcodegenツールのビルドシステムにフックを提供することを計画していますが、これは近い将来に行う可能性はありません。長期的には、ここで学んだことを利用して、ダートの言語としての発展に影響を与えたいと考えています。

前処理をサポートするためにビルドシステムの変更に何らかの動きが見込める時期について、より具体的な時間について教えてください。私たちは月、四半期、6か月、1年、2年、10年、歓喜などを話しているのですか？

これは、E4X / H4X / JSX / DSXのようなものをDart自体に追加することを意味する場合があります。

JSX / DSXにはセマンティクスがなく、エンジンによる実装や言語への組み込みを目的としていないため、JSX仕様の上部の段落を読んで、Dart言語を変更する必要がないことを確認してください。プリプロセッサ（トランスパイラ）での使用を目的としています。 DSXをFlutter＆on Webで使用すると、React-DartをReact.jsとまったく同じように作成できますが、Dart言語を使用できます。

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

あるいは、実際には誰もそれを使用しないことを知るので、何もしません。

そもそも使用できないものを使用して、使用していないので何もする必要がないと結論付けるにはどうすればよいでしょうか。これは、メリッサ・マッカーシーのショーン・スパイサーによるSNLでの「渡航禁止令」についてのなりすましを思い出させます。

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

あるいは、誰もが何か違うものを必要としているので、codegenフックとcbazzaのようなカスタムパッケージが答えです。まだわかりません。

実験を可能にするには、前処理機能が非常に必要です。それがなければ、何も前進せず、新しいことを学ぶことはできません。

cbazza 2018年05月24日

👍8

人々は私の実験を使うことができません

完全に磨かれていなくても、人々が物事を試してみる意欲を過小評価していると思います。たとえば、誰かがflutter runをラップするシェルスクリプトを簡単に記述して、最初に前処理を実行してから、 flutter runを呼び出すことができます。私は自分でホットリロードをラップして同様のことを行うスクリプトを持っています（最初にアナライザーを実行し、それが成功した場合にのみ、ホットリロードシグナルをflutterスクリプトに送信します）。

ビルドシステムの変更に関する動きをいつ期待できるかについて、時間的に具体的に教えてください。

実際にはそうではありませんが（たとえば、 https ：//en.wikipedia.org/wiki/Forward-looking_statementを参照して、そのようなステートメントを作成するのが難しい理由については）、おそらく今後数週間はそうではありません。

Dart言語を変更する必要はありません

確かに、それはかなり可能です。これらの実験に基づいて、「何もしない」から「言語構文に根本的な新機能を追加する」まで、そしてその間のあらゆるものに至るまで、いくつもの結論に達する可能性があると言っているだけです。重要なのは、私たちはまだ決定を下しておらず、これらすべての議論と実験に基づいて何をする必要があるかを学ぶことに非常にオープンです。

Hixie 2018年05月25日

👍4 ❤3

JSXをバックログに追加して、グラディエータースタイルで、他の100万以上の緊急要件と競合させますか？

jules15 2018年06月06日

👎2 👍2

ReactはWeb用に作成されているため、HTMLを作成するためのシンプルなソリューションが必要です。 JSXは、UIを作成するための最良のソリューションであるため、人気が出ませんでしたが、HTMLを作成するための最良のソリューションであるためです。

Flutterにはそのような制約がないため、間違った理由で平凡で冗長なソリューションで解決するべきではありません。

冗長性を減らしたい場合は、Anko（https://github.com/Kotlin/anko/wiki/Anko-Layouts）などからインスピレーションを得たいと思います。そこで、どこにでも新しいローカル変数を定義し、通常のforループを使用して子のリストを動的に作成できます。これにより、コードをわかりやすくすることができます。また、各ネストレベルはすでにラムダ関数であるため、LayoutBuilderは見やすくなります（追加のビルダーラムダを渡す必要はありません）。とにかく、これはインスピレーションのためだけのものであり、Flutterがそれを1：1でコピーするべきではないと思います。

wkornewald 2018年06月08日

👎8 👍6

ReactはWeb用に作成されているため、HTMLを作成するためのシンプルなソリューションが必要です。 JSXは、UIを作成するための最良のソリューションであるため、人気が出ませんでしたが、HTMLを作成するための最良のソリューションであるためです。

React NativeはWeb開発ではなく、HTMLを使用していません。経験豊富なReact開発者に聞いてください（またはこれと他のJSXスレッドを完全に読んでください）。JSXは多くのReact開発者によってUIを作成するための最良の方法と見なされていることがわかります。

そこで、どこにでも新しいローカル変数を定義し、通常のforループを使用して子のリストを動的に作成できます。これにより、コードをわかりやすくすることができます。

このステートメントは、JSXを知らないことを明確に示しています。 JSX（DSXの場合と同様）は、ホスティング言語（Javascript / Dart）のすべてのプログラミング構造（forループなど）を使用します。

このチケットはJSXのような機能にのみ関心があります。他のアプローチ（Ankoなど）については、そこで議論するために独自のチケットを作成してください。

cbazza 2018年06月08日

React NativeはWeb開発ではなく、HTMLを使用していません。経験豊富なReact開発者に聞いてください（またはこれと他のJSXスレッドを完全に読んでください）。JSXは多くのReact開発者によってUIを作成するための最良の方法と見なされていることがわかります。

ReactはReactNativeよりずっと前に登場しました。 JSXの元のデザインは、ネイティブUIではなく、レンダリングHTMLに基づいています。 JSXの優れた点について、説得力のある議論を1つだけ示すことはできませんでした。比較することによって

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>

最新の比較を行っておらず、1行にさらに多くのものを配置しているだけです。あなたはそれを以下と比較しなければなりません：

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

醜い{<{<>} />}と閉じている</...>タグがすべてなくなっていることに注目してください。

このステートメントは、JSXを知らないことを明確に示しています。 JSX（DSXの場合と同様）は、ホスティング言語（Javascript / Dart）のすべてのプログラミング構造（forループなど）を使用します。

いいえ、JSX内でifステートメントまたはforループ（またはswitchまたはその他のステートメント）を使用することはできません。

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にはこの制限がなく、（一部の）UIコードの記述がより自然になります。

JSXの導入に関する議論では、それが実際に最善の解決策であるかどうか、またはより良いものを見つけることができるかどうかを尋ねることは非常に有効であり、必要であると思います。そうしないと、間違ったタスクにリソースを浪費することになります。

wkornewald 2018年06月08日

👍3

ReactはReactNativeよりずっと前に登場しました。 JSXの元のデザインは、ネイティブUIではなく、レンダリングHTMLに基づいています。

JSXの元の設計は、UI作業を行うときに特別に表示されるツリー構造を作成/操作するための使い慣れた方法に関するものです。 Web開発、ネイティブ開発、UI開発などに表示されるコンポーネント階層（https://facebook.github.io/jsx/）を考えてみてください。

JSXの優れた点について、説得力のある議論を1つだけ示すことはできませんでした。

それがポイントです。現在の方法を置き換えることは考えていません。React開発者に馴染みのある別の方法を追加することを目指しています。

Ankoの提案はAndroidKotlin開発者にはおなじみなので、先に進んで、別のチケットで現在のFlutter階層で機能する仕様を提案してください。仕様を確認（またはオンラインバージョンを試して）すると、現在のFlutterウィジェット階層を生成/相互運用できるかどうかを確認できます。

いいえ、JSX内でifステートメントまたはforループ（またはswitchまたはその他のステートメント）を使用することはできません。

これを行うことをお勧めしますが、それは可能です。無名関数を作成して呼び出します。

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ウィジェットに直接マッピングされ、オーバーヘッドを追加しない、使い慣れたものを使用するという選択肢を持つことです。

cbazza 2018年06月08日

ちなみに、私のオンライントランスパイラーで次のことを試してください。
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用であるため、上記のリンクで説明されている独自の機能があります。

cbazza 2018年06月08日

これを見ると、Androidのxmlレイアウトからフラッシュバックが返されます。これを実装するのは良い考えではないと思います。 newとconstを書く必要がなくなったので、見た目も良くなりました。

charafau 2018年06月09日

👍5

@charafau参照している「Androidのxmlレイアウト」の例/ img /リンクを共有できますか？

jstansbe 2018年06月11日

いいえ、@ wkornewald。「JSXはUIを作成するための最良のソリューションであるが、HTMLを作成するための最良のソリューションであるために普及しなかった」場合、なぜReactはモバイルアプリとデスクトップアプリの構築にJSXを使用するのでしょうか。 Githubデスクトップアプリケーション、Walmartクロスプラットフォームモバイルアプリ、Teslaアプリ、SkypeもRNによって構築されています。

Reactの概念はコンポーネントに関するものであるため、ReactはJSXタグにforループを配置しません。上の部分がロジック、下の部分がJSXで、いつもこんな感じです。すべてが多くのコンポーネントに分離され、大きなコンポーネントに接続されます。

実際、JSXに反対しているほとんどの人は、JSXが何らかのHTML、XML、またはそれほど冗長でないソリューションであると推測することしかできません。

JonathanSum 2018年06月12日

👍7

@JonathanSum

JSXに反対しているほとんどの人は、JSXはある種のHTMLであるとしか推測できません。

個人的な好み以外にJSX / DSXを支持する議論がなかったからだと思います。もちろん、すでに上で説明したようにそれは問題ありませんが、JSXがプレーンダートよりも優れていることを示す良い事実の議論のリストがない場合、人々がJSXを理解していないために反対しているとほのめかさないでください。

zoechi 2018年06月12日

👍9

個人的な好み以外にJSX / DSXを支持する議論がなかったからだと思います。

実際には、多くは以前に与えられたものであり、両方のスレッドを完全に読んだだけです。私は前にこれらの2つのことについて言及しました：
（1）「子供」と「子供」のものはもうありません
（2）サードパーティツールによる操作（解析、分析、再生成）が簡単

（2）を使用すると、マークアップを拡張して、ダートだけでは不可能なことを実行できます。たとえば、DSXのスプレッド演算子や、より小さなセットから多くの関数パラメーターを生成します。

他の人はたくさんの良い点を提供しましたが、私はあなたのためにそれを掘り下げていません;）

cbazza 2018年06月12日

（1）前述のように、Dartでもそのようなことを変更/改善することができ、すでに議論がありました。これは、Dart2のリリース前には発生しません。
DSXがあらゆる種類の新機能を許可し、Dartが許可しないと仮定するだけでは、私の意見では実際には公正な議論ではありません。
（2）これはDartでも同様に実行できると確信しています。もちろん、Dart用のパーサーはすでに存在します。

他の人はたくさんの良い点を提供しましたが、私はあなたのためにそれを掘り下げていません;）

私のためにそれらを掘り下げる必要はありませんが、これは頻繁に発生し、あなたが実際に有効な議論を持っていることを他の人に納得させることができるかもしれません。
私は議論に従いましたが、良い事実の議論を思い出せません。それは他の人にとっても同じかもしれません。それらを要約すると、その質問をする次のリンクを投稿できます。

前に説明したように、私は個人的な好みを有効な議論として受け入れることができますが、事実に基づく議論もたくさんあると主張する場合は、それらを指摘してもらうことは有効だと思います。

zoechi 2018年06月12日

👎6 👍3

あなたは「有効な引数」を求め続け、それらが与えられたとき、「将来のダートはこれを持っている」または「これは有効な引数ではない」としてそれらを却下します。

事実、ウィジェットを作成するとき、現在Dart / Flutterにはノイズの多い子がありますが、XML / DSXにはありません。今のところ、DSXを使用してこの子/子のノイズを除去することは非常に有効な議論です。それを有効な議論として受け入れることができますか？（ダートが将来それを持っているとあなたが言うからといって、それは議論を無効にすることはありません）。

また、XMLの解析は、完全なDart言語を解析するよりもはるかに簡単であり、すべての言語にXMLパーサーがありますが、完全で完全なDart言語パーサーを備えているのはDartだけです。これも有効な議論であることがわかりますか？

有効な議論はたくさんありますが、それらはあなたにとって有効ではないので、私はそれについて議論するのをやめました。言われたことに興味があるなら、JSXの2つのスレッドをよく読んでください。私はあなたにDSXを使うように説得することに興味はありません、あなたは普通のダートに満足しています。私は違います。

cbazza 2018年06月12日

👍14 ❤9 😕3

オプションのDSX構文の引数：

1）オンボードしてReactから来るより多くの開発者を引き付ける（ウェブとネイティブ）
2）ReactNativeコンポーネントをFlutterウィジェットに移植するエクスペリエンスの向上
3）ウィジェットの子/子プロパティの一貫性を促進します
4）コードの可読性（意見のある議論）
5）ダーツリンティングとは別にロジックリンティングを表示する
6）UI構築ツールの世界を開く
7）プリプロセッサのエコシステムを開きます

birkir 2018年06月12日

👍28

DSX +1

techsin 2018年06月24日

DSX +1

たくさんの賛否両論を書きたいと思っていましたが、これらのコメントをすべて読んだことで、私はすべてを何度も繰り返すつもりだと感じています。
そんなに素朴で無知になるのをやめましょう。DSXを使用してUIを作成することを強制されるとは誰も言いません。これは単なるオプションです（より良い代替手段です）。
JSを101203103のさまざまな方法で記述できるのには理由があります。

marcus-sa 2018年06月28日

👍2

そうですね、DSXを解析して通常のDart関数呼び出しに変換するアナライザープラグインを作成するオプションが常にあるので、コンパイラーは余分な作業を行う必要がありません。

本当の問題は、アナライザープラグインがコンパイラーのコンテキスト内で適用されるかどうかです。

あなたが私に尋ねるなら、DSXはオプトインである必要があります。理想的にはある種のプラグインを介してです。それを言語自体に追加する必要は非常に少ないと思います。そうすると、Dartのサーバー側とWebユーザーは、Flutterユーザーだけでなく、変更に適応する必要があります。 Dartで記述されたコードの大部分は、リモートでXML構文を必要としないため、すべての人にXML構文を適用することは悪い決断です。

TLDR; DSXをそれほど悪くしたい場合は、アナライザープラグインを作成し、それを自分でDartに持ってきてください。インターネットはあなたを愛し、何千ものGithubスターを獲得し、Reactのように感じるでしょう。ウィンウィン。

PS私はそれをするためにあなたと競争するでしょう

thosakwe 2018年07月02日

👍2

そうですね、DSXを解析して通常のDart関数呼び出しに変換するアナライザープラグインを作成するオプションが常にあるので、コンパイラーは余分な作業を行う必要がありません。

現在、dart言語では、ハックなしでこれを実装する方法はありません（競合状態、再帰的なインポートなどを考えてください）。これは、すべてが期待どおりに機能するレベルで統合する必要があります。ホットリロード、静的分析などです。

あなたが私に尋ねるなら、DSXはオプトインである必要があります。理想的にはある種のプラグインを介してです。それを言語自体に追加する必要は非常に少ないと思います。そうすると、Dartのサーバー側とWebユーザーは、Flutterユーザーだけでなく、変更に適応する必要があります。 Dartで記述されたコードの大部分は、リモートでXML構文を必要としないため、すべての人にXML構文を適用することは悪い決断です。

スレッドを読んだら、それは初日からのアイデアです。フラッター/ダーツからのサポートでトランスパイラーを作成したいだけです。

TLDR; DSXをそれほど悪くしたい場合は、アナライザープラグインを作成し、それを自分でDartに持ってきてください。インターネットはあなたを愛し、何千ものGithubスターを獲得し、Reactのように感じるでしょう。ウィンウィン。

スレッドを読んでください、これはすでに@cbazzaによって行われています（アナライザープラグインはそれをカットするつもりはありません）

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

PS私はそれをするためにあなたと競争するでしょう

素晴らしい！これがどのように機能するかについての理論でさえ、見るのは興味深いでしょう。

birkir 2018年07月02日

👍1

SGTM。それなら、私たち全員が何らかの前処理のサポートを待っていると思います。

thosakwe 2018年07月02日

コンストラクターを介してパラメーターを渡すよりもビルダー構文の方が好きです

<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();

mohammedpascal 2018年07月03日

DSX +1

stepancar 2018年07月06日

👍1

JSXの議論はありますが、XMLをプログラミング言語に詰め込むことを嫌う人（自己を含む）も同じくらい多いと思います。それはただ間違っていると感じます（しかし、私は他の人が同じように感じていないことを完全に理解しています）。

一度実装すると機能を削除することはほぼ不可能であることを考えると、予防原則をお勧めします。 Flutterアプリの構築方法に大幅な変更を加える前に、新しいDart2構文機能のいくつかがどのように機能するかを見てみましょう。

wstrange 2018年07月07日

👍6

@wstrange
私はあなたを理解することができます。以前はJSXに反対し、jsとxml / htmlを混在させていました。それから試してみました。数ヶ月間reactに費やした後、私はJSXに恋をしました。 2つのキラーの利点は次のとおりです。

新しい構文やユーティリティはありません
変数や関数などを渡す必要はもうありません。

Bessonov 2018年07月07日

@wstrange 、

一度実装された機能を取り除くことはほぼ不可能であることを考えると、

それは当然のことではありません。GoogleがChromeからMathMLを削除すると誰が思ったでしょうか。

Flutterアプリの構築方法に大幅な変更を加える前に、新しいDart2構文機能のいくつかがどのように機能するかを見てみましょう。

これは、Flutterアプリの構築方法をまったく変更するものではなく、現在の方法を変更しない代替方法であり、最も重要なのは、クラスライブラリとは異なる構文であるということです。単純なトランスパイラーは、Flutterクラスからの情報を必要とせずにマッピングを実行するため、現在および将来のFlutterだけでなく、誰のコードでも問題なく機能します。

@ベッソノフ、

はい、Reactを操作するのに数か月を費やしてから、コンポーネント階層を処理するためのライブラリがどれほど驚異的であるかを理解するまで、Reactを知りません。

cbazza 2018年07月08日

👍4 👎1

@cbazzaFlutterについてもまったく同じことが言えます。それを使用して数週間を過ごすと、JSXを見逃すことはありません。

escamoteur 2018年07月08日

👍6

反応は私たちにすべてを教えてくれます。

今のところ、 +1は-1 $のほぼ2倍です

leedstyh 2018年07月08日

@escamoteur 、
はい、非常に公正な発言ですが、私はFlutterで多くの時間を過ごしており、DSXがそれに付加する価値を確かに見ることができます。 @leedstyhが気付いたように、DSXファンはほぼ2対1でレースをリードしています。これは、このフォーラムの人々がFlutterの人々であることを考えると非常に驚くべきことです。

cbazza 2018年07月08日

👍2

質問があります：

DSX構文を使用する場合、ネストされた子/子はWidgetタイプであると暗黙的に想定します。ネストされた子/子をウィジェットの特定のサブタイプにすることを明示的に指定したい場合はどうなりますか？

たとえば、カスタムウィジェットの子にコンテナのリストのみを受け入れさせたい場合、子にList<Container>で注釈を付けることができ、コンテナとは異なるものを配置するとすぐにIDEでエラーが発生します。私が知っているように、dsxを使用する場合、このようなタイプセーフを強制する方法はありません。アプリのコンパイル時にエラーが発生する可能性がありますが、入力中にエラーが発生する方が良いと思います。

少なくともv1のリリース後は、UIを宣言するためのフラッターな方法を試して、慣れるための時間をみんなに与えるべきだと思います。次に、この機能を詳しく調べることができます。

sandangel 2018年07月08日

👍1

@sandangel 、

非常に良いキャッチ!!! 私はあなたに私の仮想帽子をボウルします。私の最初のプロトタイプには、最初から気付いていたいくつかの穴があり、人々がそれらを見つけて前に出るのを待っていました。私は、人々がテクノロジーについて争うのではなく、テクノロジーについて議論することに興味を持ってくれることを望んでいました。

これに対する解決策は、名前空間の別のパラメーターとして配列型を提供することです。名前空間が大きくなるにつれて、「children」の短縮形を「*」に設定できます。

https://spark-heroku-dsx.herokuapp.com/index.htmlの例2で、アクションがデフォルトの「Widget」ではなく「Container」の配列である場合、次の選択肢のようになります。

        <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 2018年07月09日

👍1

こんにちは@cbazza 、ご回答ありがとうございます。

私はあなたの解決策について疑問に思っています。 w3shool-XML名前空間で説明されているようにxml名前空間を誤用していますか？

名前空間は主にXMLドキュメントの名前の競合を解決するために使用されると述べています。

したがって、誰かが上記のXMLを読んだときに、名前空間 'actions'の名前空間 'children'の下でContainerタグを宣言していると思うかもしれません。ネストされたすべての子は、Containerである必要があります。上記の説明を読まずにあなたの提案構文を最初に読んだとき、それは私を混乱させます。

もっと良いものがありますか？

sandangel 2018年07月09日

DSXはXMLではなく、XMLに似ているため、Angularテンプレート言語のようなXMLセマンティクスに従う必要はありません;）とにかく、私は常により良い代替案や提案を受け入れており、ここで議論したいと思います。

cbazza 2018年07月09日

React-nativeから来て、私は最初にJSXのような実装をサポートし、ネストされたオブジェクトが好きではありませんでしたが、OOPを楽しんで、すべてをオブジェクトとして見始めています！

React-nativeから来ている人には、このプラグインを強くお勧めします！ https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer

clarktank 2018年07月09日

👍1

@clarktank
react-native（JSX）、Flutter（OOP）、および一方から他方への旅で経験を拡張できますか？

jstansbe 2018年07月09日

@cbazza角度テンプレート構文はxmlセマンティクスに従っていると思います。私が知っているように、角度構文とxmlドキュメントの間に競合のユースケースはありません。

typescriptでは、ジェネリックコンポーネントをサポートしています。
だから私たちはこのようなものを持つことができると思います：

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

ただし、ここでも、ジェネリックコンポーネントは、プロパティ入力の型チェックに使用されます。このユースケースで、上記の構文が正しい意味を持っているかどうかはわかりません。

Flutterチームは、JSXよりも優れていると思われるUIを宣言する新しい方法のために、現在のAPIを作成したと実感しています。また、JSX構文を現在のAPIにバインドしようとすると、使用が不自然/不快に見えるようになります。

sandangel 2018年07月09日

反応は私たちにすべてを教えてくれます。
今のように、+ 1は-1のほぼ2倍になります

これは何の意味もありません。

すべてのFlutterの問題を監視している人を除いて、彼らはすでにJSXに慣れている（そして明示的にそれを探している）ため、この問題に到達した問題の2倍になります。つまり、これはむしろ_JSXのような体験を望んでいる人々が、-1に投票したすべての問題を監視している人々の2倍になることを意味します。（+1に投票する人の一部は、実際にフラッターを試したことさえありません）

a14n 2018年07月09日

👍3

@sandangel 、

Angularテンプレート構文はxmlセマンティクスに従っていると思います。私が知っているように、Angular構文とxmlドキュメントの間に競合のユースケースはありません。

もちろんですが、JSXは名前空間を使用しないため、対象となるXML機能ではありません。

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

'children'をアクションからそれ自身のタグに分割するので、一種のReactの新しいFragmentタグを思い出させます。確かに、冗長性と簡潔さのバランスです。

Flutterチームは、JSXよりも優れていると思われるUIを宣言する新しい方法のために、現在のAPIを作成したと実感しています。また、JSX構文を現在のAPIにバインドしようとすると、使用が不自然/不快に見えるようになります。

FlutterがコードでUIを宣言する方法に新しいことは何もありません。おそらく、DSXを使用することは不自然で不快ですが、JSX開発者にとってはそうではありません。 JSX / DSXはFlutterに最適で、手袋のようにフィットします。手袋が気に入らない場合は素手で行ってください;）

@ a14n 、

これは何の意味もありません。

それは確かです!!! 「感情」、「思考」、「疑わしい」、「私見」、「意見」と議論することができますが、これはデータであり、具体的なデータポイントです。データが役に立たない場合は、収集しないでください。それはあなたの絵を描かないので、私はデータが役に立たないと思います。

cbazza 2018年07月09日

👍1

@cbazzaつまり、子供/子供にサブタイプのウィジェットを適用することについての上記の質問に答えようとしているとき、DartコードはJSXよりも優れた仕事をしていると感じます。

DSXはXMLではなく、XMLに似ているため、XMLセマンティクスに従う必要はありません。

もちろんですが、JSXは名前空間を使用しないため、対象となるXML機能ではありません。

よくわかりませんが、上記のコメントのいくつかを読みました。JSX/ XMLノードについて同じ意味で言及されていると思います。とにかく、個人的には名前空間を解決策として使うのは理想的ではないと思います。

比較するだけ

<actions:children:Container>

</actions:children:Container>

と

actions: <Container>[]

構文。

sandangel 2018年07月09日

👍2

@sandangel 、

はい、この場合、タグ付けの構文はより冗長です。そのため、子の短縮形は「*」であると述べました。とにかく、この場合は例外であり、規則ではありません。ほとんどの場合、「コンテナ」は言うまでもなく、「子」を指定する必要もありません。ただし、考えられるすべてのユースケースをカバーするには、機能が必要です。

cbazza 2018年07月09日

@ a14n投票は投票です、それは確かに意味します。

私はあなたの気持ちを尊重します、多分それは本当です。ただし、比率が逆（1対2）の場合でも、33％のユーザーベースを意味します。 33％は小さなシェアだと言えますか？

JSXのような体験をしたい人

ええ、何人かの人々が見ています。これはまた、_JSXのようなものの欠如が人々がフラッターを選択することを妨げる理由の1つであることを意味します_。

Flutterは、すべての問題を読むだけでなく、より多くの開発者を対象としています。

leedstyh 2018年07月10日

👍4

@jstansbe
私は独学のプログラマーであり、ほとんどの独学の人と同じように、Javascriptから始めました。
それから私はReactとReact-Nativeを学び始めました。近年、特にES6以降、JavascriptにOOPスタイルが追加されたと思います。

ですから、私のような人々は、OOPスタイルのプログラミングに慣れていません。 React Native Componentは、FlutterのWidgetsと同じクラスですが。

JSXは、純粋なOOP画像を隠します。基本的に、それは内部で何が起こるかを隠します。注：ReactはWeb開発者向けに設計されており、Web開発者はHTML構文に慣れています。そのため、JSXはWeb開発者の間で非常に人気があります。

個人的には、純粋なOOPは大きなプロジェクトにとってより理にかなっていると思います。

clarktank 2018年07月11日

👎7 👍5

@clarktank 、

コンピュータ言語について議論するときは、次のことに注意する必要があります。
（1）構文-言語を構成する文字と単語
（2）セマンティクス-それらの文字と単語の意味

たとえば、多くの言語での関数呼び出しは次のようになります（つまり、次の構文になります）。

a = someFunction(param1, param2)

別の言語が関数呼び出しに丸括弧の代わりに角括弧を使用することを決定したと想像してください。次のようになります。

a = someFunction[param1, param2]

ここで重要なのは、構文は異なりますが、セマンティクスは同じです。つまり、どちらも基本的に関数呼び出しを行っていますが、構文が異なります。

JSXは、純粋なOOP画像を隠します。基本的に、それは内部で何が起こるかを隠します。

まったく真実ではありません。 JSX / DSXは、まったく同じものとはまったく異なる構文です（セマンティクスは同じです）。 JSXの場合、XMLタグはReactコンポーネントを作成するだけです（Pure Javascriptで実行できるのと同じです）。 DSXの場合、XMLタグはFlutterウィジェットを作成するだけです（Pure Dartで実行できるのと同じです）。構文は異なりますが、まったく同じものを生成するため、内部的には同じです。

注：ReactはWeb開発者向けに設計されており、Web開発者はHTML構文に慣れています。そのため、JSXはWeb開発者の間で非常に人気があります。

JSXは、Web、モバイル、またはUI開発のいずれの場合でも、コンポーネントツリー階層を管理するための優れた方法であるため、人気があります。以下のコードでは、ドロップダウンコンポーネントがWeb用かモバイル用かがわからないことに注意してください。

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);

個人的には、純粋なOOPは大きなプロジェクトにとってより理にかなっていると思います。

どうですか？（JSX / DSXまたはPureJavascript / Dartを使用すると、内部でまったく同じものが生成されることを考慮してください）。

cbazza 2018年07月11日

👍4 ❤1 🎉1

@cbazza

私はreact-nativeをほぼ1年間使用しましたが、Flutter / Dartを使い始めるまで、JSX要素がインスタンス化されているオブジェクトであるとは思いもしませんでした。私の見解では、あなたが言ったように、それは意味的に同じことを内部で行っていますが、それはOOP画像を隠します！

大規模なアプリケーションでは、JSXはネストされたオブジェクトと同じくらい醜いものになる可能性もあります。構文的には、混乱を招く可能性のある別のスタイルを導入するよりも、一貫性を保ちたいと思います。

clarktank 2018年07月12日

👍12 👎1

@clarktank 、

大規模なアプリケーションでは、JSXはネストされたオブジェクトと同じくらい醜いものになる可能性もあります。構文的には、混乱を招く可能性のある別のスタイルを導入するよりも、一貫性を保ちたいと思います。

私にとって、それを他のコードと異なって見えるようにすることは、実際には利点です。

cbazza 2018年07月12日

👍5 👎2

（テキストの壁については、事前にお詫び申し上げます。）

生のDartまたはJSX / DSXが「優れている」かどうかにかかわらず、自分自身を決定的な情報源と見なすのに十分な時間React-NativeまたはFlutterを使用していない人として、この問題のスレッドは読むのがかなり魅力的です。ただし、0.02ドルを下げたいことがいくつかあります。

まず、JSXが実際に何であるか、そしてそれが開発者にどのように役立つかについて、さまざまな人々に同意していることに気づきました。何よりもまず、JSXは、既存のJavascriptコードにインライン化できる「ダイナミックHTML」の形式として設計されました。 ReactのようなJSベースのWebプラットフォームには、Web開発者がひどいネイティブの方法（またはわずかに優れたjQueryの方法）に取り組むことなく、DOMとクリーンかつ効率的に対話できるようにするために不可欠です。また、JSXはその性質上、基盤となるデータから簡単に切り離すことができるUI開発を促進し、適切に編成されたプロジェクト構造を促進します。そのような環境の中で、JSXは生産性を高めるためのツールであり、それについて議論することは事実上不可能だと思います。

その段落がReact-Nativeにどのように関連しているかは、モバイル開発プラットフォームであるにもかかわらず、Reactの直接の子孫であるということです。そのため、ほとんどすべての構文とパラダイムは、元々Web開発を念頭に置いて作成されていました。これは仕様によるものです。RNの全体的な欠点は、「Reactを使用してクロスプラットフォームのモバイルアプリを作成」できることです。したがって、使用するとWeb開発のように感じることが_想定_されます。 RNアプリも主にJavascriptで記述されているため、JSXを含めるのは自然なことです。 JSXは、Web開発に役立つのとほぼ同じ理由で、RN開発に役立ちます。（これが、少なくともRNでは、JSXアプローチがネイティブアプローチよりもはるかに頻繁に使用される大きな理由の1つだと思います。RN自体はWebプラットフォームのように感じるので、よりWebに自然なアプローチが必然的に進んでいます。優勢になるために。）

一方、Flutterにはそのような設計哲学はありません。これは純粋にネイティブなクロスプラットフォームソリューションであることが意図されており、React-Nativeに触発されたと述べていますが、Webアプリというよりもネイティブデスクトップまたはモバイルアプリのように記述します。また、JavaScriptではなくDartを使用して実行されます。これは、JSXのようなものを統合するという観点からは主要な考慮事項です。 1つは、JS DOM関数は（関数の設計とJS言語自体の両方のために）ひどく冗長になる可能性がありますが、言語としてのDartは、クリーンなUI宣言コードをはるかに容易にしますが、Flutterはほとんどの場合UIコンストラクターを簡潔に保つ。別の場合（ @sandangelが指摘したように）Dartは静的に型付けされた言語であるため、JSのような動的に型付けされた言語用に設計されたJSXの性質は、たとえばUIコンストラクターが特定のタイプのウィジェット。冗長性を高める唯一のソリューションです。個人的には、DSLは、意図されていなかったシステムに固有のユースケースの増加に対応する必要があるため、時間の経過とともに肥大化し、保守が困難になるという解決策のように感じます。のために使用される。

そのため、JSX / DSXが、個人的な好みの問題を超えて、Flutter開発の生産性にどのように役立つかは実際にはわかりません。両方の構文は全体的に冗長性がほぼ同等であり、特定のインスタンスで冗長性が失われる場合は、明確にそれを補います（たとえば、終了XMLタグ）。これは主に、誰かがWeb指向のバックグラウンド（React / RN、Angularなど）からFlutterにアクセスするのか、ネイティブバックグラウンド（Java / Kotlin / Swift、WPF / UWPなど）からFlutterにアクセスするのかを決定します。彼らが好むアプローチ。このスレッドだけでも、最初はJSXに非常に懐疑的だったというユーザーストーリーがたくさんありますが、数か月使用した後、「なくてはならない」という意見に変わりました。（私の皮肉な部分は、彼らがチャンスを与えた場合、ネイティブのダートアプローチでも同じことが非常によく起こる可能性があることを指摘したいと思います。）

そうは言っても、DSXがネイティブUIコンストラクターの代わりとしてFlutterチームによって公式にサポートされるようになることに同意しているとは思えません。サードパーティのソリューション（および実際に実装するための@cbazzaのすべての小道具）としては完全に問題ありませんが、非WebテクノロジーベースのプラットフォームとしてのFlutterのコアの性質には実際には適合しません。そのため、自分のプロジェクトでDSXを使用したい人にはもっと力がありますが、Flutterチームが時間を費やすことができ、またそうすべきである他のもっと重要なことがたくさんあるという考え方に賛成です。

そうは言っても、DSXが公式にサポートされていることに私は本当に同意しませんが、_some_種類の公式UI形式があるべきだと思います。 @birkirが指摘したように、デスクトップまたはモバイルを問わず、ほぼすべての主要なネイティブUIプラットフォームには、直接コードベースのアプローチに加えてUI形式があります（それらのほとんどは、とにかくコードベースのアプローチに前処理されます）。ロジックファイルからUIファイルを分離することは、MVVMパターンを採用するための推奨される方法です（ちなみに、これはJSXについて常に間違った方法で私を悩ませてきたものの1つです）。したがって、私が主張するのは、Flutterには似たようなものがあるということです。インラインUI DSL形式ではなく、Dartコードから離れた独自のファイルに入れることを目的とした別のUI形式が必要です。

この考え方の一環として、私は先週末、その終わりに沿って実際にいくつかの作業を行いました。ちょっと落ち着くことができれば、そのようなフォーマットがどのように見えるかを示すために、私が「FLUI」を作り出したプロジェクトを開発しました。既存のDSL（または変更されたバージョン）を使用するのではなく、YAMLからインスピレーションを得たまったく新しいDSLを開発し、Flutter-constructor-approachレイアウトの「感触」に近づけるように最善を尽くしました。確かに、これは_非常に_初期の実装であるため、大量の問題が発生することはないと思いますが、プロセッサスクリプト（C＃/。NET標準で記述）のソースを含めて、人々がプレイできるようにしました。彼らが望むならそれで。 :)

andrewackerman 2018年07月16日

👍2 👎1

React / RNとFlutterの両方のユーザーとして、私は「DSX」の考え方に大きく反対しています。

DSXは何ももたらしません。 JS構文がひどいので、JSXはreactで使用されます。しかし、Flutterの場合、ウィジェットの作成は非常に簡単です。

古典的：

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

箱から出してすぐに読み取り可能で、書き込みが簡単で、型/ジェネリック互換であり、不要な重複はありません。

現在の構文で起こりうる唯一の不満は、「ウィジェットの閉じ括弧がどこにあるかを知るのは難しい」です。

しかし、繰り返しになりますが、公式にサポートされているIDEのdartプラグインがこの問題を解決します。たとえば、vscodeで以前のコードを開くと、次のように表示されます。

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

「カジュアルコードとUIコードを区別するのは難しい」については、リアクションルールがフラッターにも適用されます。

ウィジェットは、ダムまたはスマートである必要があります。スマートウィジェットにはUIロジックがありません。ダムウィジェットにはUIロジックしかありません。

このパターンに従うと、UIを他のUIと区別できない状況に陥ることはありません。
これは、BLoCパターンのようなものに従う場合にさらに当てはまります。これにより、ビジネスとUIの分離が大幅に強化されます。

rrousselGit 2018年07月21日

👍5 👎4 😕1

JS構文がひどいので、JSXはreactで使用されます

非常に意見の分かれる声明であり、単に真実ではありません。

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>
  );
}

birkir 2018年07月21日

👎2 👍2

非常に意見の分かれる声明であり、単に真実ではありません。

デフォルトのreact構文には不要な文字がたくさんあります。
各構文の単語の繰り返しと文字数を比較してみましょう（関数の定義、インデント、および「return」を除く）

JSXなしで反応する：

133文字、3つの括弧、3つの角かっこ、3つの: 、4つの, 、および11のスペースを含む
React.createElement 2回書いた

JSX：

104文字、括弧2つ、角かっこ3つ、 : 1つ、 <>つ、スペース5つ
ContainerとTextが2回書き込まれます

ダーツ：

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 2018年07月21日

👍2

@rrousselGit

DSXが単に異なる前に数回述べたように
構文とそれはダーツのスーパーセットなので、あなたができることはすべて
ダーツあなたはDSXの中でそれをすることができます。両方を組み合わせて使用することもできます
あなたが適切と思うように構文。明らかに、あなたはチェックすることさえ気にしませんでした
サポートするために行われたDSX機能のいくつかを
ダーツ：
https://spark-heroku-dsx.herokuapp.com/index.html

-1 ---------------------------------------
Dartの場合：

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 ---------------------------------------
Dartの場合：

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

DSXの場合：

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

-3 ---------------------------------------
Dartの場合：

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

DSXの場合：

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

  }}
  child={child}
/>

-4 ---------------------------------------
Dartの場合：

Text("foo")

DSXの場合：

<Text ["foo"]/>

-5 ---------------------------------------
Dartの場合：

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

DSXの場合：

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

-6 ---------------------------------------
Dartの場合：

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

DSXの場合：

<Builder
  builder={(context) => <Container/>}
/>

cbazza 2018年07月22日

👎3 ❤1 👍1

しかし、反応からフラッターへの変換が簡単であるという議論は無効です。 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} />

次に、カスタムcode-genを使用して、次のdartファイルを生成します。

part of 'main.dart';

Widget $myStateStateTemplate({ThemeData theme}) {
  return Container(
    color: theme.cardColor,
  );
}

最終結果は、UI /ロジックの分離のための「DSX」よりもさらに優れています。潜在的なUIジェネレーターにも適しています。また、 builtを使用して実装する方がはるかに簡単です。

rrousselGit 2018年07月22日

👍1

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}/>}
/>

うーん、あなたは「関心の分離」と「技術の分離」を混同しているようです。これらは非常に異なります。ダーツコードとマークアップコードを異なるファイルに分離することは、単に「テクノロジーの分離」であり、「関心の分離」の利点を何も提供しません。ここでの懸念は、再利用可能なコードをクリーンにカプセル化するコンポーネント/ウィジェットです。そのコンポーネント/ウィジェット内で異なるテクノロジーを使用していることは問題ではありません。

また、推奨するテクノロジーの分離は、すべての命令構造（forループ、関数呼び出し、ifステートメントなど）にホスト言語を使用するJSX / DSXよりも非常に劣っています。

cbazza 2018年07月22日

ここに投稿されたコードと例の多く（特に）の後で、JSXはDSXやDartとは対照的にJSにはるかに多くの価値を追加するという結論に達しました。しかし、私の観点からは、タグを閉じるという1つの機能が非常に重要です。好き：

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

以下とは対照的に、ここのような深層構造における多くの認知の複雑さを軽減します。

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

しかし、まあ、あなたがそれをこのように使うならば：

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

わずかな利益があります。

Bessonov 2018年07月22日

このチケットのタイトルに記載されているように、DSXはJSXに似ており、JSXと同一ではありません。

あなたは私の「しかし、反応からフラッターへの変換がより簡単であるという議論は無効です」を見逃しました。

DSXの議論の半分は「JSXはreactで人気があり、ここでもこれが必要です」です。しかし、あなたはJSXとは異なる（そしてより複雑な）何かを提案しています。
残りの半分は、UIをコードから分離することです。テンプレートファイルでも実行できます。

また、推奨するテクノロジーの分離は、すべての命令構造（forループ、関数呼び出し、ifステートメントなど）にホスト言語を使用するJSX / DSXよりも非常に劣っています。

違います。テンプレートファイル内でifなどを実行できます。 cshtmlまたは角度のあるテンプレートを見てください。

パーサーがすでにある限り、テンプレートファイルは、完全に機能する1週間以内にフラッター用に実装できます。
yaml、xml、cshtml、またはディレクティブ付きのhtmlです。

DSXは多くの作業を必要としますが。

@Bessonov彼らは最近、サポートされているIDEに関する仮想コメントをモッククロージングタグに追加しました。

したがって、vscodeには次のように表示されます。

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

タグを閉じることの利点。それらを入力する必要はありません

rrousselGit 2018年07月22日

👍1

@rrousselGit

彼らは最近、サポートされているIDEに関する仮想コメントをモッククロージングタグに追加しました。

ええ、私は引用されたコメントでそれを見ました。しかし、それは同じではありません。これにより、アラインシフトが発生し、読み取りフローが妨げられます。そして、これは他のIDEやテキストプロセッサでは役に立ちません。

ものはテンプレートファイルです

IMHOテンプレートはNIH症候群に悩まされています。 PHPとHTMLを混合するアプローチがそれを行う正しい方法であるとは言いません。しかし、reactはJSXでそれをより良く行う方法を示しています。

Bessonov 2018年07月22日

👍1

@rrousselGit

あなたは私の「しかし、反応からフラッターへの変換がより簡単であるという議論は無効です」を見逃しました。

いいえ、コメントを見逃すことはありませんでした。JSXから来た人はDSXが複雑すぎると思うと言っても意味がありません。

DSXの引数の半分...

DSXを選択する理由はたくさんありますが、代わりに、理由が何であれ、人々は好みのものを選択します。

違います。テンプレートファイル内で実行できます。 cshtmlまたはangularテンプレートを見てください。

パーサーがすでにある限り、テンプレートファイルは、完全に機能する1週間以内にフラッター用に実装できます。
yaml、xml、cshtml、またはディレクティブ付きのhtmlです。

DSXは多くの作業を必要としますが。

まったく逆に、DSXは2つのxml変換のみを実装し、ホスティング言語から無料で他のすべてを取得します。新しいテンプレート言語内にダーツの力を再実装しようとする努力を想像してみてください。いいえ、ダートを連れて行きます。

cbazza 2018年07月22日

👎1

いいえ、コメントを見逃すことはありませんでした。JSXから来た人はDSXが複雑すぎると思うと言っても意味がありません。

同じことが現在のdartの実装にも当てはまります。

とにかく、ここでお互いを納得させることはできないと思います。そこで、JSXがフラッターで嫌いな理由をいくつか挙げてから、「待って見て」ください。

1.ウィジェットの作成はReactとは異なります

反応として、コンポーネントの作成を処理するのはライブラリです。 JSXは、「物事がどのように機能するかを気にしないでください。私たちはあなたのために物事を行います」と言っているので問題ありません。

フラッターではそうではありません。ビルド呼び出しのたびに、新しいウィジェットを手動でインスタンス化します。 これを理解することは非常に重要であり、JSXではわかりにくくなります。

そして、その論理の続きで：

2.人々は、 <Foo />がnew Foo()ではできない特別なことをしていると思うかもしれません

メソッドの<Foo />は特別な感じがします。フレームワークに組み込まれている無関係なことをしているようです。これは、コンポーネントがReact.Elementにラップされているreactにも当てはまります。
これは、reactで<Foo /> ！= new Foo()に変換され、 Fooに直接アクセスすることはできません。

これはフラッターには適用されず、混乱を引き起こす可能性があります。

また：

<Foo>
  <Bar />
</Foo>

それに反応して、 Fooがその子を使用しない場合、 Barはインスタンス化されません。そして、 Fooは、 renderメソッドが戻った後にインスタンス化されます。
フラッターにいる間、これは反対です。 BarとFooの両方がすぐに作成されます

これにより、React開発者が最適化されていないフラッターコードを作成する可能性があります。

3.一般的に、ダート/フラッターはJS / reactではありません

dartにJSXを追加すると、型共用体に関する問題がすでに表示されているか、実行できるようになっています。
return foo && <Component />または今後の非同期レンダリングが反応します。
「私たちはすでにJSXを持っているので、それも持つことができます！」と正当化されます。

dartに最新のJSX / react機能を実装する必要がないため、独自の構文を使用するか、構文をまったく使用しないことをお勧めします。

4.JSXはいくつかのダーツの詳細を不明確にします

小さな例として、 ScaffoldはappbarにPrefferedSizeWidgetを必要とします。
JSXを使用してScaffoldを作成した場合、人々は、特定のJSXを別のJSXに置き換えることができると期待します。これは真実ではありません

つまり、なぜ私たちができるのかが非常に不明確になります

<Scaffold
  appbar={<AppBar />}
/>

だがしかし

<Scaffold
  appbar={<Container />}
/>

rrousselGit 2018年07月22日

@rrousselGit

とにかく、ここでお互いを納得させることはできないと思います。そこで、JSXがフラッターで嫌いな理由をいくつか挙げてから、「待って見て」ください。

多くの方のご意見には賛成できませんが、時間をかけて深く考えていただき、誠にありがとうございます。

ウィジェットの作成はReactとは異なります

これは単なる実装の詳細であるため、私にとっては問題ではありません。概念的には、XMLを見ると、Reactではコンポーネントであり、Flutterではウィジェットです。

人々は考えるかもしれません新しいFoo（）ではできない特別なことをします

Dart / DSXはJavascript / JSXではないことを人々はすぐに学ぶと思います。

一般的に、ダート/フラッターはJS / reactではありません

はい、最終的には同意しますが、共通のスレッドは宣言型UIフレームワークであり、宣言型ツリー構造はJSX / DSXで適切に処理されると思います。これにより、宣言型プログラミングの考え方を維持できます。

dartにJSXを追加すると、型の共用体に関する問題がすでに表示されているか、 return foo && <Component />または今後の非同期レンダリングをreactで実行できるようになります。
「私たちはすでにJSXを持っているので、それも持つことができます！」と正当化されます。

DartにJSXを追加するのではなく、DSXを追加します。これは異なりますが、JSXと類似しており、親しみやすさは非常に重要です。

dartに最新のJSX / react機能を実装する必要がないため、独自の構文を使用するか、構文をまったく使用しないことをお勧めします。

それで、なぜあなたはダートを使っているのですか？見た目はJavaにかなり似ていますが、Javaとは異なります。それでは、これらのJavaキーワードと概念をすべて破棄して、エベレストの上でプレッツェルヨガの動きをしている間は片手でしかプログラムできないErlandに漠然と似たものを考えてみましょう;）

JSXはいくつかのダーツの詳細を不明確にします

実際には、比類のないウィジェットを接続すると、Dartコンパイラは、プレーンなDartで行った場合と同じようにエラーメッセージを吐き出します。 DSXが単なるシンシンタックスシュガーであり、魔法はなく、同じものとは構文が異なるだけであることを強調することはできません。

cbazza 2018年07月22日

👍3 ❤2 😕1

@cbazza私はあなたの投稿を読むのに何時間も費やしました、そして私はこの問題へのあなたの努力に本当に感謝しています。しかし、私は議論を終わらせるのは（一種の）簡単だと思います。フラックスはreactの公式の状態管理ソリューションでしたが、今では誰もがreduxを使用していることを覚えていますか？そして、react-native用のナビゲーションライブラリはいくつありますか？ DSXリポジトリを作成し、反応する開発者を参加させます。

sunnylqm 2018年07月23日

👍6 😄2

@rrousselGit

Dartでpart / part of構文を見たことがなく、そのドキュメントを見つけるのに苦労しています。 Dart / Flutterが公式にサポートしているものですか？ FLUIでそのようなものを使いたいです。

@cbazza

あなたはDSXの正当化で輪になって回り続けます。 DSXはJSXではありません。 DSXはJSXに似ています。 DSXは、React開発者にとってなじみのある構文となることを目的としています。 DSXは、ダーツのシンタックスシュガーだと考えています。人々はDSXがJSXではないことを学びます。（等々。）

これらすべての説明であなたが言いたいことはわかりますが、それを続けなければならないという事実は、DSXの性質に関する大きな問題を明らかにしていると思います。それは、 rrouselGitも提起した点です。 DSXはJSXではないと言い続けても、DSXを見つけた人は、DSXだと思うでしょう。それが問題です。 JSXとそれを使用する人々は、Dart / Flutterとは基本的なレベルで概念的に非常に異なるエコシステムから来ています。そのため、「親しみやすさ」のための機能を開発することは必ずしも良いことではありません。そのようなより明白な理由の1つは、指摘されたように、人々は次のようなことを試みようとしているということです。

Widget build(BuildContext context) {
    return isDialogVisible && <Widget>...</Widget>;
}

それらはJavascript / JSXからのものであるため、DSXで構文が機能することを期待しています。そうでない場合、それは認知的不協和のポイントになり、DSXだけでなくFlutter全体に対する彼らの関心を実際に「傷つける」可能性があります。親しみやすさは、人々を新しいものに楽にする手段として使用される場合に有益ですが、それは両刃の剣である可能性があります-機能の90％が同じである場合、残りの10％は単にイライラしてイライラするのに役立ちます。

DSXのもう1つの問題は、サードパーティのプラグインであるか、Flutterに正式に採用されているかに関係なく、すぐにシームレスに統合される機能になる可能性が低いことです。あなたが自分で言ったように、Flutterのデバッグとデプロイのプロセスで真に機能するためには、FlutterチームだけでなくDartチームからの公式サポートが必要です。それができない場合、前処理とツールのサポートがなければ、DSXが機能する唯一の方法は、外部の手動変換ツールを使用することです。これは、開発者が実行する必要のあるもう1つの（潜在的に長い）ステップです。

これを入力しているときに、私に起こった別のことがあります。このスレッドには、JSXを称賛するプロJSXの人々が何人かいて、UIデザインへの「関心の分離」アプローチが、UIの開発を再び検討する唯一の方法であると述べています。もしそうなら、なぜReactはそれを使用している市場での存在感を持つ唯一のフレームワークなのですか？ネイティブとクロスプラットフォームの両方のモバイルアプリフレームワークは、ストーリーボード、XMLファイル、XAMLファイル、およびその他のそのようなUI定義DSTに固執しています。 Angularや新進気鋭のVueのような他の人気のあるJSフレームワークでさえ、依然として「テクノロジーの分離」アプローチを行っています。 React開発者は、JSXが未来の道であると話しますが、実際に注目を集めているフレームワークでReact以外の場所にJSXがポップアップするのはまだ見たことがありません。

andrewackerman 2018年07月23日

👍4 ❤3

@andrewackerman

part / part ofは既存のダーツ機能です。それはどういうわけか2つのファイルを1つに結合します。通常、コード生成に使用されます。

このような手法を使用する実際のシナリオがいくつかあります。 json_serializableのように、プロパティに基づいてクラスのtoJSONメソッドとfromJSONファクトリを生成します。

part / part ofは、それ自体では実際には何もしません。興味深いのは、それをsource_genのようなものに組み合わせるときです。

rrousselGit 2018年07月23日

@sunnylqm

現在の問題は、DSXをFlutterツールと適切に統合して、デバッガーやオートコンプリートなどで.dsxファイルを操作する優れた開発者エクスペリエンスを提供することであるため、レポにコードを配置しても問題は解決しないと思います。

DSXは使用できるが、デバッガーは使用できない、またはオートコンプリートを楽しむことができないことをユーザーに伝えることは、私にとっては初心者ではありません。誰かが助けたいのなら、私が必要としているのは、完全な前処理サポート（ソースマップを含む）をDartToolsとVSCode Dartプラグインに追加する方法を見つけることです。ツールがそのDSXまたは他のトランスパイル言語（はDartのスーパーセットですが、すべてをDartにコンパイルします）は正常に機能します。

@andrewackerman

私は何も正当化する必要はありません。DSXがヒットすることを確信しており、このチケットだけで100人近くの人々がDSXに興味を持っています。

それができない場合、前処理とツールのサポートがなければ、DSXが機能する唯一の方法は、外部の手動変換ツールを使用することです。これは、開発者が実行する必要のあるもう1つの（潜在的に長い）ステップです。

DSXトランスパイラーは目がくらむほど高速で、まばたきよりも速く.dsxファイルを.dartファイルに変換できるため、速度は問題になりません。人々がDSXを使用するのを簡単にするために、機能の同等性を取得しようとしているだけです。

もしそうなら、なぜReactはそれを使用している市場での存在感を持つ唯一のフレームワークなのですか？ネイティブとクロスプラットフォームの両方のモバイルアプリフレームワークは、ストーリーボード、XMLファイル、XAMLファイル、およびその他のそのようなUI定義DSTに固執しています。

タイムラインを作成するだけで、UI開発の進化がわかります。 AndroidとiOSの開発は、現在の方法で10年以上前に開始されたため、10年前の手法（完全に必須の手法）を使用しています。リアクティブUI開発（宣言型）手法は、約8年前にWebに登場し始めました。 Reactは5年前に登場し、テクノロジーをJSXとシームレスに組み合わせた最初のReactiveフレームワークでした。 Vueは現在、古い「テクノロジーの分離」手法をサポートする最新のReactiveフレームワークですが、JSXもサポートしています。モバイルではFlutterが最新であり、ReactとしてReactiveフレームワーク技術を使用しており、VueがJSXを利用するのと同じようにDSXを利用できます。 Vueは開発者に選択肢を提供し、過度に意見を述べられていないため、Angularを殺しています。

個別のテンプレートファイルの問題は、そこにある命令型プログラミング構造（if、forループなど）が、ビジネスロジックに使用されるプログラミング言語で利用できるものと比較して非常に弱いことです。私にとって、JSXのように2つを組み合わせるのは、明らかに未来です。

React開発者はJSXが未来の道であるように話します、

!!!

しかし、実際に注目を集めているフレームワークのReact以外の場所でポップアップするのはまだ見たことがありません。

VueはJSXを使用しています

cbazza 2018年07月24日

@cbazza

私は何も正当化する必要はありません。DSXがヒットすることを確信しており、このチケットだけで100人近くの人々がDSXに興味を持っています。

私はあなたが何かを正当化する必要があると言っているのではありません。 Flutterチームがこの提案を取り上げて自分たちで実装することを主張していたとき、ええ、あなたにはかなりの正当な理由があると言っていたでしょう。あなたが自分でそれをやろうとしているので、あなたはあなたが十分だと思うどんな正当化のためにでもあなたが望むことを何でもすることができ、あなたにもっと力を与えることができます。私は、あなたが思っているほど簡単でも人気もないかもしれないと思う理由を述べているだけであり、私は彼らに逆らうためにあなたのコートにボールを置いています。

DSXトランスパイラーは目がくらむほど高速で、まばたきよりも速く.dsxファイルを.dartファイルに変換できるため、速度は問題になりません。人々がDSXを使用するのを簡単にするために、機能の同等性を取得しようとしているだけです。

この時点で、サイズが小さいUIとアプリでこれまでにテストしたと思います。自明でないものはどうですか？エッジケースに該当するものはどうですか？また、プロセスにかかる実際の時間だけが関連する部分ではありません。開発者がビルドする前に手動アクションの別のチェックリストを通過する必要があるという事実だけで、多くの人にとって十分な効果があります。

また、プロジェクトのソースコードを実際にリリースしていないため、誰もあなたのプロセスを実行し、調査結果を再確認し、改善を提案することができませんでした。この時点で、誰もが本当にできることは、便利でパフォーマンスが高いというあなたの言葉にあなたを連れて行くことだけです。

VueはJSXを使用しています

私はVueを1年近く使用してきましたが、その間、さまざまなことがどのように行われるかを確認するために、多数のオープンソースプロジェクトリポジトリを調べてきました。私は決して自分自身をVueマスターとは考えていませんが、JSXが実際に利用されているのを見たことがない人は一人もいません。人々は、 .vueアプローチを大いに好むようです（テンプレート-script-styling）render + JSXアプローチを介して。返信後、Vueのドキュメントを調べて、レンダリング関数のセクションでその情報の小さな断片を発見するまで、VueがJSXをサポートしていることさえ知りませんでした（少なくともbabelプラグインを介して）。

しかし、これは私の全体的なポイントとは無関係です。 VueはまだJavascriptフレームワークです。フラッターは間違いなくそうではありません。そのため、JSXをJavascript中心の環境で最新の最高のものにし、Dart + Flutterに変換されない理由はたくさんありますが、その多くはすでにこのスレッドで取り上げられています。

!!!

Javascript以外の開発環境でそれがうまくいくのを見るまで、私は敬意を表して反対します。

andrewackerman 2018年07月24日

👍3 ❤1

VueはJSXを使用しています

Vuespecifyにはさまざまな用途があります。 JSXはただ「そこに」あります。しかし、それは支配的な構文ではありません
必要に応じて、JSXをAngularに接続できます。誰もしませんが

React開発者はJSXが未来の道であるように話します、
!!!

将来の大きな候補はWebコンポーネントです。そして、それらはAngularやVueの最も一般的な形式で見られるものと同様にhtmlで直接使用されます

rrousselGit 2018年07月24日

@andrewackerman

開発者がビルドする前に手動アクションの別のチェックリストを通過する必要があるという事実だけで、多くの人にとっては十分にオフになります。

誰が手動アクションについて何か言いましたか？完全にシームレスなIDE統合（開発者にとって可能な限り最高のユーザーエクスペリエンス）を実現しようとしていることを明確にしませんでした。

また、プロジェクトのソースコードを実際にリリースしていないため、誰もあなたのプロセスを実行し、調査結果を再確認し、改善を提案することができませんでした。

それはDSXを使用している人々とどのように関係していますか？私はJSXを2年以上使用しており、そのソースコードを気にする必要はありません。 Dartでプログラミングできるようにするには、Dartコンパイラのソースコードを確認する必要がありますか？

私が言うことは、JSXが実際に利用されているのを見たことがないということです。人々は、render + JSXアプローチよりも.vueアプローチ（template-script-styling）を大いに好んでいるようです。

JSXは新しい追加であるため、普及には時間がかかりますが、Vueは、開発者にVueで行うべき「正しい方法と唯一の方法」を強制することなく、他のアプローチを受け入れることが重要です。

VueはまだJavascriptフレームワークです。フラッターは間違いなくそうではありません。

Riiiiightなので、JSXの代わりにFlutterでDSXを使用します。

@rrousselGit

将来の大きな候補はWebコンポーネントです。

Webコンポーネントは動物園で、死んでいますが、まだ歩いています。彼らはカナダのカンガルーと同じくらい普及しています。私は何日も続けることができましたが、逸脱することを避けるために...
https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/

cbazza 2018年07月24日

😕1 👎1 👍1

@cbazza

誰が手動アクションについて何か言いましたか？完全にシームレスなIDE統合（開発者にとって可能な限り最高のユーザーエクスペリエンス）を実現しようとしていることを明確にしませんでした。

また、そのためにはFlutter / Dartチームからの前処理サポートが必要だとおっしゃいました。私はそれで間違っていますか？

それはDSXを使用している人々とどのように関係していますか？私はJSXを2年以上使用しており、そのソースコードを気にする必要はありません。

JSXはFacebookfor Reactによって開発され、厳格な提案/設計/実装/反復プロセスを経て、手に入る何年も前に世界にリリースされました。実世界の環境で何度も厳密にテストされ、証明されています。それは成熟した技術です。そのようなもののスペックシートを見ることを要求する理由はありません。

一方、DSXは、今日、あなたと少数の人々によって開発されています。あなたはそれが何ができるか、そして何ができるかについて雄弁に語りました、しかし私たちが実際に_見た_のはほんの一握りの専用のコードスニペットとそれらがトランスパイラーによって生成されたというあなたの言葉です。試してみて、変更や改善の可能性を提案したいと思っている人はそうすることができないので、「YayJSX！」以外のあなたの努力をサポートする理由はありません。

私はあなたが嘘をついているとか何かを非難しているのではなく、JSXはDSXが持っていないレベルの信頼を獲得していると言っているだけです。

JSXは新しい追加であるため、普及には時間がかかりますが、Vueは、開発者にVueで行うべき「正しい方法と唯一の方法」を強制することなく、他のアプローチを受け入れることが重要です。

JSXは2年近くVueにいます。また、Vue自体とは異なり、JSXは、特にReactに精通している人々にとって、導入を必要としない既存のテクノロジーです。 JSXがVue.jsの世界を席巻するつもりだったとしたら、私は仕方がないのですが、今ではそうなっていると感じています。（特に、あなたが主張するのと同じくらい多くの人々がFlutterでJSXを求めていることを示している場合。）

Riiiiightなので、JSXの代わりにFlutterでDSXを使用します。

JSXとDSXは同じ構文概念です。問題は、JSXがJavaScriptのような弱い型の動的言語で構築されていたのに対し、DSXはDartのような強い型の静的言語で構築されていることです。つまり、ニッチな「JSX for Flutter」の実装以外の場合、DSXが説明しなければならない問題がたくさんあり、DSXを実際に機能させるには、いくつかの「非常に難しい」変更が必要になります。それがより視覚的に簡潔であると主張することを正当化するためにそれをあまりにも肥大化させることなく。

そして、「DSXはただのダートです。DSXが何かをできない場合は、ダートを使用してください」という反論に対処するために、DSXがないシナリオに遭遇したときはいつでも、ダートにフォールバックし続けなければならない場合、私の反論になります。それなら、なぜ私はいつもダートを使うべきではないのですか？

そして、「あなたが望むなら、DSXはただのオプションです」というその読書に対する反論に対処するために、あなたは本当に自分自身を売り飛ばしています。それが本当に「オプション」になるとしても、人々にそれを使用するように説得する何かをテーブルに持ってくる必要があります。 DSXはJSXではないので、JSXだけが欲しい人は欲しいものを手に入れることができないとあなた自身が言いました。 つまり、人々がそれを使いたいと思うには、「JSXのような魅力」を超えたいくつかの具体的な理由が必要であることを意味します。

自分で使いたいツールを作成しているだけの場合は、これはすべて無意味であり、簡単に行うことができます。しかし、実際に他の人が使用することを意図しているものを構築している場合は、それをしっかりした形で、なぜそうすべきだと思うのかを決める必要があります。

Webコンポーネントは動物園で、死んでいますが、まだ歩いています。彼らはカナダのカンガルーと同じくらい普及しています。私は何日も続けることができましたが、逸脱することを避けるために...

やや話題から外れていますが、Webコンポーネントのサポートがtarよりも遅く追加されているとしても、Webコンポーネントは本当に将来を見据えていることを指摘したいと思います。このように考えてください。Reactは、基本的にJavascriptのみでWebコンポーネントの概念を実装しているため、Reactが実行することを実行します。これらの機能がブラウザーによってサポートされ、サンドボックス化されていないパフォーマンスの恩恵を受け、DOM操作を介して操作する必要がない場合、どれほど優れているか想像してみてください。（私たちが知るまでにさらに20年かかるかもしれませんが、それでも...）

andrewackerman 2018年07月24日

❤2 👍2

@andrewackerman

申し訳ありませんが、私には延々と議論し、前に言ったことを何度も繰り返す時間がありません。とにかく合意に達することはないので、FLUIに幸運を祈ります。

あなたはそれが何ができるか、そして何ができるかについて雄弁に語りました、しかし私たちが実際に見たのはほんの一握りの専用のコードスニペットとそれらがトランスパイラーによって生成されたというあなたの言葉です。

オンラインDSXトランスパイラーは2018年2月から稼働しており、誰でも使用できるため、私の言葉を何も言う必要はありません。「コンパイル」を押すと、左側のパネルに書き込まれた内容がコンパイルされ、結果が右側のパネルに配置されます。デバッガーを開くと、ASTが書き出されているのがわかります。
https://spark-heroku-dsx.herokuapp.com/index.html

問題は、JSXがJavaScriptのような弱い型の動的言語で構築されていたのに対し、DSXはDartのような強い型の静的言語で構築されていることです。

OOP（オブジェクト指向プログラミング）の概念や「クラス」の構文のように、大きな違いはまったくありません。型なしのJavascriptでも型付きのDartでもほとんど同じです。 'if'ステートメント、 'for'ステートメントなどについても同じことが言えます。

それでも、人々にそれを使用するように説得する何かをテーブルに持ってくる必要があります。

どうやらそれはこのチケットですでに100人のためにあります。それは私が使っているよりも100倍大きいです。私には十分です。

cbazza 2018年07月24日

👍3 😕1

@cbazza

申し訳ありませんが、私には延々と議論し、前に言ったことを何度も繰り返す時間がありません。とにかく合意に達することはないので、FLUIに幸運を祈ります。

私は議論のためだけに、または根深い反JSXバイアスのためにあなたと議論しているのではありません。私はあなたに答える必要のある質問に答えさせようとしています。あなたはおそらく他の人が使用することを意図しているツールを開発していますが、「親しみやすさ」と「より良いから」という漠然とした主観的な利点を超えて、他の人が使用する必要があるという説得力のある理由をまだ提供していません。前者は、私が前に言ったように、必ずしも良いことではありません、そして後者はまだ具体的なサポートなしでなされた主張です。

ツールを成功させるには、自分が何をしているのか、なぜそれをしているのかを明確にする必要があります。また、他の人に簡単に伝えられるようにする必要があります。それは、_全員_に好まれるまで製品を作ることができないということではありませんが、明確で簡潔な目的は、設計と実装を形作るために重要です。そうしないと、方向性のないユーティリティができあがります。これは、せいぜいニッチな製品であり、あらゆる規模の製品コードになってしまうと非常に幸運になります。

オンラインDSXトランスパイラーは2018年2月から稼働しており、誰でも使用できるため、私の言葉を何も言う必要はありません。「コンパイル」を押すと、左側のパネルに書き込まれた内容がコンパイルされ、結果が右側のパネルに配置されます。デバッガーを開くと、ASTが書き出されているのがわかります。

そのリンクが実用的な例だとは思いもしませんでした。私はこれまでherokuappを使ったことがなく、それは要点か何かのように見えたので、それは私にあります。：P

（オンラインサンドボックスをいじくり回すことは、より実用的な環境でトランスパイラーをテストすることと同じではないことを指摘します。）

OOP（オブジェクト指向プログラミング）の概念や「クラス」の構文のように、大きな違いはまったくありません。型なしのJavascriptでも型付きのDartでもほとんど同じです。 'if'ステートメント、 'for'ステートメントなどについても同じことが言えます。

あなたはすでに子供の強い型付けにおけるそのような違いの1つに対処しなければなりませんでした。属性の強い型付けについてはどうですか？同じ名前の異なるライブラリのウィジェットはどうですか？誰かが複数の名前のない位置引数を持つウィジェットを作成するとどうなりますか？同じ名前のウィジェットを持つ2つのライブラリをインポートするとどうなりますか？ JavascriptとDartのようなシステム間の固有の違いをさらに示すためにポップアップすることを考えていなかったいくつかのシナリオではどうなりますか？私が言わなければならないのは、あなたがこの議論のポイントに非常に軽蔑していると、現実の環境でのDSXの寿命について心配することになります。

どうやらそれはこのチケットですでに100人のためにあります。それは私が使っているよりも100倍大きいです。私には十分です。

繰り返しになりますが、「ダートコード内のJSXのような構文を検討する」に基づいてこの問題に賛成したのは100人です。彼らは_JSX_を望んでいるので賛成しました、そしてあなたが指摘することに熱心だったように、DSXはJSXではありません。では、なぜ他にDSXを使用したいと思うのでしょうか。インラインXMLのようなUI宣言は「未来」なのでしょうか？繰り返しますが、私はそれを見ていません。

VueでJSXについてはすでに取り上げましたが、リンクしたWebコンポーネントの記事で言及されているReactの2つの選択肢、InfernoとPreactもあります。私の知る限り、JSXのような構文もネイティブにサポートしているにもかかわらず、JSベースのWebアプリ開発の世界では、どちらもまったく波を立てることができませんでした。すべてのアカウントでJSX自体のせいではないように思われるので、人々はReactのJSXのような_正確になぜ_人々について長く厳しい見方をする必要があると本当に思います。 _その_質問に答えることができれば、私たちが個人的に考えている他のすべての場所に、その1つのライブラリの1つの機能を単にフランケンスタインするのではなく、「将来の」イノベーションに向けて前進することができます。

andrewackerman 2018年07月24日

👍2

この議論だけに投資されたエネルギーの量と、現在のフレームワークを改善するために何がうまくできたのかを考えると、私は悲しくなります。

escamoteur 2018年07月24日

👍5

@andrewackerman

問題は、JSXがJavaScriptのような弱い型の動的言語で構築されていたのに対し、DSXはDartのような強い型の静的言語で構築されていることです。

申し訳ありませんが、これは問題ではありません。さらに、これはまったく意味がありません。そのほかに、TypeScriptでJSXを使用しています。

@escamoteur絶対に！

Bessonov 2018年07月24日

👍1

@escamoteur私はこれであなたと一緒です。 _100._

jogboms 2018年07月24日

👍1

@ベッソノフ

申し訳ありませんが、これは問題ではありません。さらに、これはまったく意味がありません。そのほかに、TypeScriptでJSXを使用しています。

ReactはTypeScript用に設計されていません。これはJavascript用に設計されました。すべてのウィジェット定義、属性、プロパティ、およびその他すべては、JavaScriptの動的環境で使用されるように設計されているため、TypeScriptの型安全性は、JSXがReactと対話する方法に新しい要素を導入しません。これは、JSXがFlutterとはまったく異なる設定で設計された方法のさらに別の例です。

andrewackerman 2018年07月24日

@andrewackerman
なぜそれが重要だと思いますか？ JSXは、インターフェースを記述する方法です。それ自体は言語に依存しません。ここを見てください。 JavaScriptではありません。しかし、なぜJSXでは実行できないのでしょうか。（これの実装は（まだ）ないことに加えて）

そして..あなたが知っている...フローはfbからも来ます：

FlowはJavaScriptの静的タイプチェッカーです。

使用したことのない拡張機能に対する賛否両論の販売をやめてください。私は毎日JSXを使用しており、ATMには非常に懐疑的でしたが、満足しています。 JSXは、AngularJSの場合と同様に、他のパターンで進化していると想像できます。

そして、おそらくこのトピックはダーツのより良いパターンを見つけるのに役立ちますか？ DSXは1つの提案にすぎません。上記のビルダーパターンの例、またはここに示されている他の言語の調整を見てください。そして、まあ、多分あなたのfluiはより良い方法ですか？わからない。 しかし、他の誰かの提案で悪いことについて話し合うのではなく、それを見つけてお互いに助け合い、提案を改善しましょう。

Bessonov 2018年07月24日

👍1

このトピックを閉じて、限られた会話で新しい傘のトピックを開くことを提案したいと思います。方法、フラッターの使用方法を改善するためのすべての提案は、愛を込めて、憎しみを持たずに、独自のトピックで客観的に話し合います。

Bessonov 2018年07月24日

👍2

うん、ここでの憎しみの量は壮大です、これを考えてみてください：
3587のオープンチケットがあります。「サムズダウン」で並べ替えると、
1（これ）57個の「サムズダウン」
「イマイチ」が1つ以下の3586（その他のチケット）

cbazza 2018年07月24日

@ベッソノフ

なぜそれが重要だと思いますか？ JSXは、インターフェースを記述する方法です。それ自体は言語に依存しません。ここを見て。 JavaScriptではありません。しかし、なぜJSXでは実行できないのでしょうか。（これの実装は（まだ）ないことに加えて）

これは、UIを_Javascript_で説明する方法です（したがって、名前の「JS」部分）。いいえ、それはインラインDSLであるため、言語に依存しません。そして、たとえそうであったとしても、UI宣言にはひどく不十分な、真に言語に依存しないDSLがたくさんあるので、それでも「より良い選択」にはなりません。

そして..あなたが知っている...フローはfbからも来ます：

フローはTypeScriptと同じです。Javascriptの静的型チェックシステムです。これはReactツールではなく、Reactを使用するように設計されたものでもありません。 Reactは何よりもまずJavascriptライブラリであり、JSXはReactで使用するように設計されています。 React開発に導入されるセカンダリツールやユーティリティは、最終的にはReact + JSXの相互運用性とは無関係です。

使用したことのない拡張機能に対する賛否両論の販売をやめてください。私は毎日JSXを使用しており、ATMには非常に懐疑的でしたが、満足しています。 JSXは、AngularJSの場合と同様に、他のパターンで進化していると想像できます。

私はJSXを使用しましたが、個人的な意見はありますが、意図的にこれらの意見をこの議論から除外しました。実際、私の以前のコメントを読んだら、ReactのUI開発に革命をもたらしたJSXを称賛したことをご存知でしょう。 JSX全体の市場浸透について私が行ったいくつかの穏やかな接線のコメントを除いて、私の議論は特にJSX _inFlutter_についてでした。そして、そのトピックに関しては、DSXの有効性を判断するための実際的な根拠がないため、JSXが他の場所でどのように実装されているかを調べることしかできず、その検討はあまり良い前兆ではありません。

もちろん、DSXを毎日使用していて、FlutterでDSXを使用することの実際的な利点について教えてくれる場合を除きますか？

そして、おそらくこのトピックはダーツのより良いパターンを見つけるのに役立ちますか？ DSXは1つの提案にすぎません。上記のビルダーパターンの例、またはここに示されている他の言語の調整を見てください。そして、まあ、多分あなたのfluiはより良い方法ですか？わからない。しかし、他の誰かの提案で悪いことについて話し合うのではなく、それを見つけてお互いに助け合い、提案を改善しましょう。

_それが私がやっていることです。_DSXはJSXに精通している人々のためのUIソリューションとして提案されています。 JSXには、DartやFlutterとはまったく異なる環境で使用することを目的とした主要な設計要素があります。 _DSXを成功させるには、これらの違いに対処する必要があります。_私は_嫌い_ではありません。私は建設的な議論を促進し、重要な質問をしようとしています。それでも、私が得ているすべての応答は、主観的なトートロジー（「JSXは未来だから良い、そしてそれは良いから未来だ」）、重要な設計ポイントの手を振る（「DSXは説明する必要がない」）になりました。 JSとDartの違いについては、何もないため」）、または単に敵対的（「明らかにJSXが好きではないので、DSXについて話すのをやめてください」）。

純粋な賞賛だけで成功する製品を作ることはできません。批判にも立ち向かい、説明する必要があります。「OMGはい、DSXを作ってください」と言って現れる人は、高揚している間は役に立ちません。このスレッド全体を通して、DSXの初期の設計と全体としての概念の両方について、完全に有効な批判を提起した人々が何人かいました。そして、ほとんどの場合、これらの批判の多くはまだ直接対処されておらず、一般的な態度は否定的です。

私の唯一の恐れは、JSXに対するこの無条件の愛が、人々がDSXを客観的に見ることを妨げていることです。 FlutterでJSXのようなものが必要な理由がわかります。また、Flutterには専用のUI DSLが必要であるという私の意見が、私がfluiを作成するきっかけになっています。しかし、DSXについて話すことを許可されているのが、DSXについて良いことしか言えない人々だけである場合、DSXは失敗します。

andrewackerman 2018年07月24日

👍1

このトピックに関する議論を最近にまとめることはできますか？
実際、この問題を未解決のままにしておく理由は見当たらない。

ダーツチームは、他の優先事項があると述べました。そして、プロのJSX側は、独自のDSX実装を自発的に作成しました

たぶん、さまざまなソリューションを提案するいくつかのオープンソースリポジトリが必要です（ほとんど機能していなくても）。 DSXやテンプレートなど。
次に、Flutterのreadmeまたはawesome_flutterからこれらのリポジトリにリダイレクトすることを検討してください。また、DSXの実装を妨げるものがある場合は、詳細について別の問題を作成してください。

次に、コミュニティにその仕事をさせます。

rrousselGit 2018年07月25日

👍2

人々はJSXを要求する新しいチケットを開き続けるので、開いたままにしておきます（これは、以前に2回行われているためです）。

cbazza 2018年07月25日

👎2

人々はJSXを要求する新しいチケットを開き続けるので、そのまま開いたままにしておきます（これは、以前に2回行われているためです）。

ここでの違いは、次のように答えることができるということです。

「今のところ、これをdart / flutterに実装する予定はありません。ただし、コミュニティの代替案[ここ]と[そこ]を確認するか、[この問題]を読むことができます。」

重複として問題を閉じます。

rrousselGit 2018年07月25日

コメントと投票のための1つの場所とそれはここにあります。 JSXのような機能のリクエストはなくなりません。Flutterツールのサポート（コンパイラとVS Code IDE）が必要なため、チケットが開かれます。この情報でチケットリクエストを更新しました（最初のコメント）。膨大な数の人々がこれを求め始めた場合、それはFlutterチームにリソースを投入するインセンティブを与えます。

cbazza 2018年07月25日

ここでの論争のほとんどは、現時点ではJSXに関するものではなく、DSXに関するもののようです。 DSXディスカッションを独自のスレッドに分割し、これをJSXに一般的なものにすることをお勧めします。

結局、DSXはJSXに何かを近づけるための1つの方法にすぎないので、これら2つの議論を1つのスレッドに混ぜてはいけません。

pulyaevskiy 2018年07月25日

これは大したことではありません。1つの言語だけが大きなメリットだと思います。jsx構文には、xmlとjsの分離などが含まれます...良くありません。

それが私の意見です。

viniciusgati 2018年07月25日

これは私が今まで見た中で最も長くて無意味なGithubの問題です。

andreyluiz 2018年07月26日

👎8 😄1

@cbazzaお疲れ様でした👍
DSX + 1

BarryYan 2018年07月31日

👎4 👍3

@BarryYan 、ありがとう

cbazza 2018年07月31日

👎2

「+1」でも「ありがとう」でも、このようなコメントは避けてください。
これにより、すべてのサブスクライバーに何も興味深いことのない電子メールが送信されます。

rrousselGit 2018年07月31日

👍4 👎1

「+1」でも「ありがとう」でも、このようなコメントは避けてください。
これにより、すべてのサブスクライバーに何も興味深いことのない電子メールが送信されます。

あなたにとって興味深いものは何もありません!!!
人々に何を言うか、何をすることができるかを伝えることを避け、あなたが何を言うか、何をすることができるかだけに焦点を合わせてください。

cbazza 2018年07月31日

👎6 😕1

@cbazza

おい、それは基本的なエチケットです。このスレッドの新しいメッセージは、購読しているすべての人に電子メールを送信します。そのため、理由もなく人々を苛立たせるため、ディスカッションに貢献しないコメントを投稿するのは失礼です。「+1」や「ありがとう」などの基本的な反応は、簡単な親指を立てる反応で伝えることができるので、そうするだけです。

そうは言っても、このスレッドが本当に誰かが「+1」メッセージを投稿するべきかどうかについて議論することに移った場合、それはすべての建設的な議論が公式に死んだことを示す大きな赤い旗であり、それは本当に閉じられるべきです（おそらく永久に）この時）。

andrewackerman 2018年07月31日

👍3

@andrewackerman 、

了解しましたが、小説（長くて架空の文章）でこのスレッドを爆破するときは、基本的なエチケットも検討する必要があります。

意味のない質問（ご存知のとおり、壁にたくさんのがらくたを投げて、何かがくっつくかどうかを確認してください）と要求のスプレーアンドプレイの弾幕でFUD（恐怖の不確実性と疑い）を広めるのを止めてください。

結局のところ、あなたはDSXに何の価値も加えていないので、このテーマについてあなたと話し合うことに興味はありません。あなたの動機は明らかですが、DSXを爆破しながらFLUIを宣伝してください。

何か教えてください、FLUIに適用されたときのあなた自身の質問に対する答えはありますか？ FLUIについて少し話し合いましょう。

cbazza 2018年07月31日

👎3

@cbazza

了解しましたが、小説（長くて架空の文章）でこのスレッドを爆破するときは、基本的なエチケットも検討する必要があります。

私が「長くて架空の文章」としてできる限りよく考えられ、偏見のないものにするために多くの時間と労力を費やした私の回答を参照しているという事実は、あなたの性格とあなたがどのように近づいているかについて多くを示していますこの議論。私は、FlutterでのJSXの実装を取り巻く非常に現実的な問題についての議論を促進しようとしています。基本的なエチケットの最大の犯罪者は誰ですか？

意味のない質問（ご存知のとおり、壁にたくさんのがらくたを投げて、何かがくっつくかどうかを確認してください）と要求のスプレーアンドプレイの弾幕でFUD（恐怖の不確実性と疑い）を広めるのを止めてください。

私が「要求している」唯一のことは、DSXに関して多くの人々によって提起された多くの問題に、手波またはオープンな敵意以上のもので対処することです。 Flutterの機能セットに大幅な変更/追加を提案している人にとって、それは不合理な期待ではないと思います。

結局のところ、あなたはDSXに何の価値も加えていないので、このテーマについてあなたと話し合うことに興味はありません。あなたの動機は明らかですが、DSXを爆破しながらFLUIを宣伝してください。

私はあなたにあなたの立場を守るように頼んでいます。あなたはJSX / DSXが最高/未来であると繰り返し言ってきましたが、その方法や理由についてはまだ説明していません。何人かの人々がDSXについて正当な懸念を表明しましたが、それらに対処する代わりに、「気に入らない場合は使用しないでください」という反論の背後に隠れて、DSXを振り払うことになります。私の「動機」は、技術プロジェクトに関して尋ねる必要のある質問に答えてもらうことです。何よりもまず、人々が代替案よりもそれを使用する必要がある理由です。（そして私が前に説明したように、親しみやすさは十分な理由ではありません。）

FLUIに関する限り、私が行っているのは、全体的な問題に対する代替ソリューション（FlutterのUI宣言構文）を提案する一方で、DSXに対して行っているのと同じことを人々に要求することです。誠実で建設的な批判を提供します。 FLUIがDSXよりも客観的に優れていると言っているのではありません。UI開発への異なるアプローチから形成された代替案を提案し、人々に自分の意見を形成するように求めています。

（また、GUI表現の代替アプローチの可能性を提案していた最初の言及を除いて、FLUIについて話したことがあるのは、それを立ち上げたときだけです。私の裏側の動機は、あなたが私よりもそれについて話しているときにそれを促進することであるということは理にかなっていますか？）

何か教えてください、FLUIに適用されたときのあなた自身の質問に対する答えはありますか？ FLUIについて少し話し合いましょう。

FLUIはDSXではありません。DSXに関して私が提起したすべての質問に答える必要はありません。それらの多くはDSXの設計に固有のものだからです。それは、答える必要のある独自の質問のセットがないということではありませんが、いいえ、私はそれらすべての答えを持っているわけではありません。それが私が批判的な議論を大切にする理由です-FLUI / DSXは、石炭を数回かき集められて生き残ることができない限り、世論の法廷に立ち向かうつもりはありません。ただし、これはFLUIについて議論するのに適切な場所ではありません。 FLUIについて詳しく話し合いたい場合は、プロジェクトに独自の問題ボードがありますので、お気軽に投稿してください。

批判に答える代わりに、あなたは防御的で回避的でした。そのため、物事が熱くなりすぎたためにこのスレッドを一時的に閉じなければならなかった2つの別々の機会（3つに近づく）に直接責任があります。だから私は「エチケット」から抜け出し、これを一度言います：あなたのエゴを棚に置き、批判を個人的な攻撃として解釈するのをやめ、そして重要な質問に答えてください。それか、DSXが決して軌道に乗らないことで和解してください。

andrewackerman 2018年07月31日

😕1 👍1

andrewackermanお疲れ様でした👍
+ 1

jstansbe 2018年08月01日

👎4 😕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()])

他のすべてはホスト言語によって処理されるため、たとえば、次のようになります。同じ名前のコンポーネントのインポートをどのように処理するか。回答：ホスト言語。私は否定的ではありません、それはそれが設計された方法であり、それの強さの源です。マークアップとプログラミングを別々のファイルに分割すると、「if」などの単純な構造を使用してマークアップ内のプログラミングを複製し始めます。最終的には、マークアップ内に宣言型プログラミング言語を構築することになります。主なプログラミング言語。したがって、マークアップをプログラミング言語に組み込むことで、両方の長所を活用できます。これがJSX / DSXのパワーです。

上記の（2）で、変換が<Widget>をハードコーディングしていることに注意してください。これは常に当てはまるわけではないため、前に説明したように、必要に応じて指定できます。変換を見てください。すべてのシンボルはソースからのものであるか、指定できるため、将来的に大きな魔法の落とし穴はありません。

あなたが反対意見の形で誰かをなだめる間。

それは真実ではありません、あなたは反対意見を持つことができますが、私が他の方法で証明できるとき、あなたは何か真実を主張することはできません。

Flutterの機能セットに大幅な変更/追加を提案している人にとって、それは不合理な期待ではないと思います。

しかし、それが問題でした。FlutterチームにDSXを実装してもらいたかったのですが、実装する必要があるのはDSXに依存しない一般的なものであり、DSXだけが受益者ではありません。ブラウザのjsエンジンは、jsに変換されたブラウザの新しい言語のエコシステムを可能にするソースマップをサポートしています。それはダーツの作成を可能にしました!!! および他のいくつか（Coffeescript、Typescript、Reasonなど）。ダートは今同じことをすることができ、それが育てるのを助ける生態系から利益を得ることができます、すべてのボートは上昇します。

私はあなたにあなたの立場を守るように頼んでいます。

私はすでに何度もそれを行ってきましたが、結論として、PlainDartまたはDSXはユーザーの好みに依存します。そして重要なことは、人々を一方向に強制するのではなく、オプションを提供することです。

何よりもまず、人々が代替案よりもそれを使用する必要がある理由です。

スペースやタブのように、変数名の前後に定義を入力する方が好きなので、DSXを使用します。それのために戦う意味はありません。人々が異なる好みを持っていることを受け入れるだけです。そこには複数のプログラミングエディタがありますよね？

親しみやすさは十分な理由ではありません

ちょうどあなたの意見ですが、なぜ私たちはほとんどすべての言語で「if」ステートメントを使用するのですか？「for」ステートメント、「class」、そして今は「asyn / await」。

ただし、これはFLUIについて議論するのに適切な場所ではありません。 FLUIについて詳しく話し合いたい場合は、プロジェクトに独自の問題ボードがありますので、お気軽に投稿してください。

とても良いです、今あなたは私の尊敬を得ました。

あなたは、物事が熱くなりすぎたためにこのスレッドを一時的に閉じなければならなかった2つの別々の機会（3つに近づく）に直接責任があります。

再び閉鎖されても、人々がJSXのような機能を求めるのを止めることはできません。

エゴを棚上げし、批判を個人的な攻撃として解釈するのをやめ、重要な質問に答えてください。

私にはエゴはありませんが、気性が短いので、誰かが私を怒らせても間違いはありません（すぐに出てきます）。あなたを怒らせることはありませんが、あなたの質問は重要ではありませんでした。

それか、DSXが決して軌道に乗らないことで和解してください。

あなたは成功を測定するために使用されるメーターではなく、私が何をしているのかわかりません。

cbazza 2018年08月01日

おい、あなたは@jstansbeから褒め言葉を受け取ります。これは、親指を立てるよりもはるかに多くの情報を伝え、褒め言葉を低く評価しますか？

あなたはどうやら彼のコメントに内在する皮肉を理解していなかったようです。（彼は文字通り私がやらないと言ったすべてのことをしました。）私が感謝できる楽しいトローリングのビットですが、ここでは適切ではありません。そして、偶然にも彼が誠実であった場合、私は私の臆病さをお詫びしますが、私の主張は依然として有効です-そのようなコメントはここでは_まだ_適切ではありません。

あなたがJSXの経験があまりないことは私には明らかです...

このスレッドに関する私の最初のコメントでの私の免責事項は、おそらくあなたをひっくり返しましたか？

...あなたはそれがどのように機能するかを本当に理解していません。

JSXの経験があまりなく、JSXがどのように機能するのかまったくわからないということですか？私は深刻なReactプロジェクトに取り組んだことはありませんが、かなりの割合でいじくり回しました。私はそれがどのように機能するかを完全によく理解しています。

他のすべてはホスト言語によって処理されるため、たとえば、次のようになります。同じ名前のコンポーネントのインポートをどのように処理するか。回答：ホスト言語。

そして、それはマークアップ言語とホスト言語が異なる場合に意味があります。 JSXでは、マークアップ言語はホスト言語の_extension_として設計されています。そのため、JSXはJSの拡張として設計されており、それがJSXと同様に機能する理由です。 DSXは、JSX forDartの実装です。

そこに問題はありませんか？ある言語の拡張として設計されたマークアップ言語は、根本的に異なる言語にジェリーリギングされています。たくさんの問題、エッジケース、および考慮事項があることは_不可避_です。

マークアップとプログラミングを別々のファイルに分割すると、「if」などの単純な構造を使用してマークアップ内のプログラミングを複製し始めます。最終的には、マークアップ内に宣言型プログラミング言語を構築することになります。主なプログラミング言語。

まず、マークアップとプログラミングの分離の背後にある全体的な考え方は、正しく実行している場合、2つの間に明確な分離があり、重複が発生しないということです。

次に、UIコード（多くのマークアップソリューションで簡単に処理できる構造）でifやforよりもはるかに複雑なことをしている場合は、次のように主張します。とにかくあなたのデザインに何か問題があるというサインです。 MVC / MVVMの設計原則に従って、UI構造に複雑なロジックを組み込んでいる場合、それは臭いコードの潜在的な兆候であり、とにかく再設計を真剣に検討する必要があります。

（JSXを使用してMVVM方式で宣言型UIを記述できないと言っているわけではありませんが、客観的な利益をほとんど得ることができないため、問題を引き起こすだけです。使用できるのに、標準に準拠したコードを記述できるものを使用するのはなぜですか。 _そうではない_コードを書くのを難しくする何か？）

それは真実ではありません、あなたは反対意見を持つことができますが、私が他の方法で証明できるとき、あなたは何か真実を主張することはできません。

あなたは何も「証明」していません。あなたは、実証的な論理でまだ裏付けられていない主観的な主張をたくさん与えました。（あなたの名誉のために、この最新の投稿は大きな改善です。）

しかし、それが問題でした。FlutterチームにDSXを実装してもらいたかったのですが、実装する必要があるのはDSXに依存しない一般的なものであり、DSXだけが受益者ではありません。

あなたはまだ彼らに重要なことをするように求めているので、彼らと私たちの残りの人々に彼らがなぜそうすべきか、そしてなぜ彼らが彼らのやることリストにある他のことを押し下げることがとても重要なのかを説得する責任はあなたにあります。

ブラウザのjsエンジンは、jsに変換されたブラウザの新しい言語のエコシステムを可能にするソースマップをサポートしています。それはダーツの作成を可能にしました!!!

そのようなことは（比較的言えば）簡単に実行できるのはJS自体の性質であるため、DartはJSへのトランスパイラーを持つ唯一の言語とはほど遠いです。何度も指摘してきたように、ダートはJSではありません。これは静的で強く型付けされているため、JSで簡単に実行できる多くのことがDartでは非常に複雑になります。

スペースやタブのように、変数名の前後に定義を入力する方が好きなので、DSXを使用します。それのために戦う意味はありません。人々が異なる好みを持っていることを受け入れるだけです。そこには複数のプログラミングエディタがありますよね？

そのロジックによって、16進数でエンコードされた点字を使用して構成を定義するUIソリューションを作成する必要があります。つまり、本当に重要なのが個人的な好みである場合、その存在を擁護するために私が言う必要があるのは、「一部の人々はそれを好む」ということだけですよね？

あなたは他の人が使用することを意図しているツールを開発しているので、自分を説得力のあるものにするために「一部の人はそれを好むかもしれない」以上の推論が必要です。あなたがそれを言葉にできないなら、彼らがそれを他の何かの上に使うべきである理由は何ですか？そして、DSXの機能セットを設計するときに彼らがそうすることを_保証_するようにあなたを動機付けるために何がありますか？

ちょうどあなたの意見ですが、なぜ私たちはほとんどすべての言語で「if」ステートメントを使用するのですか？「for」ステートメント、「class」、そして今は「async / await」。

まず、これらのキーワード（ 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は宣言型UIを表す1つの方法ですが、それだけではなく、最も人気のあるものでもありません。さらに、あるタイプの環境で使用するように設計されているため、別の環境で使用すると、親しみやすさが悪いものに変わる可能性があります。親しみやすさにより、他の場所とほぼ同じように機能することを期待できます。そうしないと、それはあなたが_避けたい_ものである精神的な切断につながりません。

再び閉鎖されても、人々がJSXのような機能を求めるのを止めることはできません。

彼らはとにかくそれを求めます、そして問題はここですべて同じようにリダイレクトされます。閉じているスレッドがそれをどのように変えるかわかりません。

あなたは成功を測定するために使用されるメーターではなく、私が何をしているのかわかりません。

製品デザインに関する本を読んでください。第1章は常に、製品とは何か、なぜ人々がそれを気にする必要があるのかを説明する、ステートメント、マニフェスト、スローガン、わかりやすい英語で具体的で表現可能なものを作成することです。アマチュア起業家に与えられるアドバイスの最も一般的な形式は、30秒以内に製品と抽選を明確かつ簡潔に伝える「エレベーターピッチ」を作成することである理由があります。なぜ人々があなたの製品を使うべきなのかを簡潔に言えないのなら、それはそれがアイデンティティの危機に苦しんでいるというサインです。製品を設計する人が批判に適切に対応できない場合、それは彼ら自身の製品への信頼の欠如の印象を与えます。これらは両方とも、投資家にとって大きな危険信号です。

この状況では、製品はDSXであり、投資家はそれを使用することを検討している開発者です。あなたが支持しているのは、説明に「JSX」が含まれているものを無条件に応援する人だけです。このスレッドの他のすべての人は、あなたが何をしているのかという質問を見て、あなたの答えに続いて一見納得がいかないように見えました。

あなたは現在、コンバージョン率が0％かそれに近い状態にあり、批判にまだ十分に対応していないと私が言ったとき、私はそこから来ています。気にしないかもしれませんが、DSXを実際のプロジェクトで使用および使用できるUI宣言マークアッププラグインにすることを真剣に考えている場合は、開始することをお勧めします。

しかし、繰り返しになりますが、おそらくあなたは例外です。

andrewackerman 2018年08月01日

この会話は、Flutterコミュニティで受け入れられると思われる種類の議論をはるかに超えているので、このスレッドをロックしてバグを閉じます。ここでの動作の詳細については、 https： //flutter.io/design-principles/#conflict-resolutionをお読みください。

この問題に対処するためにコードを提供したい場合の次のステップは、Gradle、Xcode、ホットリロード、および既存のアプリとの統合でコード生成を機能させることができるように、システム統合を構築する方法の設計を考え出すことです。誰かがこれに取り組むことに興味があるなら、遠慮なく私に連絡してください。そうでなければ、これは来年初めに取り組むことになると思います。それを行うメカニズムができれば、DSXのようなソリューションをFlutterエコシステムに簡単に統合できるようになります。デフォルトで統合されるべきソリューションを見つけることさえあるかもしれません。その間、UI式をさらに簡単に記述できるかどうかを確認するために、Dartの構文の改善にも取り組んでいます。

非常に建設的で新しいものを持ち出す価値がない限り、このトピックに関して新しいバグを開かないようにお願いしたいと思います。

Hixie 2018年08月01日

Flutter: Dartコード内のJSXのような構文を検討してください

最も参考になるコメント

全てのコメント238件

Androidとの比較

しかし、反応からフラッターへの変換が簡単であるという議論は無効です。 JSXはプロトタイプとは根本的に異なるため、次のようになります。

関連する問題