cc @lukechurch

@cbazza Kannst du näher erläutern, warum du das willst? Vielleicht ein Beispiel zeigen, wie es im Vergleich zu heute aussehen würde?

Ok, also würde das Beispiel "Basis-Widgets" auf ' https://flutter.io/widgets-intro/#basic -widgets' wie folgt aussehen:

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

Wie wäre es mit dieser Syntax?:

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

Humm, eine kleine Verbesserung, aber nicht so gut ...
Hier sind die Dinge, die durch die Verwendung von XML erreicht werden:
(1) Kein 'Kind'- und 'Kinder'-Zeug mehr
(2) einfach für Tools von Drittanbietern zu manipulieren (parsen, analysieren und regenerieren)
(3) Beachten Sie, dass das Umschalten zwischen Markup und Programmierung leicht erkannt wird. Ich meine, in XML haben Sie '{}', um Code zu begrenzen, und im Code haben Sie ' Trennen Sie auch alle "Stil" -Dinge von der Hauptstruktur.
Ich weiß, dass dies den Weg von React im Grunde vollständig unterstützt, aber Sie sind sowieso schon auf halbem Weg;)

cc @kasperl

(1) Kein 'Kind'- und 'Kinder'-Zeug mehr

Ich verstehe nicht wirklich, warum das wünschenswert ist. "Kind" und "Kinder" sind nichts Besonderes. Betrachten Sie zum Beispiel ListTile. Wie würdest du das machen? Warum ist "Icon" in IconButton oder "Home" in MaterialApp etwas, dem Sie einen Namen geben möchten, aber nicht "Child" in Expanded? Alle drei sind nur willkürliche Argumente, die zufällig Widget-Objekte annehmen. Es gibt nichts Magisches an „Kind“ vs. „Zuhause“.

(2) einfach für Tools von Drittanbietern zu manipulieren (parsen, analysieren und regenerieren)

Sie können Dart-Code parsen, analysieren und neu generieren. Aber ich stimme zu, dass wir das einfacher machen sollten. Hoffentlich wird das Dart-Team in den kommenden Jahren bessere APIs dafür bereitstellen.

(3) Beachten Sie, dass das Umschalten zwischen Markup und Programmierung leicht erkannt wird.

Warum ist das wünschenswert? Ich meine, warum sollte irgendetwas davon als "Programmierung" gelten? Es sind alles nur Ausdrücke.

Ich meine, in XML haben Sie '{}', um Code zu begrenzen, und im Code haben Sie '

Ich verstehe die Unterscheidung nicht wirklich.

Trennen Sie auch alle "Stil" -Dinge von der Hauptstruktur.

Sie können dies heute in Flutter tun, wenn Sie wirklich wollen, fügen Sie einfach den Stil in eine Variable ein, wie Sie es im XML-Fall getan haben.

Ich verstehe nicht wirklich, warum das wünschenswert ist. "Kind" und "Kinder" sind nichts Besonderes. Betrachten Sie zum Beispiel ListTile. Wie würdest du das machen? Warum ist "Icon" in IconButton oder "Home" in MaterialApp etwas, dem Sie einen Namen geben möchten, aber nicht "Child" in Expanded? Alle drei sind nur willkürliche Argumente, die zufällig Widget-Objekte annehmen. Es gibt nichts Magisches an „Kind“ vs. „Zuhause“.

Weniger Boilerplate, das brauchen Sie nicht zu sagen, weil es in der Struktur vererbt wird.

Warum ist das wünschenswert? Ich meine, warum sollte irgendetwas davon als "Programmierung" gelten? Es sind alles nur Ausdrücke.

Es ist mit (2) verwandt, weil es das Leben von Werkzeugmachern, insbesondere GUI-Erstellern, viel einfacher macht, da sie Dart nicht vollständig analysieren müssen; aber es erleichtert auch das Lesen des Codes.

Ich verstehe die Unterscheidung nicht wirklich.

Das XML-Format ist sehr einfach. Wenn Sie also „{}“ sehen, wissen Sie, dass es einen Ausdruck in Dart berechnet. Gleiches gilt für das Gegenteil, wenn Sie den Dart-Code lesen und Sie sehen ') wissen Sie, dass eine Objekthierarchie aus XML-Markup erstellt wird.

Auch im endgültigen XML-Prozessor würde ich vermeiden, Objekte an Attribute von Eltern zu übergeben, und stattdessen untergeordnete Tags wie folgt erstellen:

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

Weniger Boilerplate, das brauchen Sie nicht zu sagen, weil es in der Struktur vererbt wird.

Aber warum nur für einen Teil der Eigenschaften? Und wie gehen Sie mit Fällen um, in denen zwei untergeordnete Slots vorhanden sind, z. B. ListItem? Die XML-artige Syntax scheint dies nicht sehr gut zu handhaben.

Ich bin mir auch nicht sicher, ob es weniger Boilerplate ist.

Vergleichen:

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

Es ist mir überhaupt nicht klar, dass die XML-ish-Syntax sauberer oder weniger Boilerplate ist. Es gibt viel mehr Satzzeichen und einige Duplizierungen von Inhalten (z. B. in den schließenden Tags). Und Sie mussten einige Namen hinzufügen, also verlieren Sie "Kind", aber Sie gewinnen "Name" auf Icon.

Wie stellen Sie außerdem mit XML klar, dass Row null, ein oder mehr als ein untergeordnetes Element annehmen kann, während Center genau ein untergeordnetes Element haben muss? Was würde passieren, wenn jemand dies tun würde?:

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

Es ist mit (2) verwandt, weil es das Leben von Werkzeugmachern, insbesondere GUI-Erstellern, viel einfacher macht, da sie Dart nicht vollständig analysieren müssen;

Sie müssten Dart aber auch nicht vollständig parsen, wenn wir eine Dart-Parsing-API hätten, richtig? Ich meine, Sie würden analysieren, was Sie analysieren möchten, und den Rest verlassen. Ich bin mir auch nicht sicher, ob es tatsächlich einfacher zu analysieren ist, da es nicht wirklich XML ist; siehe unten.

aber es erleichtert auch das Lesen des Codes.

Ich bin überhaupt nicht davon überzeugt, dass die XMLy-Version hier einfacher zu lesen ist. Nachdem Sie einige Build-Funktionen gelesen haben, gewöhnen Sie sich schnell an die verschachtelte Konstruktorsyntax.

Das XML-Format ist sehr einfach. Wenn Sie also „{}“ sehen, wissen Sie, dass es einen Ausdruck in Dart berechnet.

Es ist aber nicht wirklich XML, oder? Es ist eine Variante von XML. Gibt es wohldefinierte Parsing-Regeln dafür? Ist das zum Beispiel gültig?

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

Woher weiß es, dass das erste "}" nicht das Ende des Attributausdrucks ist, ohne Dart zu analysieren?

Gleiches gilt für das Gegenteil, wenn Sie den Dart-Code lesen und Sie sehen ') wissen Sie, dass eine Objekthierarchie aus XML-Markup erstellt wird.

Das wissen Sie heute auch, wenn Sie das Schlüsselwort new sehen, richtig? Oder tatsächlich in dem neuen Markup-Vorschlag oben, wenn Sie ein großgeschriebenes Wort sehen. Ist das wirklich ein Vorteil von XML, oder sind Sie mit XML besser vertraut als mit Dart?

Auch im endgültigen XML-Prozessor würde ich vermeiden, Objekte an Attribute von Eltern zu übergeben, und stattdessen untergeordnete Tags wie folgt erstellen:

Ich verstehe wirklich nicht, was Sie hier vorschlagen. Soweit ich das beurteilen kann, ist es überhaupt kein wohlgeformtes XML. Können Sie genau erläutern, was die von Ihnen vorgeschlagene Syntax ist und wie sie funktioniert? Zum Beispiel scheint der Konstruktor "Text" verschwunden zu sein; Woher weiß der Prozessor das?

Schau, du vermischst alles, was ich sage, und dieses Gespräch führt nirgendwo hin. Rechtlich gesehen sind Sie "Zeugnisverdrängung".

Wenn Sie wirklich daran interessiert sind zu erfahren, warum JSX so beliebt ist, googeln Sie einfach nach „React Tutorial“ und beachten Sie, dass in den letzten 2 Jahren alle Artikel zu React JSX verwenden. Die ursprüngliche Methode zum Erstellen von Komponentenhierarchien in React (die der aktuellen Methode in Flutter entspricht) wird nie wieder erwähnt, da JSX zur bevorzugten Methode wurde (Best Practice).

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

Eine weitere interessante Sache ist, dass Typescript auch JSX übernommen hat:
https://www.typescriptlang.org/docs/handbook/jsx.html

Sie haben nicht verstanden, dass XML-Parsing (mit etwas zusätzlichem Code, um '{}' richtig zu überspringen) um Größenordnungen einfacher ist als das vollständige Parsing einer Programmiersprache wie Dart. Das ist ein Fakt. Sie gehen davon aus, dass Werkzeughersteller Dart für ihre Entwicklung verwenden werden, nicht der Fall, Intellij verwendet höchstwahrscheinlich Kotlin und Java in ihren IDEs, die Dart unterstützen (sie sind ein Sonderfall, weil sie sich auf das Parsen von Sprachen spezialisiert haben; alle anderen werden Schwierigkeiten haben, vollständig zu sein parse Dart aus einer anderen Sprache).

Was ich daran mag, XML in eine andere Sprache zu integrieren, ist, dass es eine kognitive Trennung zwischen den beiden bietet, da XML sich stark von Programmiersprachen unterscheidet. Wenn Sie einfach durch die Quelldatei scrollen, können Sie leicht erkennen, was Code und was deklaratives Markup ist. Kann das nicht mit Dart-Code erreichen, der vorgibt, Markup zu sein.

Hören Sie auf, Dinge aufzuzählen, die nicht vollständig spezifiziert sind. Alle Ihre Zweifel haben sich damit erledigt, erfahren Sie einfach mehr darüber, wie das in JSX gehandhabt wurde. Dafür fehlt mir hier einfach die Zeit.

Ich entschuldige mich, wenn ich defensiv oder aggressiv klinge. Dies ist ein Thema, das mehrmals aufgekommen ist, aber ich hatte noch nie jemanden, der bereit war, den Fall tatsächlich zu argumentieren, also fand ich dieses Gespräch sehr nützlich, um mir beizubringen, was die Gründe für die Anfrage waren. Bitte verstehen Sie meinen argumentativen Ton nicht als abwertend, ich bin sehr an Ihrem Beitrag hier interessiert.

Bitte haben Sie nicht das Gefühl, dass Sie antworten müssen. Ich kommentiere hier, damit es Transparenz bezüglich der Probleme gibt, die wir lösen müssten, bevor wir in der Lage sind, eine Entscheidung zu treffen oder auf die eine oder andere Weise zu entwerfen. Dies ist im Grunde nur ein sokratischer Dialog. Ihre Teilnahme ist willkommen, aber Sie sollten sicherlich nicht das Gefühl haben, dass es Ihre Verantwortung ist, Ihren Vorschlag zu verteidigen.

Ich habe keinen Zweifel, dass JSX "heiß" ist. In React ist die Nicht-JSX-Syntax viel schlechter als die in dieser Ausgabe vorgeschlagene alternative Syntax (die wie unser aktueller Code aussieht, aber ohne die Schlüsselwörter „new“ und „const“). Was ich zu verstehen versuche, ist, ob die gleichen Gründe, warum JSX in React "heiß" ist, auch für Flutter gelten.

In Bezug auf TypeScript für JSX war ich 2012 an Bemühungen beteiligt, E4H zu spezifizieren, und sogar davor gab es E4X . Beide Versuche starben. Daher ist es mir wichtig, dass wir verstehen, was genau die Leute an JSX im Vergleich zu anderen Syntaxen mögen.

Das Analysieren von XML ist nicht einfach, das Analysieren von XML, aber irgendwie mit geschweiften Klammern, ist auch nicht einfach. Noch weniger einfach ist das Parsing von XML, das aber irgendwie mit geschweiften Klammern in einer anderen Sprache eingebettet ist. Wie einfach das zu implementieren ist, ist jedoch wahrscheinlich keine große Sache, da es ein- oder zweimal implementiert wird und dann die Bibliothek, die dies tut, wiederverwendet wird. (Ich war stark am Schreiben der Spezifikationen für das Parsen von HTML und an ähnlichen Arbeiten für XML beteiligt, und ich habe einen Parser für Dart implementiert, daher habe ich eine ziemlich gute Vorstellung davon, wie schwierig das Parsen von Auszeichnungssprachen im Vergleich zu Programmiersprachen tatsächlich ist ist.)

Was ich daran mag, XML in eine andere Sprache zu integrieren, ist, dass es eine kognitive Trennung zwischen den beiden bietet, da XML sich stark von Programmiersprachen unterscheidet. Wenn Sie einfach durch die Quelldatei scrollen, können Sie leicht erkennen, was Code und was deklaratives Markup ist. Kann das nicht mit Dart-Code erreichen, der vorgibt, Markup zu sein.

Aber warum ist es vorteilhaft, das tun zu können?

Beim Scrollen durch Flutter-Apps ist es ziemlich offensichtlich, wo sich die Build-Funktionen befinden (es sind die riesigen verschachtelten Ausdrücke). Was ist an „deklarativem Markup“ wichtig, das von „Code“ zu trennen ist?

Hören Sie auf, Dinge aufzuzählen, die nicht vollständig spezifiziert sind. Alle Ihre Zweifel haben sich damit erledigt, erfahren Sie einfach mehr darüber, wie das in JSX gehandhabt wurde. Dafür fehlt mir hier einfach die Zeit.

Soweit ich das beurteilen kann, behandelt JSX nicht die Dinge, nach denen ich gefragt habe. Zum Beispiel hat React nicht das Konzept der untergeordneten Slots. Das nächste, was ich finden könnte, ist etwas, das sie tun, indem sie zurück zu JS und dann zurück zu JSX darin wechseln, also müssten Sie in der Lage sein, sowohl die Programmiersprache als auch die Auszeichnungssprache zu analysieren.

Was ich zu verstehen versuche, ist, ob die gleichen Gründe, warum JSX in React "heiß" ist, auch für Flutter gelten.

Ja, hier gilt genau das gleiche. Der jetzige Weg sieht für Sie gut aus, denn das ist die einzige Option, die Sie haben. Geben Sie den Menschen eine zweite Option und das Gleiche wird passieren.

Ob E4X gestorben ist oder nicht, ist irrelevant, denn nichts lebt ewig. Ich habe ActionScript viel mit E4X verwendet und fand, dass Adobe dort hervorragende Arbeit geleistet hat. In gewisser Weise ist Flutter nur eine neuere Version von Adobe Flash mit Flex-Apps.

(Ich war stark am Schreiben der Spezifikationen für das Parsen von HTML und an ähnlichen Arbeiten für XML beteiligt, und ich habe einen Parser für Dart implementiert, daher habe ich eine ziemlich gute Vorstellung davon, wie schwierig das Parsen von Auszeichnungssprachen im Vergleich zu Programmiersprachen tatsächlich ist ist.)

Großartig, damit Sie wissen, dass das Parsen einer Auszeichnungssprache im Vergleich zum Parsen einer imperativen Programmiersprache trivial ist.

Aber warum ist es vorteilhaft, das tun zu können?

Lesbarkeit und Einfachheit des Codes, was wiederum eine ganze Reihe weiterer Vorteile mit sich bringt.

Beim Scrollen durch Flutter-Apps ist es ziemlich offensichtlich, wo sich die Build-Funktionen befinden (es sind die riesigen verschachtelten Ausdrücke). Was ist an „deklarativem Markup“ wichtig, das von „Code“ zu trennen ist?

Können Sie in Ihren riesigen verschachtelten Ausdrücken leicht die Struktur erkennen? kann diese Struktur leicht durch andere Tools wie GUI-Builder austauschbar verändert werden? Ich meine, wie es Adobe Flex Builder früher getan hat, ziehen Sie Widgets per Drag & Drop, verbinden Sie sie mit der Benutzeroberfläche und wechseln Sie dann zur Codeansicht und bearbeiten Sie einfach alles, was Sie möchten, und wechseln Sie dann zurück in den GUI-Modus und bearbeiten Sie die Widgets weiter. Sie können das nicht einfach tun, wenn der Programmierer in Ihre "riesigen verschachtelten Ausdrücke" eindringt und gültigen Dart-Code schreibt, der nicht der Struktur folgt, die der GUI-Editor erwartet. Mit einer festen XML-Struktur ist das kein Problem.

Soweit ich das beurteilen kann, behandelt JSX nicht die Dinge, nach denen ich gefragt habe. Zum Beispiel hat React nicht das Konzept der untergeordneten Slots

Es handhabt es ganz gut, Sie wissen nur nicht, wie es geht. Setzen Sie also in Zukunft einfach das fragliche Beispiel hier ein und ich werde Ihnen mitteilen, was meiner Meinung nach die JSX-Version sein sollte.

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

Es sieht länger aus als die Dart-Version, aber ich hätte alles in der gleichen Anzahl von Zeilen platzieren können. Die Sache ist, dass ein IDE/Editor '+' & '-' bereitstellen kann, um diese XML-Knoten trotzdem zu erweitern und zu reduzieren.

Sorgen Sie dafür, dass Flutter React-Entwicklern bekannt vorkommt, und Sie haben die Chance, eine Reihe neuer Benutzer für Flutter zu gewinnen.

Ob E4X gestorben ist oder nicht, ist irrelevant, denn nichts lebt ewig.

Ob es gestorben ist, ist nicht das Problem, es ist, warum es gestorben ist. Ist es gestorben, weil es keine Lösung bot, die die Leute wollten? Ist es aufgrund von Implementierungsproblemen gestorben? Ist es wegen Patentproblemen gestorben? War es zu früh? Zu spät? Ich denke, es ist wichtig, Lehren aus vergangenen Erfahrungen zu ziehen. Warum sind E4X und E4H gescheitert, wo JSX erfolgreich war?

Was ich interessant finde, ist, dass Leute, die neu bei Flutter sind, oft nach zwei Dingen fragen: einer Auszeichnungssprache und animierten GIFs. Drei Monate später fragen sie immer noch nach animierten GIFs, aber nicht nach einer Auszeichnungssprache. Es könnte daran liegen, dass die Auszeichnungssprache eigentlich nicht benötigt wird, wenn Sie sich daran gewöhnt haben, Build-Methoden in Dart zu schreiben. Es könnte sein, dass sie immer noch eine Auszeichnungssprache wollen, aber die Auslassung umgangen haben und daher nicht mehr daran denken, danach zu fragen. Es lohnt sich herauszufinden, welche, denn sonst riskieren wir, dass wir uns für etwas aufwenden, das die falsche Wahl ist (in beide Richtungen).

Können Sie in Ihren riesigen verschachtelten Ausdrücken leicht die Struktur erkennen?

Ja, mindestens so einfach wie mit XML. Ich persönlich finde XML sehr ausführlich und verschleiert die Struktur. Aber ich denke, das ist eher das, was Sie gewohnt sind.

(Wir experimentieren auch mit IDEs, die virtuelle „Abschluss-Tag“-Kommentare für Sie einfügen, damit Sie die Struktur sehen können, ohne sie tatsächlich schreiben zu müssen.)

Großartig, damit Sie wissen, dass das Parsen einer Auszeichnungssprache im Vergleich zum Parsen einer imperativen Programmiersprache trivial ist.

Meine Erfahrung ist, dass deklarativ vs. imperativ nicht die Unterscheidung ist, auf die es ankommt, wenn es darum geht, zu bestimmen, wie einfach eine Sprache zu parsen ist. (Zum Beispiel ist HTML „deklarativ“, aber es kann zu den am kompliziertesten zu analysierenden Sprachen gehören, mit denen ich mich je befasst habe.)

Lesbarkeit und Einfachheit des Codes, was wiederum eine ganze Reihe weiterer Vorteile mit sich bringt.

Wenn dies der Hauptvorteil ist, können wir dies testen. Wir könnten eine Mischung aus Ingenieuren nehmen, die daran gewöhnt sind, HTML, React, iOS-Code, Android-Code, Flutter, Befehlszeilen-Apps usw. zu schreiben, und ihnen jeweils verschiedene Syntaxen präsentieren und sie bitten, zu beschreiben, was sie davon halten resultierende UI würde aussehen. Wir können dann messen, welche Syntax die besten Ergebnisse erzielt. @InMatrix könnten wir uns das vielleicht nach Abschluss der Animationsarbeit ansehen?

kann diese Struktur leicht durch andere Tools wie GUI-Builder austauschbar verändert werden?

Ja, im Prinzip zumindest. Es sollte relativ einfach sein, Dart-Ausdrücke mechanisch in XML oder JSON oder eine andere strukturierte Sprache zu konvertieren, die man verwenden könnte. Es muss nur die Syntax konvertiert werden, die eigentlichen Informationen sind die gleichen. Persönlich würde ich es nicht in eine andere Syntax konvertieren, wenn ich einen GUI-Editor erstellen würde, ich würde es einfach direkt aus Dart in eine Datenstruktur im Speicher parsen.

Sie können das nicht einfach tun, wenn der Programmierer in Ihre "riesigen verschachtelten Ausdrücke" eindringt und gültigen Dart-Code schreibt, der nicht der Struktur folgt, die der GUI-Editor erwartet. Mit einer festen XML-Struktur ist das kein Problem.

Die Sache ist die, dass Sie genau den gleichen "beliebigen gültigen Dart-Code" in die XML-Struktur einfügen können wie in den Dart-Ausdruck. Sie sind buchstäblich mechanisch austauschbar. Ich sehe also nicht wirklich, wie die Verwendung von XML dabei besonders hilft. Wie würden Sie dies beispielsweise in XML umwandeln?:

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

Es handhabt es ganz gut, Sie wissen nur nicht, wie es geht.

Ich meinte speziell JSX. Ich stimme zu, dass Ihre vorgeschlagene Syntax ein vollkommen gültiger Weg wäre, um das Problem anzugehen.

Ich habe in den letzten Jahren, in denen das Produkt bei Adobe existierte, an Adobes Flex SDK gearbeitet, das XML-Markup und ActionScript kombiniert. Ich verstehe den Reiz von Markup zum Definieren von Benutzeroberflächen, kann mich aber auch an einige Nachteile erinnern:

• Visuals für Flex-Anwendungen können in Bezug auf Markup und Code definiert werden. Soweit ich mich erinnere, dominierte Code in großen realen Apps. Lesbarkeit ist nicht unbedingt ein Vorteil für Apps, die als komplexe Mischungen aus Markup und Code definiert sind.
• Die „Flex Builder“-IDE musste Apps unterstützen, die durch Markup und Code definiert wurden. Dies machte es schwierig, die IDE zu erstellen und zu warten. Entwickler betrachteten es eher als ActionScript-Tool.
• Die Weiterentwicklung und Wartung des XML-„Compilers“ war eine erhebliche Belastung, die ein Team von Ingenieuren in Vollzeit beschäftigte. Den Compiler und das Toolkit im Gleichschritt zu halten, verlangsamte die Entwicklung des gesamten SDK.

Es ist Jahre her und ich kann mich nicht mehr an alle Details erinnern. Mein Gesamteindruck ist jedoch, dass das Definieren von Benutzeroberflächen mit einer Kombination aus Markup und Code bestenfalls eine gemischte Sache ist.

Ob es gestorben ist, ist nicht das Problem, es ist, warum es gestorben ist. Ist es gestorben, weil es keine Lösung bot, die die Leute wollten? Ist es aufgrund von Implementierungsproblemen gestorben? Ist es wegen Patentproblemen gestorben? War es zu früh? Zu spät? Ich denke, es ist wichtig, Lehren aus vergangenen Erfahrungen zu ziehen. Warum sind E4X und E4H gescheitert, wo JSX erfolgreich war?

Es starb, weil E4X nur in ActionScript implementiert wurde, das nur in Adobe Flash/Flex verwendet wurde, und Adobe das Projekt beendete. Stattdessen änderte Adobe die Richtung hin zu offenen Standards, bei denen es keinen Single-Source-Anbieter mit der Möglichkeit einer Bindung und Implosion des Ökosystems gibt.

Was ich interessant finde, ist, dass Leute, die neu bei Flutter sind, oft nach zwei Dingen fragen: einer Auszeichnungssprache und animierten GIFs. Drei Monate später fragen sie immer noch nach animierten GIFs, aber nicht nach einer Auszeichnungssprache. Es könnte daran liegen, dass die Auszeichnungssprache eigentlich nicht benötigt wird, wenn Sie sich daran gewöhnt haben, Build-Methoden in Dart zu schreiben. Es könnte sein, dass sie immer noch eine Auszeichnungssprache wollen, aber die Auslassung umgangen haben und daher nicht mehr daran denken, danach zu fragen. Es lohnt sich herauszufinden, welche, denn sonst riskieren wir, dass wir uns für etwas aufwenden, das die falsche Wahl ist (in beide Richtungen).

Nun, wenn ich Sie um 2 Dinge bitten würde und Sie beides in 3 Monaten nicht getan haben und es eine Alternative zur ersten Sache gibt, würde ich Sie auch nur um das bitten, was aufgrund Ihrer Reaktionsfähigkeit und früheren Lieferleistung völlig unmöglich ist.

(Wir experimentieren auch mit IDEs, die virtuelle „Abschluss-Tag“-Kommentare für Sie einfügen, damit Sie die Struktur sehen können, ohne sie tatsächlich schreiben zu müssen.)

Irgendwie lustig, aber es ist, als wäre das Einfügen des XML-Endtags, das Sie zuvor erwähnt haben, zu ausführlich gewesen.

Wenn dies der Hauptvorteil ist, können wir dies testen. Wir könnten eine Mischung aus Ingenieuren nehmen, die daran gewöhnt sind, HTML, React, iOS-Code, Android-Code, Flutter, Befehlszeilen-Apps usw. zu schreiben, und ihnen jeweils verschiedene Syntaxen präsentieren und sie bitten, zu beschreiben, was sie davon halten resultierende UI würde aussehen. Wir können dann messen, welche Syntax die besten Ergebnisse erzielt. @InMatrix könnten wir uns das vielleicht nach Abschluss der Animationsarbeit ansehen?

Sicher können Sie das tun, ich bin sicher, Sie werden feststellen, dass "Sobald Sie React (mit JSX) machen, gehen Sie einfach nicht mehr zurück". Befragen Sie erfahrene React-Entwickler und fragen Sie sie, ob sie denken, dass JSX schlecht ist und es nie hätte gemacht werden dürfen. Zeigen Sie Ihren Weg und fragen Sie sie, ob sie JSX durch das ersetzen möchten, was Sie haben. Bevor Sie das tun, schließen Sie die Türen und sperren Sie den Ort ab, denn diese Entwickler schnappen sich einfach ihre Sachen und sprinten zum nächsten Ausgang.

Die Sache ist die, dass Sie genau den gleichen "beliebigen gültigen Dart-Code" in die XML-Struktur einfügen können wie in den Dart-Ausdruck.

Sicher, aber für die GUI-Ersteller ist das nur ein Block von Bytes, der nicht berührt werden muss und einfach übersprungen werden kann. Design/Code-Austauschbarkeit praktisch statt prinzipiell möglich machen.

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>

Ich habe Adobe Flex Builder erweiterbar verwendet ...

Entwickler betrachteten es eher als ActionScript-Tool.

Ja, aber ich habe oft von der Entwurfsansicht zur Codeansicht und umgekehrt gewechselt.
Beim Starten eines Bildschirms würde ich zur Entwurfsansicht gehen und Drag & Drop verwenden, um Widgets anzuordnen und einen ersten statischen Bildschirm zu generieren. Dann fügte ich Code und einige statische Daten hinzu, um den Bildschirm auszufüllen, damit ich den Leuten etwas zeigen konnte, das wie produktionsreifes Zeug aussah. Die Produktivität war unglaublich. Als die Entwicklung fortschritt, verband ich das Frontend mit dem Backend und die Menge an ActionScript-Code wuchs und ja, es dominierte den Code insgesamt, aber selbst kurz vor der Veröffentlichung habe ich oft die Designansicht verwendet, um die Benutzeroberfläche zu optimieren, ohne mich einarbeiten zu müssen Code.

Mein Gesamteindruck ist jedoch, dass das Definieren von Benutzeroberflächen mit einer Kombination aus Markup und Code bestenfalls eine gemischte Sache ist.

Nicht in der heutigen Welt. Imperative Sprachen haben sich in der Philosophie von Python entwickelt und eignen sich hervorragend für die Entwicklung. Deklarative Techniken mit eingebettetem Markup (XML) wurden mit dem Aufkommen von React zum Mainstream; und JSON wurde zum bevorzugten textbasierten Datenformat.

E4X wurde nur in ActionScript implementiert

E4X war ein ECMA-Standard. Mozilla lieferte es eine Zeit lang aus, entfernte es dann aber (ein sehr ungewöhnlicher Schritt für einen Browser-Anbieter). Andere Browserhersteller wollten es nie implementieren. (Sie haben jedoch andere neue ECMA-Funktionen implementiert.) Bei E4H waren die Browserhersteller nie daran interessiert, es zu implementieren (obwohl sie noch viele andere Dinge implementiert haben, an deren Erfindung ich mitgewirkt habe).

Nun, wenn ich Sie um 2 Dinge bitten würde und Sie beides in 3 Monaten nicht getan haben und es eine Alternative zur ersten Sache gibt, würde ich Sie auch nur um das bitten, was aufgrund Ihrer Reaktionsfähigkeit und früheren Lieferleistung völlig unmöglich ist.

Das ist eine mögliche Theorie. Die Leute neigen jedoch dazu, nach vielen anderen Dingen zu fragen, und viele der Dinge, nach denen sie fragen, werden implementiert, und es gibt auch Problemumgehungen für animierte GIFs, daher bin ich mir nicht sicher, ob dies die Situation vollständig erklärt.

Irgendwie lustig, aber es ist, als wäre das Einfügen des XML-Endtags, das Sie zuvor erwähnt haben, zu ausführlich gewesen.

In der Tat. Dies ist eine optionale IDE-Funktion, die Sie nicht in den Code schreiben müssen, was jedoch einen großen Unterschied darin macht, ob die Ausführlichkeit ein Problem darstellt.

... ListView ...

Wie würde ein GUI-Editor mit diesem Markup umgehen? Ich verstehe nicht wirklich, wie man die Benutzeroberfläche dafür visualisiert.

Dies kann ein Gegenargument zu dieser Anfrage sein und/oder vielleicht einige Erkenntnisse, die Sie berücksichtigen sollten, wenn Sie ein Markup wünschen. Ich habe das starke Gefühl, dass das Hinzufügen von Markup einige Herausforderungen mit GWT schafft, die ich hassen würde, wenn eine andere API durchlaufen würde.

Ich habe ein paar andere Frameworks gesehen, die diesen Übergang in Bezug auf die Erstellung von Benutzeroberflächen durchlaufen haben. Markup wie dieses funktioniert hervorragend für Tools, insofern ist es himmlisch für die IDE-Entwickler. Es ist einfacher, die Verantwortlichkeiten zu trennen, wer was tut. Obwohl ich denke, dass es besser gemacht werden kann.

GWT hat auf diese Weise angefangen, Benutzeroberflächen mit Java zu erstellen. Dann kam UiBinder, wo Sie die Benutzeroberfläche in XML-Markup mit einer Spezifikation erstellen konnten. Dann war das Tool Eclipse Plugin in der Lage, UIs im XML-Markup zu generieren. Android tut es auch, keine Notwendigkeit, den Punkt zu vertiefen. Was ich also gesehen habe, Markup funktioniert hervorragend für UI-IDE-Entwickler. Aber wirklich, Markup ist eine enorme Investition in Zeit und zusätzliche Komplexitätswerkzeuge, um es in ein echtes Programm umzuwandeln. Und das Werkzeug kommt immer zuletzt. Während sich all das in der Zwischenzeit in der Realität manifestiert, gibt es also zwei Welten. Zwei interessante Möglichkeiten, alles zu tun. Eine in der Standardsprache und eine in Markup. Deshalb unterstütze ich GWT heute. Wenn ich Dokumentation schreibe, muss ich sie zweimal schreiben, einmal für Java und einmal für UiBinder XML Markup. Die eigentliche Frage also, wenn Sie den Markup-Weg gehen wollen, sollte meiner Meinung nach die Frage gestellt werden, ob die zusätzliche Komplexität die Reise wert ist!

Ich denke, JSX zielt darauf ab, andere Probleme zu lösen, bei denen Sie Ihre Arbeit mit HTML und Javascript zusammenführen möchten. Es fühlt sich wirklich nicht so an, als würde die zusätzliche Komplexität der Markup-Spezifikation den Anforderungen des Schreibens von Benutzeroberflächen mit Markup entsprechen. Vor allem, wenn Sie nicht wirklich eine Dokumentauszeichnungssprache als Ziel haben. Zumindest nicht für den Alltagsnutzer.

Positiv zu vermerken. Ich arbeite gerne an Werkzeugen. Daher sehe ich eine Auszeichnungssprache als sehr nützlich an. Es ist viel einfacher, AST zu schreiben und zu ändern, wenn Sie Markup verwenden.

Aber andererseits, wenn Sie genug Verstand bei der Arbeit haben, spielt es keine Rolle, was Sie tun. Wenn der Entwickler seine Anwendung mit Ihrer API schneller schreiben kann, werden Sie am Ende des Tages Fahrt aufnehmen. Aber zu welchem ​​Preis für das Engineering-Team.

Ich denke, die eigentliche Frage ist, wie kann die Benutzeroberfläche schneller erstellt werden. Ich denke, das Werkzeug könnte den Dart schreiben und jedes Mittelmann-Markup überspringen. Und mein Ziel ist nicht wirklich zu sagen, dass es sich nicht lohnt, sondern wirklich die Kosten an allen Fronten zu zählen, wenn der Weg eingeschlagen wird!

E4X war ein ECMA-Standard. Mozilla lieferte es eine Zeit lang aus, entfernte es dann aber (ein sehr ungewöhnlicher Schritt für einen Browser-Anbieter). Andere Browserhersteller wollten es nie implementieren.

Ich würde sagen, nur Adobe hat sich voll und ganz für E4X eingesetzt und hatte eine gute Anhängerschaft bei Entwicklern. Browser-Anbieter fügen ihren Browsern ständig Dinge hinzu und entfernen sie; Hat Google die MathML-Unterstützung nicht entfernt?

Das ist eine mögliche Theorie. Die Leute neigen jedoch dazu, nach vielen anderen Dingen zu fragen, und viele der Dinge, nach denen sie fragen, werden implementiert, und es gibt auch Problemumgehungen für animierte GIFs, daher bin ich mir nicht sicher, ob dies die Situation vollständig erklärt.

Hier ist die Sache mit React und JSX. Sie wissen wirklich nicht, was React auf den Tisch bringt, bis Sie eine Weile damit entwickelt haben, dann wird es Nacht und Tag gegen alle anderen Frameworks.

Wie würde ein GUI-Editor mit diesem Markup umgehen? Ich verstehe nicht wirklich, wie man die Benutzeroberfläche dafür visualisiert.

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

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

Ich würde die \als Rechteck und wenn seine Kind/Kinder wo andere Widgets sind, würde ich Rechtecke dafür hineinlegen.
Da das untergeordnete Element in diesem Fall eine Funktion ist, können Sie einfach ein Rechteck mit der Aufschrift „nicht editierbar/Code“ einfügen, um den Benutzern mitzuteilen, dass dieses Widget aus Code erstellt wurde, oder in diesem Fall leicht ableiten, dass die Funktion ein flacher Wrapper für die istWidget und präsentieren Sie es einfach; Ich meine ein Rechteck, das besagt, dass die Funktion ein flacher Funktionswrapper ist, und darin das Listenelement-Widget-Rechteck (\in diesem Fall).

Aber wirklich, Markup ist eine enorme Investition in Zeit und zusätzliche Komplexitätswerkzeuge, um es in ein echtes Programm umzuwandeln.

Alles, worum ich bitte, ist, diese einfachen Erweiterungen zum Dart-Compiler hinzuzufügen, damit Entwickler, wenn sie dies wünschen, mit dieser XML-Struktur schreiben können. Der alte Weg würde weiterhin funktionieren und der Arbeitsaufwand dafür ist überhaupt nicht groß. Sie können tatsächlich sehen, wie viele Codezeilen der babel.js-Compiler benötigt, um JSX auszuführen, und ich spreche von Hunderten und nicht von Tausenden von Zeilen (ich habe es gerade überprüft).

Und das Werkzeug kommt immer zuletzt. Während sich all das in der Zwischenzeit in der Realität manifestiert, gibt es also zwei Welten. Zwei interessante Möglichkeiten, alles zu tun. Eine in der Standardsprache und eine in Markup

Sicher, aber React war so und das ist überhaupt kein Problem.

Wenn ich Dokumentation schreibe, muss ich sie zweimal schreiben, einmal für Java und einmal für UiBinder XML Markup.

Nicht in React, da Markup im Code lebt.

ist die zusätzliche Komplexität die Reise wert!

Absolut, es ist wie das Argument, ob Sie Ihre Entwickler mit den neuesten Techniken schulen und riskieren sollten, dass sie Ihr Unternehmen verlassen. Das größere Risiko besteht darin, sie untrainiert herumzuhalten. Sie müssen also die neuesten Techniken anwenden oder riskieren, zurückgelassen zu werden.

React führt die Reise mit den neuesten Techniken zur Entwicklung von UI/UX an. Es hat eine enorme Anziehungskraft bei Entwicklern. Ihr größtes Risiko besteht darin, die Reaktionsleiste nicht zu treffen.

Ich denke, JSX zielt darauf ab, andere Probleme zu lösen, bei denen Sie Ihre Arbeit mit HTML und Javascript zusammenführen möchten

JSX ist nicht nur für HTML, React Native generiert Ansichten (wie Flutter-Widgets) aus dem XML-Markup.

Ich denke, die eigentliche Frage ist, wie kann die Benutzeroberfläche schneller erstellt werden.

Eher wie UI/UX besser gebaut werden kann. Bessere Bedeutung: schneller, höhere Qualität (Code und UI/UX), reibungslose Designer-Entwickler-Interaktion usw.

Übrigens, wirklich gute Arbeit bei den Entwicklertools; 'Flutterdoktor' war der Hammer !!!
Ich koche jetzt mit Gas und kann gefährlich kreativ sein ;)

Ich wollte nur auf die hier aufgeworfene Lesbarkeitsfrage antworten, obwohl ich verstehe, dass Lesbarkeit nur einer der vielen Faktoren ist, die wir berücksichtigen müssen.

Lesbarkeit und Einfachheit des Codes, was wiederum eine ganze Reihe weiterer Vorteile mit sich bringt.

Wenn dies der Hauptvorteil ist, können wir dies testen. Wir könnten eine Mischung aus Ingenieuren nehmen, die daran gewöhnt sind, HTML, React, iOS-Code, Android-Code, Flutter, Befehlszeilen-Apps usw. zu schreiben, und ihnen jeweils verschiedene Syntaxen präsentieren und sie bitten, zu beschreiben, was sie davon halten resultierende UI würde aussehen. Wir können dann messen, welche Syntax die besten Ergebnisse erzielt. @InMatrix könnten wir uns das vielleicht nach Abschluss der Animationsarbeit ansehen?

Es gibt sicherlich Möglichkeiten, die Lesbarkeit von Code empirisch zu untersuchen, und wir können eine ernsthaftere Diskussion führen, wenn es Zeit für die Q4-Planung ist. Um eine solche Studie nützlich zu machen, müssen wir definieren, welche Arten von Leseaufgaben für Entwickler im Kontext der Flutter-Programmierung wichtig sind. Neben dem Lesen einer ganzen Build-Methode und der Vorstellung, wie die resultierende Benutzeroberfläche aussehen könnte, wirkt sich die Lesbarkeit auch auf kleinere Aufgaben aus, wie z.

Um einige dieser enger gefassten Aufgaben zu unterstützen, können wir zuerst mit UI-Verbesserungen im Editor experimentieren, was normalerweise billiger ist, als eine Auszeichnungssprache einzuführen und zu pflegen. Die schließende Beschriftungsfunktion in VS-Code ist eine dieser UI-Verbesserungen, und wir sollten verstehen, wie gut sie das Problem der Klammerübereinstimmung löst, das sie ansprechen soll. Es gibt viele andere Optionen in diesem Bereich, die wir noch nicht ausprobiert haben. Beispielsweise könnte eine andere Schriftart oder Hintergrundfarbe verwendet werden, um die Build-Methode anzuzeigen, um dem Entwickler zu helfen, sie mental vom Rest ihres Codes zu trennen.

Eine andere Sache, die mir wichtig erscheint, ist, wie wir die Leute ermutigen können, keine riesige Build-Methode zu schreiben und die Kompositionsnatur des Frameworks zu nutzen. Wenn die Build-Methode größer als die Höhe Ihres Bildschirms ist, wird sie schwer zu lesen sein, unabhängig davon, ob es sich um Dart oder XML handelt.

Eine andere Sache, die mir wichtig erscheint, ist, wie wir die Leute ermutigen können, keine riesige Build-Methode zu schreiben und die Kompositionsnatur des Frameworks zu nutzen. Wenn die Build-Methode größer als die Höhe Ihres Bildschirms ist, wird sie schwer zu lesen sein, unabhängig davon, ob es sich um Dart oder XML handelt.

Es ist nicht nur die Build-Methode. Es sind alle anderen Methoden, die die Build-Methode aufruft, um den Widget-Baum zu erstellen. In React ist es sehr üblich, kleinere Methoden zu verwenden, um Teile des Unterbaums zu erstellen und diese dann in den größeren Baum aufzurufen.

Auch in WebStorm mit JSX hat jeder XML-Knoten +/-, die zum Erweitern/Reduzieren von Knoten und untergeordneten Elementen verwendet werden können, um das Lesen von Strukturen zu erleichtern, die größer als die Höhe des Bildschirms sind.

Eine Sache, die wir in Flutter festgestellt haben, ist, dass große Build-Methoden nicht gut für die Leistung sind, und wir versuchen, die Leute zu ermutigen, ihre Build-Methoden in kleinere wiederverwendbare Widgets zu zerlegen. Insbesondere in Flutter ist eine Build-Methode, die aus den Ergebnissen anderer Methoden erstellt wird, so etwas wie ein Anti-Pattern, von dem wir eher abraten, als es einfacher zu machen. (Dies ist eine ziemlich neue Erkenntnis, daher funktionieren viele unserer Beispiele und Widgets noch nicht so gut.)

Wir versuchen, die Leute zu ermutigen, ihre Build-Methoden in kleinere wiederverwendbare Widgets zu zerlegen.

Wird es wirklich ein wiederverwendbares Widget oder einfach ein Wrapper/zusammengesetztes Widget? Ich meine, um wiederverwendbar zu sein, sollten Sie mindestens 2 Nutzungsinstanzen haben.

Die AppBar auf https://flutter.io/catalog/samples/basic-app-bar/ ist so einzigartig, dass man sie nicht wirklich als wiederverwendbare Komponente bezeichnen kann; Es ist eine Wrapper-/Composite-Komponente, und warum verwenden Sie in diesen Fällen nicht einfach eine lokale Methode, um diesen Teil der Benutzeroberfläche zu erstellen? Ich denke, wenn es mehr Dinge tun würde, wäre es sinnvoll, es in einer Wrapper-/Composite-Komponente zu platzieren.

Eine Sache, die wir in Flutter festgestellt haben, ist, dass große Build-Methoden nicht gut für die Leistung sind

Da Sie die Leistung erwähnt haben, führt das Steuern der Erstellungsmethode durch die Animationsschleife zu Leistungsproblemen für eine reibungslose Animation. Sie möchten nicht, dass Ihre Build-Methode 60 Mal pro Sekunde oder öfter aufgerufen wird, insbesondere wenn Sie bedenken, dass die Build-Methode Benutzercode ist (z. B. könnte sie eine super lange Schleife haben, die ewig dauert und dazu führen würde, dass Animationen übersprungen werden). Als Flutter-Anfänger habe ich das vielleicht falsch verstanden.

Die AppBar auf https://flutter.io/catalog/samples/basic-app-bar/ ist so einzigartig, dass man sie nicht wirklich als wiederverwendbare Komponente bezeichnen kann

Es ist auch relativ klein, also ist das ok.

In Bezug auf die Leistung ist dies für dieses Problem etwas off-topic, also reichen Sie bitte ein neues Problem ein, wenn Sie darüber diskutieren möchten (oder senden Sie eine E-Mail an flutter-dev oder posten Sie einen Stapelüberlauf, was immer Sie bevorzugen).

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

Es ist verrückt zu sehen, wie dieses Problem begraben wird. Meiner Meinung nach wird es für Flutter ein Make-or-Break sein, eine JSX-ähnliche Syntax zum Erstellen von Widgets zu implementieren.

Ich verstehe die Zielgruppe einfach nicht, viele iOS- und Android-Entwickler bewegen sich dazu, nativ zu reagieren, es scheint die perfekte Gelegenheit zu sein, Marktanteile zu gewinnen.

Ich ermutige die Beteiligten, React Native auszuprobieren und zu sehen, wovon wir sprechen.

Ich vermisse JSX kein bisschen in Flutter. Dies würde nur das Framework und die Tools für ein paar kleine Gewinne hier und da aufblähen.

@birkir Ich bin in dieser Frage 100% bei dir. Das Fehlen von JSX, das perfekt zu Flutter passt, lässt Flutter alt und rostig aussehen und fühlt sich an wie Technologie der 1990er Jahre. Tatsächlich scheint es, als würde jeder auf die eine oder andere Weise JSX übernehmen; Das neueste ist das beliebte Vue.js-Framework.

+1

@zoechi Was sind deine bisherigen Erfahrungen mit JSX, hast du es wirklich benutzt oder nur angeschaut? Ich denke, Sie unterschätzen JSX, indem Sie sagen, dass es hier und da kleine Gewinne bringen wird. Wenn Sie keine Benutzer haben, haben Sie kein Produkt.

@birkir Ich sehe hier viel Aufregung über JSX, aber niemand scheint sich die Mühe zu machen, zu erklären, was genau Flutter von einem solchen DSL profitieren würde, außer vielleicht einer besseren Lesbarkeit, die größtenteils subjektiv ist.

Mehr Funktionen belasten ein Framework normalerweise nur, anstatt es zu verbessern.
Ihre Implementierung verbraucht auch viele Ressourcen, die in anderen Bereichen fehlen, in denen fehlende Funktionen Menschen tatsächlich daran hindern, bestimmte Anwendungen zu implementieren.

Wenn Sie also begeistert sind, dass Flutter so etwas wie JSX bekommt, sollten Sie Zeit und Energie investieren, um überzeugende Argumente zu verfassen.
Etwas einfach hinzuzufügen, weil andere es auch haben, ist wahrscheinlich das schwächste Argument, das es gibt.

Es gibt auch Pläne, Dart zu verbessern, um das Schreiben von Flutter-UI-Code weniger ausführlich zu machen, was die Argumente für JSX noch mehr schwächt.

Was sind also Ihre überzeugenden Argumente?

Wirklich !!! "Niemand scheint sich die Mühe zu machen, zu erklären, was genau Flutter gewinnen würde ... bla bla bla".
Hast du diesen Thread nicht ganz gelesen? Ist Ihre Aufmerksamkeitsspanne größer als Ihr JSX-Wissen?

Ihr leidet am NIH-Syndrom (Not-invented-here). „Gute Künstler kopieren, große Künstler stehlen“, mittelmäßige Künstler, nun ja, benehmen sich wie Sie.

Allein die Tatsache, dass die Unterstützung von JSX relativ einfach ist und enorm dazu beitragen wird, neue Kunden (React Native-Mobilentwickler) für die Plattform zu gewinnen, macht es zu einem Kinderspiel, das Sie nicht sehen. Es ist nicht gut für die Plattform.

Können wir bei der Debatte bitte einen konstruktiven Ton bewahren?

Das Hinzufügen von Funktionen, weil andere sie haben, ist ein schwaches Argument. Okay.
Warum hat Flattern ein heißes Nachladen? Woher kommt das? Jesus, Alter.

Wie haben wir es versäumt, solide Argumente für euch zu liefern? Projekttraktion und das Anziehen von Entwicklern ist unser Hauptgrund.

Grund Nummer zwei, Lesbarkeit :

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

Grund Nummer drei, GUI Builders . Ich zitiere die erste Zeile in der README.

Ein neues SDK für mobile Apps, das Entwicklern und Designern hilft, moderne mobile Apps für iOS und Android zu erstellen.

Ich würde es hassen zu sehen, wie Flutter in dasselbe Kaninchenloch wie Polymer gerät, bevor es überhaupt die Beta erreicht.

Traktion von Projekten und Gewinnung von Entwicklern

Der Zusammenhang ist noch unklar.

Grund Nummer zwei, Lesbarkeit:

Dart-Code lesbarer zu machen, scheint mir ein besseres Ziel zu sein

Grund Nummer drei, GUI Builders. Ich zitiere die erste Zeile in der README.

Soweit ich mich erinnere, wurde oben bereits erwähnt, dass es keinen Grund gibt, warum die Verwendung von Dart-Code dies verhindern würde.

Ihre Gegenargumente können die Idee nicht wirklich von der Hand weisen, oder?

1. Beziehung ist ziemlich klar. Es sei denn, es ist kein Ziel für das Projekt, populär zu werden?
2. Toll! Wird es der JSX-Lesbarkeit nahe kommen? Was ist der aktuelle Vorschlag für so etwas?
3. Es wurde gesagt, dass es möglich sei . Die Anpassung der JSX-Unterstützung für derzeit verfügbare GUI-Builder wird viel einfacher sein.

Es gibt auch Pläne, Dart zu verbessern, um das Schreiben von Flutter-UI-Code weniger ausführlich zu machen

Schön, die Bestätigung zu sehen, dass der aktuelle Weg einige Verbesserungen gebrauchen könnte.
Bitte geben Sie Einzelheiten zu einem solchen Vorschlag an. Am besten interagierst du mit der React Native-Community, um Feedback zu erhalten.

Mehrere Funktionsanfragen für die Dart-Sprache könnten den Code kürzer/lesbarer machen:

• Optional new und const für Dart 2
• Meta-Problem für die Diskussion des Vorschlags, benannte Argumente überall zuzulassen - - dies könnte Widgets mit child -Argument ermöglichen, benannte Argumente zu überspringen.
  
  
  
  • Variable Anzahl von Argumenten - dies könnte es Widgets mit children -Argument (wie Row und Column) ermöglichen, dieses benannte Argument und seine Listendeklaration zu überspringen.
  
  

Mit diesen Änderungen könnte der Code so aussehen:

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

Darüber hinaus können Sie abhängig von Ihrer IDE optional synthetische Kommentare am Ende der Klammern haben, und Sie könnten so etwas in Ihrer IDE sehen:

  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
  }

Dieses Gespräch wird hitzig. Ich möchte alle ermutigen, unseren Verhaltenskodex zu lesen:
https://flutter.io/design-principles/#conflict -resolution
Ich werde dieses Gespräch für ein paar Tage beenden, während jeder darüber nachdenkt, wie er sich respektvoll und produktiv einbringen kann.

Wir alle wissen, dass die Syntax zum Erstellen von Benutzeroberflächen ein sehr wichtiger Teil der mobilen Entwicklungserfahrung ist. Im Moment ist die Syntax etwas ausführlich, ich muss etwas new machen, nur um einen Rand hinzuzufügen: margin: new EdgeInsets.symmetric(horizontal: 4.0) , ich denke, es gibt einen einfacheren Weg.

Wäre es möglich, eine DSL zu bauen, wie sie das Kotlin-Team für Android-Entwickler gemacht hat? Es heißt Anko , eine DSL zum Erstellen einer Android-Benutzeroberfläche:

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

Eine prägnante Syntax hilft, den Code lesbar und wartbar zu halten, kann auch die Bauarbeit angenehm machen, es spielt eine Rolle. Bitte schätzen Sie das Flutter-Team ernsthaft ein, bevor Sie die Entscheidung treffen. Wir alle freuen uns, wenn Flutter in den kommenden Jahren noch erfolgreicher wird.

Bitte führen Sie keine XML-ähnliche Syntax in Flutter ein.

Ich habe mehr als ein Jahr lang in Android Java programmiert und dann angefangen, nach einem plattformübergreifenden Toolset zu suchen, das ich ausprobieren könnte.
Ich habe mit React Native angefangen und dann React ausprobiert. Ich mochte die JSX-Syntax nicht wirklich, weil sie nicht ganz Javascript und nicht ganz HTML ist, also nur eine andere Sache zu lernen.
Als ich Flutter ausprobierte, fand ich den Einstieg viel einfacher (wahrscheinlich hauptsächlich aufgrund meines Java-Hintergrunds).

Ich denke, einige der Gründe, warum ich nicht möchte, dass eine XML-Syntax zu Flutter hinzugefügt wird:

1. Eine andere Sache zu lernen - könnte stattdessen damit verbracht werden, Futures zu lernen ;P
2. Kontextwechsel - Sie wechseln den Kontext zwischen XML und Code, was nur eine unnötige kognitive Belastung darstellt.
3. Es gab Tage, an denen ich morgens in Java und nachmittags in Python programmiert habe. Mit React müssen Sie möglicherweise Javascript, Babel, JSX, HTML, CSS und mehr in einer Codebasis verstehen.
4. Der Grund, warum XML in Flutter nicht notwendig ist, liegt darin, dass Dart benannte Argumente hat, die XML-Attribute ziemlich gut ersetzen.
5. Dart hat das sehr coole dartfmt, das den Code ohne großen Aufwand wirklich gut einrückt.

Im Vergleich zu Android

1. Sie müssen den programmatischen Weg sowieso lernen, warum sollten Sie einen anderen Weg hinzufügen, Dinge zu tun?
2. Das XML-Layout in Android zeigt Änderungen auf dem Gerät schneller an, aber die Ausführung in Flutter erfolgt sowieso praktisch sofort, sodass das Hinzufügen von XML diesen Vorteil nicht bieten würde.
3. Die programmgesteuerte Kombination aus Android XML und XML erhöht die Komplexität, z. B. das Aufblasen von XML-Snippets und das programmgesteuerte Einfügen in den XML-Baum.
4. Instant Run ist in Flutter so schnell, dass Sie das XML-Modell nicht benötigen, um zu visualisieren, wie es aussehen wird, Sie können einfach eine Taste drücken und die Änderung sofort sehen.
5. Die Fehler aus programmgesteuerten Layoutproblemen unterscheiden sich von Layoutproblemen in XML, sodass Sie zwei Dinge verstehen müssen.

Ich würde noch einen Schritt weiter gehen und pubspec.yaml entfernen und durch pubspec.dart ersetzen und eine Konfiguration im Dart-Code haben.

Wenn sich Entwickler über die Schwierigkeit beschweren, die Seiten visuell zu gestalten – eine Idee wäre, einen Layout-Designer zu erstellen, mit dem Sie Ihre Themen festlegen und Seiten visuell per Drag-and-Drop gestalten können. Dann würde es Flutter-Code generieren, der niemals bearbeitet werden soll, sondern Klassen erstellt, die zum Erstellen Ihrer App verwendet werden können.

Es müsste keine 2-Wege-Bearbeitung (XML/Layout) wie Android XML sein, aber Sie speichern Ihr Layout einfach für später. Wenn Sie es ändern müssen, können Sie den Code neu generieren und (hoffentlich) nur einige Argumente ändern.

Ich weiß, dass dieses Gespräch alt ist und ja, es wurde ziemlich heiß, aber ich möchte ein paar Zeilen zu dem schreiben, was meiner Meinung nach hier passiert.

Flutter ist NEU. Es ist eine völlig NEUE Art, Dinge zu tun. Ja, es hat Anleihen beim React-Paradigma gemacht. Aber das bedeutet nicht, dass es die gleichen Schritte befolgen muss. Ich denke nicht, dass es das Ziel des Teams von Flutter ist, Entwickler von React Natives zum Flattern zu bewegen, sondern nur etwas Neues zu bauen, an dem Entwickler Interesse finden könnten. Google verwendet es intern, bevor es mit der Welt geteilt wird, und sie waren damit produktiv es. Ich teile die Kommentare mit @Hixie , dass es sich beim Erstellen der Benutzeroberfläche nicht von JSX unterscheidet. Ja, es ist etwas ausführlicher, um den reinen Dart richtig zu machen. Aber es macht tatsächlich das Debuggen Ihres Codes viel einfacher.

Der Grund, warum ich gegen eine Auszeichnungssprache oder JSX oder irgendetwas anderes bin, das auf einer Technologie sitzt, ist, dass es tonnenweise mehr Arbeit von der Plattform erfordert. Sie können mit dem Komponieren von Markup-Sprache für eine Benutzeroberfläche glücklich sein, aber Sie werden so viele Entwickler haben, die an der Plattform arbeiten und weinen und Haare raufen, damit sie für Sie funktioniert. Ein anderer Standpunkt ist, dass JSX für eine Javascript-Community gearbeitet hat, wobei das Hauptziel wie immer darin besteht, die Dinge für den Entwickler einfacher zu machen und sich nicht um Kompromisse zu kümmern. Versteh mich nicht falsch React(JSX) für das Web war ein himmlisches Match, weil HTML ohnehin Markup ist. Aber für React Native sehen Sie sich den gesamten Code im Repository an, den sie tun mussten, damit es funktioniert. Das Hinzufügen von JSX zu Flattern würde eine Menge Arbeit und zwei Dinge erfordern, an die Sie denken müssen, wenn Sie neue Funktionen hinzufügen. Und wieder nur, um den untergeordneten Parameter und die Schlüsselwörter const und new entfernen zu können?. Ich bevorzuge es, zu wissen, was wirklich im Code passiert, und die Kontrolle darüber zu haben, was passiert, als eine magische Syntax zu haben, die nur Overhead hinzufügt.

Nun, das ist meine Meinung. Möchte keine neue Riesendiskussion anfangen. Nur um die Tatsache zu erwähnen, dass JSX für eine React/Javascript-Community großartig ist, weil es für sie funktioniert hat, aber für Dart/Flutter finde ich es ein bisschen übertrieben, JSX hinzuzufügen, nur um Entwickler von React Native anzuziehen.

Wow, hätte einen Blogbeitrag schreiben können xD

@Rockvole ,

Eine andere Sache zu lernen - könnte stattdessen damit verbracht werden, Futures zu lernen ;P

Die Sache, die man lernen muss, macht die aktuelle rekursive Objektkonstruktionsmonstrosität einfacher und den alltäglichen React-Native-Entwicklern vertraut, also denke ich, dass die Leute es vorziehen werden, das zu lernen.

Kontextwechsel - Sie wechseln den Kontext zwischen XML und Code, was nur eine unnötige kognitive Belastung darstellt.

Kein Problem, es gibt keinen Kontextwechsel, es ist nur ein Teil der Umgebung, die die Programmierung von UI/UX sauberer macht.

Dann würde es Flutter-Code generieren, der niemals bearbeitet werden soll

Warum nicht? Dann nicht sehr sinnvoll.

@franzsilva

Ich glaube nicht, dass es das Ziel des Flatter-Teams ist, Entwickler von React-Natives dazu zu bringen, zum Flattern zu kommen

Wirklich !!! React Native dominiert und angesichts der Tatsache, dass die Gesamtzahl der mobilen Entwickler, die plattformübergreifende Tools verwenden, begrenzt ist, glauben Sie wirklich, dass Flutter ein Homerun-Hit werden kann, ohne React Native-Leute anzuziehen?

Ja, es ist etwas ausführlicher, um den reinen Dart richtig zu machen. Aber es macht tatsächlich das Debuggen Ihres Codes viel einfacher.

Das ist keine richtige Aussage. Das Debuggen von JSX-Code, der nur Javascript-Code ist, ist weder einfacher noch schwieriger, es ist dasselbe.

Der Grund, warum ich gegen eine Auszeichnungssprache oder JSX oder irgendetwas anderes bin, das auf einer Technologie sitzt, ist, dass es tonnenweise mehr Arbeit von der Plattform erfordert.

Wen kümmert es, wie viel Arbeit in die Plattform gesteckt wurde? Entwickler wollen nur die neuesten Techniken, die die Lesbarkeit und Produktivität des Codes verbessern. Kein Entwickler möchte alte und veraltete Techniken verwenden, wenn neueres Zeug eine bessere Alternative bietet.

Ich bevorzuge es, zu wissen, was wirklich im Code passiert, und die Kontrolle darüber zu haben, was passiert, als eine magische Syntax zu haben, die nur Overhead hinzufügt.

Das ist Unsinn, ich weiß genau, was mit JSX passiert, es ist eine winzig kleine Schicht, die fast eins zu eins transformiert, aber viele Vorteile bietet. Vernachlässigbarer Aufwand für die Kompilierzeit, wenn Sie mich fragen.

Nur um die Tatsache zu erwähnen, dass JSX für eine React/Javascript-Community großartig ist, weil es für sie funktioniert hat, aber für Dart/Flutter finde ich es ein bisschen übertrieben, JSX hinzuzufügen, nur um Entwickler von React Native anzuziehen.

JSX sollte auch hervorragend für Dart/Flutter funktionieren. Es ist keineswegs ein Overkill. Gibt es einen guten Grund, warum JSX nicht für Dart/Flutter funktionieren würde? Wenn ich es programmieren und veröffentlichen würde, warum wäre es nicht gut für die Dart/Flutter-Entwicklung geeignet?

Nehmen wir das konkrete Beispiel von @xinthink :

Im Moment ist die Syntax etwas ausführlich, ich muss etwas new machen, nur um einen Rand hinzuzufügen: margin: new EdgeInsets.symmetric(horizontal: 4.0) , ich denke, es gibt einen einfacheren Weg.

Wenn Sie links und rechts einen Rand hinzufügen möchten, wie möchten Sie das ausdrücken? Lassen Sie uns insbesondere ein einfaches Beispiel nehmen und sehen, wie es in verschiedenen Syntaxen aussehen würde.

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

Wie würden Sie empfehlen, diese _exakte_ Semantik auszudrücken?

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

Babel.js hat diese nette kleine Website, auf der Sie JSX eingeben können und es in einfaches Javascript konvertiert:
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% 20Welt!%3C%2Fdiv%3E%3B%0A%7D

Ich werde ein Äquivalent für DSX zu Dart machen. Nur ein Proof of Concept, mal sehen, wie lange ich brauche ...

Hier ist das neueste Beispiel von @Hixie in „DSX“, das den Styleguide von Airbnb verwendet und davon ausgeht, dass alle untergeordneten Elemente automatisch child -Eigenschaften zugeordnet werden können.

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

Wenn es darum geht, die Lesbarkeit zu verbessern, gewinnt Future Dart meiner Meinung nach in höchstem Maße.

Sie müssen die Dokumentation überprüfen, um zu wissen, was zu Tags werden kann (vermutlich nur Widget s) oder wie viele untergeordnete Elemente erforderlich/erlaubt sind.

Wenn Sie HTML aus JavaScript ausgeben möchten, ist JSX als Mittelweg sehr sinnvoll. Denn wenn Sie Tags am Ende des Tages wollen, ist React.createElement('div', null, 'foo') viel schlimmer als <div>foo</div> .

Wenn es Ihr Ziel ist, einen Baum von Dart-Objekten aus ... Dart auszugeben, und ein schön formatierter Baum von Dart-Konstruktoren perfekt (wohl besser) lesbar ist, sehe ich keinen Sinn darin, XML zu umgehen. Und ich vermisse diese XMLs nicht, die von Android kommen.

Es ist das, was die Verwendung von XML ermöglicht ... Schauen Sie, es waren 5 Monate mit nur Reden, jetzt unternehme ich etwas dagegen, also geben Sie mir etwas Zeit (ich habe einen Vollzeitjob und kann am Wochenende nur etwa 4 Stunden erübrigen).

Habe gerade diesen Thread gefunden, interessant für beide Seiten. Als React-Entwickler, der an Flutter interessiert ist, gibt es ein paar andere Argumente, die ich nicht erwähnt habe (obwohl ich alle Kommentare nur kurz überflogen habe).

1. Die Deklaration des schließenden Tags verbessert das Verständnis von Kindern und Eigenschaften. UI kann leider tief verschachtelt sein, und ein klares Tag vs. ein unknown ) hilft, Kinder zu klären und zu parsen. Es ermöglicht mir auch, Code zwischen Komponenten zu verschieben und sehr deklarativ zu sehen, wenn etwas fehl am Platz ist (z. B. ein schließendes Tag vor a). Dies ist mit mehreren verschachtelten )'s schwieriger.

2. Meine anfängliche Bauchreaktion auf das Sehen mehrerer verschachtelter Komponenten in Konstruktoren gibt mir Flashbacks zur "Callback Hell" . Es war eine sehr schmerzhafte Ära von JS, die allmählich besser wird. Dahin zurückzukehren fühlt sich ein bisschen wie ein Rückschritt an.

3. Im Zusammenhang mit #2 ist die unglückliche Tatsache, dass wir die Leute davon überzeugen müssen, zu wechseln (oder es zumindest auszuprobieren). Viele Leute verwenden React/React Native und noch mehr verwenden HTML/JS. Das Erstellen eines einfachen und größtenteils syntaktisch vertrauten Tutorials / Leitfadens, das speziell auf einige der Schmerzpunkte von React abzielt, kann für diejenigen, die ein bisschen müde sind, äußerst überzeugend sein.

Einer der Hauptgründe, warum React in der Webentwickler-Community populär wurde, war die Unterstützung von JSX.

Es ist wirklich enttäuschend, „Abwertungen“ für eine so nette Feature-Anfrage zu sehen. Es verbessert die Lesbarkeit und beschleunigt die Akzeptanz.

Ich denke, das ist ein wesentlicher Unterschied zwischen Open JavaScript und Dart. JavaScript ist wirklich Open Source, während eine Anfrage auf Dart so ins Gespräch kommt und Sie letztendlich mit Ablehnungen demotiviert werden.

Schaffen Sie mehr Raum für neue Ideen!

@jayjun Das sieht toll aus! Kann ich es irgendwo versuchen?

@sanketsahusoft Keine Sorge, bald wirst du meine Version ausprobieren können und sie ist sogar noch besser als @jayjun.

Kurzes Update: Vor 2 Wochenenden funktionierte die Benutzeroberfläche hervorragend. Letztes Wochenende funktionierte der Parser vollständig und die Hälfte des Transpilers. Am kommenden Wochenende hoffe ich, es zu beenden, wenn ich den Superbowl vermeide ;)

Ich habe eine dicke Haut und eine maultierartige Sturheit, also bemerke ich diese Abwertungen nicht einmal, aber danke, dass Sie darauf hingewiesen haben.

Carlos.

Würde dies bei dem Problem helfen, den Überblick über schließende Tags zu verlieren?
Idee: Automatisch generierte schließende Tags

Hier ist eine vorgeschlagene Markup-Syntax für das Beispiel von @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 , das Interessante, was Sie getan haben, war, eine dritte Attributmöglichkeit hinzuzufügen, die das Aussehen von Ausdrücken vereinfacht, wenn es sich um ein anderes Tag handelt.
JSX hat:
1 - <tag attrib=""/> oder <tag attrib=''/>
2 - <tag attrib={}/>
Du hast einen anderen vorgeschlagen:
3 - <tag attrib=<anotherTag.../>/>
mit JSX müssen Sie es schreiben als:
<tag attrib={<anotherTag.../>}/>

@cbazza Ja, der dritte Fall ist in Flutter ziemlich häufig, daher ist es sinnvoll, die zusätzliche { -Verschachtelung zu überspringen.

@abarth Ah, aber ich mache die meisten dieser Dinge unnötig, indem ich CSS-ähnliche Stile verwende !!! Der Transpiler erweitert diese CSS-ähnlichen Stile zu geeigneten Flutter-Aufrufen. Jetzt ist die Tagging-Struktur viel sauberer und Stile können einfach aus Designer-Tools wie InVision, Figma, Atomic usw. importiert werden

@cbazza Cool, ich verwende viele Widgets mit Closures wie FutureBuilder . Ich hoffe, Ihr Transpiler kann so etwas erzeugen wie:

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 , Ja, das ist kein Problem. Der Transpiler ist ein einfacher XML-Prozessor und wenn es darum geht, Ausdrücke (alles innerhalb von {}) zu parsen, wird er einfach zu einem Text-Blob, der ihn wörtlich ausschreibt.

@xinthink

Wäre es möglich, eine DSL zu bauen, wie sie das Kotlin-Team für Android-Entwickler gemacht hat?

Scheint, als würden viele Leute Kotlin gerne mit Flutter verwenden. Ehrlich gesagt verstehe ich nicht, warum die Entwickler beschlossen haben, das Rad in Dart neu zu erfinden?

Meiner bescheidenen Meinung nach braucht Flutter JSX nicht. Flutter hätte Kotlin statt Dart wählen sollen. Kotlin ermöglicht es uns, komplexe UI-Logik mit schöner Syntax sofort zu schreiben, hat eine riesige Community, produktionsbereite Tools, kampferprobt in der Android-Entwicklung ...

Sag nur.

Kotlin ist nett, ich bin ein Fan , aber es läuft nicht auf iOS..... eigentlich schon, aber es wurde noch nicht veröffentlicht (Vorabversionsphase im Moment).
Für die UI/UX-Entwicklung bevorzuge ich immer noch JSX anstelle von Anko DSL. Mir gefällt die Tatsache, dass ich deklaratives Markup visuell von imperativem Code trennen und Komponenten ganz einfach mischen und zusammenpassen kann.

Dart, Kotlin und Swift haben alle Gemeinsamkeiten:
https://sethladd.github.io/swift-is-like-kotlin-and-kinda-like-dart/

Ich mag es :

1. Dart ist bekannter, wenn Sie aus Java kommen.
2. Sie können Ihre Dart-Fähigkeiten nutzen und zum Erstellen von Webseiten verwenden - was beim Erstellen von Apps wertvoll ist, Sie können Funktionen im Web erstellen (und sie in einer WebView anzeigen), wo es sinnvoller ist (vielleicht schnelle Admin-Seiten oder Produktlisten, die müssen von Google indexiert werden).
3. Dart wurde von Anfang an entwickelt, um zu Javascript zu kompilieren, von dem ich annehme, dass es später nicht einfach ist, es einer Sprache hinzuzufügen.

Dies sind im Grunde die Gründe, warum ich mich für Dart gegenüber Kotlin / Swift / React entschieden habe.

_Obwohl die Entscheidung, Dart und Swift in Googles neuem Fuchsia OS zu unterstützen, für mich verwirrend ist._

Ich bin mir nicht sicher, ob Dart bekannter ist, wenn Sie aus Java kommen. Ich komme aus Java und habe keine Probleme mit Kotlin oder Swift; im Grunde ist die Typdeklaration umgekehrt, nichts wirklich Neues, da es in Pascal und ActionScript verwendet wurde.

Ja, Sie können Webseiten mit Dart erstellen, aber ich sehe keine große Akzeptanz dafür. Die einzige andere Sprache, die im Web gut abschneidet, ist TypeScript, da sie sich gut in die Top 3 der beliebtesten Web-Frameworks integrieren lässt.

Werfen Sie einen Blick auf die verschiedenen Syntaxen, die für React on the Web verfügbar sind:
https://github.com/Workiva/over_react#fluent -style-component-consumption
Beide Dart-Versionen haben gegen JSX keine Chance !!!

TypeScript wurde entwickelt, um zu Javascript zu kompilieren, und dafür ist es besser als Dart. Es unterstützt auch JSX.
Dart wird von allen Seiten gequetscht. Swift hat Schwung, daher ist es ratsam, es zusammen mit Ihrem Baby auf Fuchsia OS zu unterstützen.

Wie lange noch bis zum Prototyp? Ich würde es gerne benutzen!

Ich habe React eine Zeit lang verwendet und JSX hat meine Produktivität um das Zehnfache gesteigert. Dies ist kein kontroverses Thema: Andere Teams haben zu Recht entschieden, dass dies besser wäre, also warum nicht Flutter? (Rhetorisch: Ich habe den Thread gelesen ... (Facepalm))

Ich arbeite dieses Wochenende daran, aber ich erweitere den Umfang mit neuen Ideen, also hoffe ich, dass ich dieses Wochenende etwas herausbringen kann.

Einige der interessanten Dinge, mit denen ich experimentiere:
1) XML-Namespace für untergeordnete Tags verwenden, damit sie mit dem korrekten benannten Dart-Argument in das übergeordnete Element eingefügt werden.
2) Spread-Operator, um stilähnliche Eigenschaften besser zu organisieren, sodass sie außerhalb von XML in einer Map definiert/gruppiert und dann wie typisches React-Zeug in ein Tag gebracht und verteilt werden können.
3) styleCSS-Eigenschaft, die Flatterstile aus CSS generiert.

(1) & (2) sind generisch und funktionieren daher für alle Dart Flutter-Codes.
(3) ist auf das Flutter-Widget (Container, Text usw.) spezialisiert und ich mache vorerst nur diese 2.

@yuriy-manifold Nur weil etwas für JS funktioniert hat, heißt das nicht, dass es eine gute Idee für Dart ist.
Wenn Sie die obigen Diskussionen gelesen hätten, würden Sie sehen, dass es tatsächlich umstritten ist.
Ich verstehe nicht, warum 2 Sprachen besser sein sollten als eine.

Nur weil etwas für JS funktioniert hat, bedeutet das nicht, dass es eine gute Idee für Dart ist.

JSX ist eine unglaubliche Idee für die UI/UX-Entwicklung in einem reaktiven Framework, unabhängig von der Sprache. Wenn ich mehr Freizeit hätte, würde ich LSX herausbringen, was JSX für Logo ist;)

Ich verstehe nicht, warum 2 Sprachen besser sein sollten als eine.

Sie können iOS mit Objective-C und Swift programmieren (2 Sprachen)
Sie können Android mit Java und Kotlin programmieren (2 Sprachen)
...

Ich habe noch kein Argument für JSX gesehen.
Die obigen Diskussionen enthalten nur Argumente wie "es ist besser", "es erhöht die Produktivität" oder ähnliches, aber kein Argument, warum oder wie es tatsächlich besser wäre als reiner Dart-Code, insbesondere unter Berücksichtigung geplanter Sprachänderungen, die den Unterschied zwischen JSX-ähnlich und verringern würden
reiner Dart-Code noch mehr.

@cbazza

Sie können iOS mit Objective-C und Swift programmieren (2 Sprachen)
Sie können Android mit Java und Kotlin programmieren (2 Sprachen)

Wie hängt das mit der JSX-Diskussion zusammen? Wie kann das als Vorteil angesehen werden?
Sie können Swift unter iOS verwenden, da es der Nachfolger von Objectiv-C ist.
Sie können Kotlin auf Android verwenden, da es als raffinierte Verbesserung von Java gilt.
Das klingt so, als würden Sie argumentieren, dass JSX Dart ersetzen sollte. Das ergibt für mich nicht viel Sinn.

@Zoechi

Wie hängt das mit der JSX-Diskussion zusammen? Wie kann das als Vorteil angesehen werden?
Sie können Swift unter iOS verwenden, da es der Nachfolger von Objectiv-C ist.
Sie können Kotlin auf Android verwenden, da es als raffinierte Verbesserung von Java gilt.
Das klingt so, als würden Sie argumentieren, dass JSX Dart ersetzen sollte. Das ergibt für mich nicht viel Sinn.

Sie haben es tatsächlich gesagt (JSX ist eine raffinierte Verbesserung gegenüber dem aktuellen Weg), sind aber zu der falschen Schlussfolgerung gekommen (JSX soll Dart ersetzen).

@cbazza das ist nur mehr vom Gleichen

Was ist der eigentliche Vorteil gegenüber normalem Dart?

"JSX ist eine raffinierte Verbesserung" ist einfach nicht überzeugend und kein Argument.
Es ist nur eine persönliche Meinung ohne (wieder) Argumente, um sie zu untermauern,
ähnlich wie bei anderen Pro-JSX-Argumenten oben.

Sie können nicht erwarten, dass jemand Ihre Vorschläge berücksichtigt, wenn Sie nicht bereit sind, gute Argumente zu liefern.

Das Hinzufügen von etwas wie JSX zu Dart verursacht eine Menge Arbeit und Komplexität in den Flutter-Tools und der IDE. Sie müssen die richtigen Argumente liefern, damit andere es überhaupt in Erwägung ziehen, es sich anzusehen.

@zoechi klingt wie ein kaputter Rekord, der nach „guten“ Argumenten fragt, es wurden schon viele gegeben, aber Sie haben es einfach nicht verstanden; was ok ist, 'jedem das Seine'.

Das Hinzufügen von etwas wie JSX zu Dart verursacht eine Menge Arbeit und Komplexität in den Flutter-Tools und der IDE. Sie müssen die richtigen Argumente liefern, damit andere es überhaupt in Erwägung ziehen, es sich anzusehen.

Nicht wirklich, meine Arbeit ist fast fertig und es hat mich sehr wenig Zeit gekostet, wenn man bedenkt, dass ich nur am Wochenende daran gearbeitet habe.

Auch hier ist DSX nur eine raffinierte Verbesserung, die die Leute verwenden oder nicht verwenden können, da sie die derzeitige Vorgehensweise nicht ändert, sondern nur eine Alternative bietet, mit der andere (React-Entwickler) sofort vertraut sein werden.

@cbazza

viel wurde gegeben

nicht wirklich. Nur allgemeine Behauptungen, die wahr sein können oder nicht.
Es wurden keine zusätzlichen Details bereitgestellt, die es anderen ermöglichen würden, dies zu überprüfen.

Nicht wirklich, meine Arbeit ist fast fertig

Toll. Dann braucht das Flutter-Team nichts zu tun und das Thema kann geschlossen werden ;p
Beinhaltet dies Unterstützung für die automatische Vervollständigung und Syntaxprüfungen in allen von Flutter unterstützten IDEs?

Toll. Dann braucht das Flutter-Team nichts zu tun und das Thema kann geschlossen werden ;p

;)

Beinhaltet dies Unterstützung für die automatische Vervollständigung und Syntaxprüfungen in allen von Flutter unterstützten IDEs?

Die meisten IDEs unterstützen bereits XML und JSX, daher wäre es für sie nicht schwer, meine kleinen Ergänzungen hinzuzufügen.

Ich frage mich, ob die JSX-Syntax in Angular Dart mehr geschätzt wird? Es scheint eher eine Situation zu sein, an die Sie gewöhnt sind, als eine "bessere". Die JSX-Syntax fühlt sich für Webentwickler wahrscheinlich natürlicher an.

Ich weiß, dass sich das Programmieren für mich unangenehm anfühlt, selbst wenn ich nur einen Tag lang verschiedene Code-Hervorhebungsfarben verwende.

https://blog.dantup.com/2014/08/du-hast-ruiniert-html/

Ja, Angular-Leute werden sich mit JSX sehr wohl fühlen, aber auch React Native-Entwickler, und dies ist für die mobile Entwicklung. JSX wird sicherlich nicht von aktuellen Flutter-Entwicklern übernommen, aber diese zweite Alternative wird neue Entwickler für Flutter gewinnen, und das ist sicher.

Der obige Artikel hat es so falsch verstanden, React ohne JSX ist im Grunde nicht existent und alle reaktiven Web-Frameworks erlauben das Mischen von Markup und Programmierung auf ihrer DSL.

Die Zeit ist gekommen...
Ich freue mich sehr, den Online-DSX-Transpiler ankündigen zu können
https://spark-heroku-dsx.herokuapp.com/index.html

Gute Arbeit mit dem Transpiler cbazza
Eine Sache, die meiner Meinung nach mit JSX einfacher zu verfolgen ist, sind die schließenden Tags. Die Idee, die ich bereits erwähnt habe:
Idee: Automatisch generierte schließende Tags

In Ihrem ersten Beispiel würde der Flattercode von (entfernt das optionale neue in der Zukunft Dart) geben:

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

@cbazza Ich schätze deine Arbeit für die Community und die Leute, die UIs auf diese Weise bauen wollen, aber ich hoffe wirklich, dass ich nie gezwungen bin, so etwas in Flutter zu verwenden :-(((

Als Neuling bei Flutter, aber ziemlich vertraut mit React, sind mir ein paar Dinge aufgefallen:

• Das Zustandsverwaltungsmodell ist ziemlich gleich
• Der virtuelle Renderbaum für Widgets/Komponenten ist ziemlich gleich
• Da ich das Status- und Komponentenmodell kenne, fühle ich mich im Grunde bereit, jetzt eine App zu schreiben, mit Ausnahme einiger Dart-Spezifika und Plattform-APIs, aber ...
• Die Stilsprache ist ein Stolperstein. Ich beziehe mich auf https://flutter.io/web-analogs/ , aber es ist nicht einfach herauszufinden, welche Importe erforderlich sind, damit die Dinge funktionieren (EdgeInset? Farbe?) oder wann ich Primitive anstelle von Klasseninstanzen verwenden sollte.
• Der CSS-Parser aus dem DSX-Konverter von @cbazza ist wirklich nützlich, um Layout-Äquivalente im Flutter-Modell herauszufinden.

Bezüglich JSX:

• Ich denke nicht, dass es notwendig ist, eine neue JSX-Syntax zu erfinden, um Flutter-Muster zu unterstützen. Einige der Syntaxfehler in diesem Thread könnten mit einigen der neueren Reaktionsmuster wie Komponenten höherer Ordnung (Funktionen, die Komponentenklassen erstellen) und Requisiten (Komponenten, die Funktionen als Argumente verwenden; die Funktionen geben Elemente zurück) gelöst werden. Beispielsweise könnte der Name "untergeordnete Slots" in JSX in etwa so übersetzt werden:

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

• Das beste Argument gegen JSX, das ich gesehen habe, war, dass Dart Argumente genannt hat.
• Warum ist es für ein Element wichtig zu wissen, ob es mehrere Kinder oder ein Kind hat? Vielleicht könnte ein "Fragment" -Konstrukt diese API eindeutig machen.

Als Flutter-Neuling mit etwas Erfahrung mit Angular, React usw. denke ich immer noch, dass der reguläre Dart-Weg und mehr im Dart 2.0 besser ist als dieser DSX. Es macht einfach mehr Sinn als einige XML- und CSS-artige Parameter. 🤷‍♂️

@cbazza Ihr zweites Demo-Beispiel hat 466 Zeichen im Vergleich zu Darts 391 (beide ohne Leerzeichen). Für mich sieht es optisch aufgebläht aus. Ich müsste seine Semantik lernen, was ich mit normalem Dart-Code nicht muss. Und ich habe keine Ahnung, wie man allgemeine Programmierparadigmen damit verwendet (if, forEach usw.).

Wenn ich die Wahl hätte, würde ich beim jetzigen Modell bleiben.

Jeder gibt nur seine eigene subjektive Meinung zum Vergleich beider Syntaxen ab, aber wir müssen uns auf eine Tatsache einigen: Es ist ein sehr kontroverses Feature. Es gibt Liebe und Hass, aber die meisten Meinungen über die Nützlichkeit von JSX gegenüber einfachem Dart gehen auseinander.

Auf jeden Fall halte ich es für völlig unvernünftig, das Flutter-Team zu bitten, sich zu verpflichten, dieses Feature vor der Veröffentlichung von 1.0 zu unterstützen. Während die derzeitige Art der Erstellung von Benutzeroberflächen nicht für alle großartig erscheint, funktioniert sie (und sie funktioniert in einigen Meinungen großartig).

Wenn die Leute jetzt wirklich eine JSX-ähnliche Syntax wollen, scheint eine von der Community betriebene Anstrengung der richtige Weg zu sein. Und es würde helfen, den Fall zu vertreten (oder nicht), wenn das Flutter-Team dies in der Version nach 1.0 in Betracht zieht.

Persönlich stimme ich dem folgenden Argument stark zu: Es liegt nicht daran, dass JSX für React funktioniert (wo Sie die Benutzeroberfläche bereits mit einer Auszeichnungssprache erstellen), dass es automatisch für Flutter funktioniert.

@tehfailsafe

Die gute Nachricht ist, dass selbst wenn dies vom Flutter-Team übernommen wurde (was wahrscheinlich nicht auf diesem Thread basiert), niemand gezwungen wäre, es zu verwenden. Es ist eine OPTION. Ich verstehe nicht, warum es so emotional aufgeladen ist, dass manche Leute gerne Code mit einer Syntax schreiben, die Sie nicht mögen ...

Es ist mir egal, was andere Leute mögen oder nicht mögen. Aber ich interessiere mich für Funktionen, die mir helfen, mit meiner Anwendung voranzukommen. Die Ressourcen sind begrenzt, und ich hätte lieber einen richtigen Video-/Stream-Player, native Kinderansichten und ein Vektorgrafikformat.

Zum Beispiel können Sie jetzt in React und React Native Ihre gesamte Anwendung ohne JSX schreiben, es ist nur eine Option. So sieht React ohne JSX aus:
[...]
Es ist viel chaotischer als die JSX-Version und fast niemand verwendet es. Das ist wahrscheinlich der Grund, warum einige von uns, die von React kommen, die Möglichkeit schätzen würden, es nicht noch einmal in diesem Stil machen zu müssen.

Das liegt daran, dass das Web nicht für ein solches System entwickelt wurde. Wenn Sie eine statische Auszeichnungssprache wie HTML haben und diese "dynamisieren" möchten, müssen Sie ein System erfinden, das darauf aufbauend arbeiten muss. Am Ende erhalten Sie ein Konstrukt, das durch die zugrunde liegende Plattform eingeschränkt wird.
(siehe: https://gbracha.blogspot.de/2014/09/a-domain-of-shadows.html)

Flutter hingegen hat keine Auszeichnungssprache. Ich sehe noch keinen Grund, Ressourcen in etwas zu investieren, das weniger dynamisch und weniger ausdrucksstark ist.

Ich würde gerne wissen, ob Leute, die damit nicht einverstanden sind, React mit und ohne JSX verwendet haben. Ich ermutige jeden, es zu versuchen, damit diese Diskussion weniger theoretisch wäre. Nach der anfänglichen flachen Lernkurve wird es sehr natürlich (und es geht nicht nur um die Anzahl der Zeichen, denn die schließenden Tags erleichtern das Lesen). Es ist nicht anders als irgendetwas Neues zu lernen, wie Flutter, was auf lange Sicht die Produktivität steigert. Und ich stimme zu, dass es nicht jedermanns Sache ist, weshalb es optional wäre.
Ich denke, es ist wichtig, im Hinterkopf zu behalten, dass wir das Beste füreinander im Sinn haben – es einfacher zu machen, Dinge zu bauen. Ich denke, dieser Transpiler würde helfen, und es wäre einfacher zu übernehmen, wenn er offizielle Unterstützung hätte.

Auch danke @cbazza :)

@yuriy-Verteiler

Ich glaube nicht, dass hier jemand daran zweifelt, dass JSX React eine Verbesserung gegenüber dem klassischen React ist. Aber wie gesagt, diese Lösung wurde aufgrund von Problemen im Zusammenhang mit Eigenschaften der zugrunde liegenden Plattform erstellt. Flutter hat diese Eigenschaften nicht.

Die Frage lautet nicht: Ist JSX hilfreich für React? Die Frage ist: "Ist so etwas wie JSX hilfreich für Flutter?".

Ich denke, die Antwort ist nein.

Es gibt noch ein paar andere Dinge zu beachten:

• Die Trennung der Layoutspezifikation vom App-Code kann den Code zukunftssicherer machen; zB würde dieser Dart-2-Syntaxvorschlag build -Methoden nicht beeinflussen, wenn sie gemäß einem aktualisierbaren Pragma in Dart-Code aus einem agnostischen Format wie JSX umgewandelt würden.
• Das Definieren des Layouts als Markup ermöglicht es, die Render-Engine von der (zustandsbehafteten/virtualisierten) Widget-Engine ala Reacts Beziehung zu ReactDOM und React Native zu trennen, wodurch es möglicherweise einfacher wird, Widgets auf neue Plattformen zu portieren.
• Das Definieren des Markup-Formats erleichtert das Portieren vorhandener Layouts zu Flutter, beispielsweise aus Sketch oder anderen Design-Tools

Gute Arbeit mit dem Transpiler cbazza

@Rockvole , danke.

Ich schätze deine Arbeit für die Community und die Leute, die UIs auf diese Weise bauen wollen, aber ich hoffe wirklich, dass ich nie gezwungen bin, so etwas in Flutter zu verwenden :-(((

@zoechi , danke. Ja, es ist nur eine weitere Option für Leute, die JSX lieben. Wenn das nicht dein Ding ist, mach weiter so, wie du es gerade tust, daran ändert sich nichts.

Ich denke nicht, dass es notwendig ist, eine neue JSX-Syntax zu erfinden, um Flutter-Muster zu unterstützen.

@alexkrolick , ja, Sie können Requisiten für die benannten Parameter verwenden, aber Sie können nichts gegen die Positionsparameter tun. Der Schlüssel war, dass ich nichts im Transpiler fest codieren wollte, damit es für alles funktioniert.

Als Flutter-Neuling mit etwas Erfahrung mit Angular, React usw. denke ich immer noch, dass der normale Dart-Weg und mehr im Dart 2.0 besser ist als dieser DSX. Es macht einfach mehr Sinn als einige XML- und CSS-artige Parameter.

@tenhobi , großartige Verwendung, denn offensichtlich ist DSX nicht jedermanns Sache.

Wenn ich die Wahl hätte, würde ich beim jetzigen Modell bleiben.

@b-strauss, dies ist kein Ersatz, sondern eine Option für Leute, die JSX mögen.

Es gibt Liebe und Hass, aber die meisten Meinungen über die Nützlichkeit von JSX gegenüber einfachem Dart gehen auseinander.

@lukaspili , DSX ist für React Native-Leute, die JSX lieben, wenn Sie seine Vorteile nicht sehen, verwenden Sie es nicht. Es ist nicht DSX gegen einfachen Dart. Es ist DSX vs. JSX, je näher die 2 sind, desto besser.

Die gute Nachricht ist, dass selbst wenn dies vom Flutter-Team übernommen wurde (was wahrscheinlich nicht auf diesem Thread basiert), niemand gezwungen wäre, es zu verwenden. Es ist eine OPTION. Ich verstehe nicht, warum es so emotional aufgeladen ist, dass manche Leute gerne Code mit einer Syntax schreiben, die Sie nicht mögen ...

@tehfailsafe , danke fürs Zuhören!!! Sie treffen den Nagel auf den Kopf, warum so ein großer Widerstand gegen etwas besteht, das die React-Indianer wirklich glücklich machen wird.

Es ist mir egal, was andere Leute mögen oder nicht mögen. Aber ich interessiere mich für Funktionen, die mir helfen, mit meiner Anwendung voranzukommen. Die Ressourcen sind begrenzt, und ich hätte lieber einen richtigen Video-/Stream-Player, native Kinderansichten und ein Vektorgrafikformat.

@b-strauss, sobald React Native-Fans zu Flutter wechseln, wird es Tonnen von Leuten geben, die bei diesen anderen notwendigen Dingen helfen. Priorität 1 ist es, React Natives Mind Share zu stehlen und es den React Natives so einfach wie möglich zu machen, umzuziehen.

Flutter hingegen hat keine Auszeichnungssprache. Ich sehe noch keinen Grund, Ressourcen in etwas zu investieren, das weniger dynamisch und weniger ausdrucksstark ist.

@b-strauss, inwiefern ist DSX „weniger dynamisch“ und „weniger ausdrucksstark“ als einfaches Dart? DSX ist Dart, hast du den Transpiler nicht ausprobiert?

@yuriy-manifold, danke.

Die Frage lautet nicht: Ist JSX hilfreich für React? Die Frage ist: "Ist so etwas wie JSX hilfreich für Flutter?".

@b-strauss, natürlich ist es das. Es ist nicht hilfreich für aktuelle Flutter-Entwickler, aber es ist sehr hilfreich für Designer, die CSS aus ihren Tools ausgeben können, es ist sehr hilfreich für Leute, die sich mit der React Native-Plattform auskennen.

@alexkrolick , sehr gute Beobachtungen.

@cbazza

Dies ist kein Ersatz, sondern eine Option für Leute, die JSX mögen.

Ich verstehe das ... Es würde mich nicht auf diese Weise betreffen, aber wie ich bereits sagte, fehlen im Moment Funktionen, die ich brauche, um eine Flatter-App zu erstellen.

Sobald React Native-Fans zu Flutter wechseln, wird es Unmengen von Leuten geben, die bei diesen anderen benötigten Dingen helfen. Priorität 1 ist es, React Natives Mind Share zu stehlen und es den React Natives so einfach wie möglich zu machen, umzuziehen.

Sie schlagen also vor, dass das Flutter-Team Funktionen für etwas zurückhalten sollte, das fragwürdig ist und möglicherweise einen Bruchteil einer bestimmten Untergruppe von Webentwicklern anzieht oder nicht?

Inwiefern ist DSX „weniger dynamisch“ und „weniger ausdrucksstark“ als einfaches Dart? DSX ist Dart, hast du den Transpiler nicht ausprobiert?

Jede DSL ist per Definition weniger aussagekräftig als eine GPL. Wie verstecke ich mit DSX ein Widget bedingt? Wie iteriere ich über eine Sammlung und bilde jedes Element einem Widget zu? Wie verwende ich einen Schalter? Sie müssen jetzt Syntax und Semantik für Konstrukte erfinden, die Sie bereits in Ihrer GPL haben. Warum also überhaupt DSL erfinden?

natürlich ist es das. Es ist nicht hilfreich für aktuelle Flutter-Entwickler, aber es ist sehr hilfreich für Designer, die CSS aus ihren Tools ausgeben können, es ist sehr hilfreich für Leute, die sich mit der React Native-Plattform auskennen.

Das war nicht die Frage... Welche Probleme würde ein DSL lösen, die Sie gerade nicht lösen können? Du sagst immer, es ist besser, warum ist es besser? Ich habe keinen Zweifel, dass DSX einige JSX-Leute anziehen würde. Ich weiß, dass die Leute keine Dinge mögen, die anders sind. Und Vertrautheit scheint das einzige Argument zu sein. Warum also nicht CSS verwenden?
Warum nicht JavaScript verwenden? Mehr Leute wissen, wie man diese benutzt als Dart.

Wenn Sie Ihr System basierend auf etwas anderem entwerfen, nur um vertraut zu sein, sind Sie nicht wirklich innovativ.

@b-strauss Um es klar zu sagen, JSX kompiliert zu Funktionsaufrufen (in React-Aufrufen an createElement(ComponentClass) , in Dart sollten es Konstruktoren sein).

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

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

Die einzigen Konstrukte sind die Transformationen zwischen den Elementnamen+Attributen und den Funktionsaufrufen+Argumenten sowie Escape-Ausdrücken ( {...} ).

• Wie verstecke ich mit DSX ein Widget bedingt?

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

• Wie iteriere ich über eine Sammlung und bilde jedes Element einem Widget zu?

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

• Wie verwende ich einen Schalter?
  Soweit ich weiß, können Sie in Dart wie in JS keinen Schalter inline verwenden, da es sich nicht um einen Ausdruck handelt. Wenn Sie sich außerhalb des Widget-Baums befinden, können Sie ganz normal einen Schalter verwenden.

Sie schlagen also vor, dass das Flutter-Team Funktionen für etwas zurückhalten sollte, das fragwürdig ist und möglicherweise einen Bruchteil einer bestimmten Untergruppe von Webentwicklern anzieht oder nicht?

@b-strauss, React Native ist keine Webentwicklung, sondern die plattformübergreifende mobile Entwicklung, die der Hauptkonkurrent von Flutter ist. und ja, JSX ist wie eine Lichtquelle, es wird viele React-Native-Entwickler anziehen. Ich habe im August 2017 nach dieser Funktion gefragt, zu viel Gerede zu wenig Aktion.

Jede DSL ist per Definition weniger aussagekräftig als eine GPL. Wie verstecke ich mit DSX ein Widget bedingt? Wie iteriere ich über eine Sammlung und bilde jedes Element einem Widget zu? Wie verwende ich einen Schalter? Sie müssen jetzt Syntax und Semantik für Konstrukte erfinden, die Sie bereits in Ihrer GPL haben. Warum also überhaupt DSL erfinden?

Du liegst völlig falsch. Die gute Nachricht ist, dass ich mich auch einmal geirrt habe. Die meisten (aber nicht alle) DSLs versuchen, Programmierkonstrukte in Markup nachzubilden (und das ist nicht sehr leistungsfähig), JSX bringt Markup in die Programmierung (unter voller Nutzung der Hostsprache). Der Unterschied ist transformatorisch. Die Antwort auf alle Ihre Fragen ist im Grunde, verwenden Sie es so, wie Sie es in Dart tun, weil es Dart ist. Alles zwischen '{}' ist Dart-Code mit Ausnahme des Spread-Operators. Es sind alles Dart-Ausdrücke, aber Sie können auch anonyme Funktionen verwenden, die einen Ausdruck zurückgeben. Wie Sie im Transpiler sehen, ist ein Tag (\) ist nur ein neues Widget (neuer Text()).

Welche Probleme würde ein DSL lösen, die Sie derzeit nicht lösen können?

Warum Dart verwenden, wenn Sie Nullen und Einsen verwenden können, ist das nicht alles, was notwendig ist, um jedes Computerproblem zu lösen?

Du sagst immer, es ist besser, warum ist es besser?

Ich habe meine Gründe vorher angegeben und werde sie hier nicht wiederholen. JSX-Leute werden mir zustimmen, aber „jedem das Seine“.

Ich habe keinen Zweifel, dass DSX einige JSX-Leute anziehen würde. Ich weiß, dass die Leute keine Dinge mögen, die anders sind. Und Vertrautheit scheint das einzige Argument zu sein. Warum also nicht CSS verwenden?
Warum nicht JavaScript verwenden? Mehr Leute wissen, wie man diese benutzt als Dart.

Ja, die Verwendung von CSS ist sinnvoll, um den Designer-Entwickler-Workflow zu vereinfachen. DSX unterstützt das. Der Vorteil von Dart gegenüber Javascript ist die Ausführungsgeschwindigkeit (Performance).

Wenn Sie Ihr System basierend auf etwas anderem entwerfen, nur um vertraut zu sein, sind Sie nicht wirklich innovativ.

Sie sind so voller falscher Vorurteile, die Sie höchstwahrscheinlich daran hindern, Ihr volles Potenzial auszuschöpfen. Öffnen Sie Ihren Geist, probieren Sie verschiedene Dinge aus.

@alexkrolick , danke für die Details.

@cbazza

Sie sind so voller falscher Vorurteile, die Sie höchstwahrscheinlich daran hindern, Ihr volles Potenzial auszuschöpfen. Öffnen Sie Ihren Geist, probieren Sie verschiedene Dinge aus.

Ich werde mich jetzt von dieser Ausgabe abmelden. Bitte erwähne mich nie wieder hier oder sonstwo, thx.

@b-strauss

Tut mir leid, Mann, ich wollte deine Gefühle nicht verletzen ... Ich habe nur versucht, dich sanft zu führen, während ich versuchte, mit meiner eigenen Frustration umzugehen. Wir sind schließlich alle Menschen.

@cbazza Kannst du mir bitte eine E-Mail schicken? [email protected]

Ich habe diesen Vorschlag bereits im alten Thread gemacht, aber ich denke immer noch, dass das ein wichtiger Punkt ist

IMHO hat das Entfernen der Notwendigkeit, new/const zu verwenden, bereits sehr geholfen. Ich habe echte Schwierigkeiten mit der Art und Weise, wie das Dart-Format die Bäume formatiert. es betont die Baumstruktur meiner Meinung nach nicht genug im Vergleich zu:

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

Ich stimme zu, um Flattern zu vereinfachen, das keine JSX-ähnliche Syntax verwenden möchte, und ich unterstütze auch das Konzept der Aufteilung in mehrere Widgets, aber jetzt habe ich das Gefühl, dass die MVC-Ära in jquery zurück ist. Ein solches Szenario, dass es ein einfaches Widget gab, mit Padding, Border und Center-Layout dafür später, viele "} "-Symbole beeinträchtigen die Lesbarkeit ernsthaft. Es ist jedoch ein integrales Widget, ich möchte es nicht aufteilen, was auch immer nützlich ist Lösung? Obwohl mein Englisch schlecht ist, bemühe ich mich, meine Gedanken auszudrücken.

Herr, hilf uns allen.

Ok, das führt nirgendwohin. Es sieht nicht so aus, als würde bald jemand die Seite wechseln. Hier müssen wir unbedingt einen Kompromiss finden. Natürlich gibt es zwischen „Pro-DSX“ und „Anti-DSX“ keinen wirklich zufriedenstellenden Kompromiss, was eine frustrierende Erkenntnis ist. Könnten wir möglicherweise unsere Positionen neu formulieren, damit sie kompatibler sind?

@naiveaiguy "sie" können ihren DSX haben.
Wenn das Flutter-Team es nicht implementiert, kann es sich um eine Open-Source-Initiative handeln.
Das bedeutet nicht, dass der reine Dart-Ansatz, wie er jetzt ist, nicht mehr funktionieren wird.
Beide Welten können koexistieren.

Ich stimme @zoechi so sehr zu, dass sie koexistieren können ... das war's und ich dachte, das wäre im alten Thread geklärt worden

@lrhn

Bitte alle, seid höflich und konstruktiv. Wir diskutieren hier über Stil, etwas sehr Subjektives, also egal wie sehr jeder seine eigenen Vorlieben mag, es ist unwahrscheinlich, dass sie denen aller anderen von Natur aus überlegen sind. Listen Sie die Vor- und Nachteile auf, die Sie bei bestehenden und vorgeschlagenen Syntaxen sehen, aber denken Sie daran, dass nicht jeder das so sieht, und das ist völlig in Ordnung.

Bravo, das ist es absolut.

In React kannst du es auf 4 Arten tun (und ich habe erst heute von den anderen 2 Möglichkeiten erfahren !!!)

(1) Sie können JSX verwenden (was mir gefällt)
https://reactjs.org/docs/introducing-jsx.html

(2) Sie können den ursprünglichen Weg verwenden (der Flutter ähnelt)
https://reactjs.org/docs/react-without-jsx.html

Am Ende des obigen Links werden sogar 2 vielversprechende Community-Projekte erwähnt

(3) Hyperscript-Syntax für React.js-Markup
https://github.com/mlmorg/react-hyperscript

(4) Knappe Syntax für Hyperskript.
https://github.com/ohanhi/hyperscript-helpers

Alternativen zu haben ist eine gute Sache, vorbei sind die Zeiten, in denen man einen Ford in jeder beliebigen Farbe bekommen konnte, solange es schwarz war :)

@naiveaiguy warum ist es für dich ein Problem, wenn es den aktuellen Ansatz und DSX gibt?
(das leite ich aus deinen Downvotes ab)

@naiveaiguy "sie" können ihren DSX haben.
Wenn das Flutter-Team es nicht implementiert, kann es sich um eine Open-Source-Initiative handeln.
Das bedeutet nicht, dass der reine Dart-Ansatz, wie er jetzt ist, nicht mehr funktionieren wird.
Beide Welten können koexistieren.

Dem stimme ich voll und ganz zu. Obwohl ich denke, dass es eher eine Pluggable- als eine Out-of-the-Box-Lösung sein sollte. Einen Standard zu haben, der funktioniert, aber die Erfahrung mit zusätzlichen Dingen anpassen zu können, ist ein großartiges Paradigma. Auf diese Weise kann sich das Flutter-Team auf (meiner Meinung nach) relevantere Themen konzentrieren, die Community kann mit verschiedenen Tools/Lösungen experimentieren und dann können wir eine Diskussion mit mehr Daten und Erfahrungen mit DSX oder anderen Alternativen zum aktuellen führen Meta.

Alternativen zu haben ist eine gute Sache, vorbei sind die Zeiten, in denen Sie einen Ford in jeder gewünschten Farbe bekommen konnten
Gefällt mir solange es schwarz ist :)

Stimmt das. Ich denke jedoch, wir sind uns alle einig, dass wir nicht wollen, dass Dart/Flutter zu einem weiteren JS/Web-Frontend-Ökosystem wird. Flutter ist noch nicht einmal aus der Beta-Phase heraus und wir möchten bereits, dass es zwei Standards für etwas Subjektives hat.

In React kannst du es auf 4 Arten tun (und ich habe erst heute von den anderen 2 Möglichkeiten erfahren !!!)

Die meisten sind Community-getrieben, obwohl React sich auf sie bezieht. Gut auf halbem Weg. Jetzt werden nur 2 davon offiziell unterstützt: der React.createElement und der JSX-Weg, der ein Wrapper über dem anderen ist. Der Wert von JSX ist in diesem Zusammenhang berüchtigt, aber hier ist es nicht so klar. Können wir uns vor diesem Hintergrund auf halbem Weg treffen, indem wir nur einen offiziellen Standard haben und die Dokumente, wann immer relevant, auf DSX verweisen?

Ich glaube, das Flutter-Team sollte sich auf die fehlenden Funktionen konzentrieren, die Entwickler wirklich daran hindern, Apps zu erstellen. Ich kann Flutter meinen Managern nicht empfehlen, wenn wir nicht einmal Kartenunterstützung hinzufügen können und die Entwicklung einer Kamerafunktion zwei Wochen dauert.

Denken Sie daran, ich werde die Tür zu DSX nicht für immer schließen. Vielleicht wird es die Lösung für die Erstellung von Benutzeroberflächen, aber wir brauchen die Community, die damit experimentiert, um diese Entscheidung zu treffen.

@zoechi Persönlich glaube ich nicht, dass die beiden Ideen im aktuellen Zustand von Flutter koexistieren können - wir sollten wirklich nicht so früh zu einer Spaltung dieser Art ermutigen -, aber an diesem Punkt sieht es nach dem einzigen Kompromiss aus.

@naiveaiguy

Ich persönlich glaube nicht, dass die beiden Ideen im aktuellen Stand von Flutter koexistieren können – wir sollten eine Trennung dieser Art so früh wirklich nicht fördern

Könnten Sie genauer sagen, warum sie nicht koexistieren können? (angesichts der Tatsache, dass DSX nur syntaktischer Zucker ist; oder wie @emalamela sagt "nur ein Wrapper der aktuellen Art").

Warum ist es auch zu früh, eine andere Syntax für genau dasselbe bereitzustellen? Ich frage mich im Grunde, warum es notwendig ist, dies zu verzögern, was in der Zukunft anders wäre, was jetzt noch nicht da ist?

@emalamela

Ich denke jedoch, wir sind uns alle einig, dass wir nicht wollen, dass Dart/Flutter zu einem weiteren JS/Web-Frontend-Ökosystem wird.

Ich persönlich setze dem, was Leute mit Dart/Flutter machen können, eher keine Grenzen. Lass den Markt/die Community entscheiden. Wenn das, was geschaffen wird, keinen Mehrwert bringt, werden die Leute es nicht verwenden und es wird sterben. Wenn es populär wird, liegt es daran, dass die Community es nützlich fand und schätzte. Sie müssen jetzt keine Gewinner und Verlierer auswählen.

Das einzige, was mich davon abhält, Flutter auszuprobieren, ist die Tatsache, dass sie sich entschieden haben, JSX nicht zu verwenden.
IMHO JSX ist die beste Wahl, um die Komponentenhierarchie auszudrücken

Ich habe von Flutter gehört, wollte es ausprobieren, habe sofort aufgehört, selbst wenn ich bedenke, dass ich die Syntax gesehen habe, was schade ist, denn die Chancen stehen gut, dass dies ein großartiges Stück Technik ist. Produkte zu bauen.

Ich habe die React/React Native-Entwicklung in den letzten 2,5 Jahren durchgeführt, und es ist viel verlangt, die Produktivität zu opfern, die die JSX-Syntax bietet, wenn es um die Beschreibung der Benutzeroberfläche geht. Ich würde ernsthaft in Betracht ziehen, die Zeit zu verbringen, um alles über Flutter zu lernen und zu untersuchen, ob es sich lohnt, zu wechseln, wenn eine solche Funktion standardmäßig unterstützt wird.

Ich kann mir nicht einmal vorstellen, wie viele potenzielle Adoptierende/Benutzer/Entwickler Flutter dadurch verliert, ich werde in den nächsten Monaten wiederkommen.

Ich kann mir nicht einmal vorstellen, wie viele potenzielle Adoptierende/Benutzer/Entwickler Flutter dadurch verliert, ich werde in den nächsten Monaten wiederkommen.

Ja, 44 Mio fanden es sogar wichtig genug, um zuzustimmen :D

Ja, 44 fand es sogar wichtig genug, um zuzustimmen :D

Bei der Sortierung nach „Upvote“ wird diese Feature-Anfrage jedoch auf Platz 7 der Liste der 3131 geöffneten Tickets aufgeführt.

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

@cbazza Ich möchte nicht gegen das Feature argumentieren, aber Kommentare wie "Wenn Sie x nicht tun, wird schrecklich y passieren" sind einfach lächerlich.

Ich habe die React/React Native-Entwicklung in den letzten 2,5 Jahren durchgeführt, und es ist viel verlangt, die Produktivitätshebel zu opfern, die die JSX-Syntax bietet, wenn es um die Beschreibung der Benutzeroberfläche geht. Ich würde ernsthaft in Betracht ziehen, die Zeit zu verbringen, um alles über Flutter zu lernen und zu untersuchen, ob es sich lohnt, zu wechseln, wenn eine solche Funktion standardmäßig unterstützt wird.

@sonaye

Da Sie die Produktivität erwähnt haben, können Sie ein Beispiel nennen, das den Produktivitätsverlust durch die Verwendung von Flutter's Pattern anstelle von JSX deutlich macht? Das Beispiel sollte auf der Grundlage erstellt werden, dass Sie genügend JS und Dart kennen, um das Beispiel codieren zu können. Ich glaube, wenn wir das nicht berücksichtigen, vergleichen wir auch Programmiersprachen, was nicht dieselbe Diskussion ist.

Bei der Sortierung nach „Upvote“ wird diese Feature-Anfrage jedoch auf Platz 7 der Liste der 3131 geöffneten Tickets aufgeführt.

@cbazza

Es ist auch das am meisten herabgestufte. Es ist ziemlich umstritten.

@emalamela ,

Es ist auch das am meisten herabgestufte. Es ist ziemlich umstritten.

Da diese Funktionsanfrage eine Alternative zum aktuellen Weg ist und den aktuellen Weg nicht ändert, sollte es überhaupt keine Kontroversen geben; Wenn Sie JSX/DSX nicht mögen, fahren Sie mit der Programmierung fort, wie Sie es heute tun.

Die sogenannte Kontroverse existiert nur, weil das Flutter-Team daran arbeiten muss, dass die Community DSX richtig macht. Wenn die Flutter-Tools (Compiler, Analysator, IDE-Unterstützung usw.) die Vorverarbeitung mit Quellkarten unterstützen würden, wäre DSX schon vor langer Zeit fertig gewesen, und höchstwahrscheinlich wären auch andere Sprachinnovationen/Ideen von Drittentwicklern passiert.

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

Wird:

<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 Das Argument für und gegen JSX wurde durch Diskussion erschöpft, es gibt viel Material, das Sie nachschlagen können. Ich teile nur meine persönliche Meinung.

Erstens, Lesbarkeit des Codes. Ich kann mir sofort eine klare Vorstellung von der Struktur der Benutzeroberfläche in JSX machen (dauert Sekunden), das mentale Modal ist sehr visuell. Zweitens die Benutzerfreundlichkeit. Ich würde argumentieren, dass JSX auch ohne Kenntnisse von JS/Dart oder irgendetwas über die zugrunde liegende API verwendet werden kann. Dies ist sehr geeignet für jemanden, der gerade Programmieren lernt, oder für jemanden, der Teil meines Teams ist. Designer können jetzt die Benutzeroberfläche codieren .

Die Beschreibung der Anwendung ist vollständig deklarativ (nicht nur ausdrucksstark). Wenn Sie an einem großen Projekt mit Hunderten von Komponenten arbeiten, macht diese Art der Beschreibung der Benutzeroberfläche einen großen Unterschied (Sie müssen es ausprobieren, um es wirklich zu schätzen). Ich mochte JSX auch nicht, als ich es zum ersten Mal sah, sobald ich es benutzte, fühlte es sich einfach richtig an, so möchte ich die Benutzeroberfläche von nun an beschreiben, es war ein klarer Durchbruch in meiner Herangehensweise an das Erstellen von Schnittstellen.

Es geht nicht darum, weniger Codezeilen zu schreiben, es geht nicht darum, einen "Syntaxzucker" zu haben, es geht darum, Werkzeuge für Menschen zu bauen. Ich bin auch gegen das Argument, dass jeder JSX verwenden sollte, das ist lächerlich. Sie verwenden das Tool, mit dem Sie Ihre Arbeit schneller und mit weniger Verwirrung erledigen können. Bei vielen (einschließlich mir) wäre es JSX (oder DSX im Fall von Flutter), das ist alles.

Ich komme von React und probiere Flutter zum ersten Mal aus. Es ist wirklich seltsam, dass Flutter Team keine JSX-Syntax hat, ich meine es ernst! In der JS-Welt ist JSX heutzutage in allen React-Alternativen weit verbreitet! JSX ist superfreundlich für Entwickler. Bitte implementieren Sie dies so schnell wie möglich, damit Sie zum Wachstum der Community beitragen können.

Sie können erkennen, dass JSX (oder in diesem Fall DSX) eine große Sache ist, wenn Sie nur nach der Anzahl der Kommentare in dieser Ausgabe suchen.

JSX ist etwas, von dem Sie nicht wissen, dass Sie es lieben, bis Sie es ausprobieren. Es ist zunächst seltsam, Markup in Ihrem Code zu haben, aber dann wird es großartig.

Es scheint unnötig für Leute zu sein, die Flutter/Dart bereits kennen, ich verstehe. Aber für jemanden, der noch nie Dart gespielt hat (wie ich), ist JSX viel einfacher anzufangen und das ist der Punkt. Wenn ihr wollt, dass mehr Leute vorbeikommen und anfangen, viel mehr tolle Sachen zu bauen, muss das Tooling einfacher sein.

Und wie @eseidelGoogle (https://youtu.be/h7HOt3Jb1Ts?t=2m41s) dem anderen sagte: „Flutter ist eine Möglichkeit, in einer einzigen Codebasis für iOS und Android zu schreiben. Wir versuchen, das schnell und einfach zu machen [. ..] Flutter spricht bis hinunter zur Hardware [...] Wir verfolgen einen sehr vielschichtigen Ansatz, sodass Sie so wenig oder so viel nehmen können, wie Sie möchten. [...] Wir haben eine Menge Investitionen in Werkzeuge getätigt ."

Implementieren Sie bitte JSX.

Ich bin ein Fan von Dart und auch ein starker Nutzer von React. Ich finde Dart immer knapper und wartbarer als JSX. Ich denke also, dass JSX/DSX auf Community-Weise implementiert werden könnte und vielleicht sollte.

@rajaraodv Nur weil Flutter als Framework im reaktiven Stil beworben wird, heißt das nicht, dass es nur eine Variante von ReactJS ist.
Aus den meisten Kommentaren habe ich den Eindruck, dass die Leute einfach Probleme damit haben, zu akzeptieren, dass etwas Neues nicht dasselbe ist wie das, was sie bereits wissen.

Sie könnten versuchen, eine Weile mit Flutter so zu arbeiten, wie es derzeit ist, und dann angemessene Argumente liefern, warum Sie denken, dass JSX/DSX auf sachliche Weise besser wäre als einfaches Dart, anstatt nur "wegen persönlicher Präferenz" oder "weil es besser ist". .

@zoechi , dir fehlt etwas: Flutter wurde laut Flutter-Dokument von React inspiriert.
Vielleicht ist es nur mein Problem. Ich habe wirklich das Gefühl, dass es mir schwer fällt, den UI-Code zu lesen, selbst wenn er in Dart 2-Syntax ist.

Flutter wurde von React Native inspiriert

Ich verstehe nicht, wie das sagt: "Alles ist gleich, außer dass die Sprache Flutter anstelle von JS heißt".

Ich habe wirklich das Gefühl, dass es mir schwer fällt, den UI-Code zu lesen

und Sie behaupten, die einzig denkbare Lösung dafür sei DSX?

Haben Sie bedacht, dass Flutter noch nicht einmal 1.0 ist und dass sich die IDE-Unterstützung im Laufe der Zeit verbessern kann?

Kürzlich wurden nur die ersten winzigen Schritte unternommen, um eine bessere Flutter-IDE-Unterstützung im Code-Editor zu erhalten, wie z. B. Schnellkorrekturen ("wrap xxx") und schließende Labels.

Es gibt unbegrenzte Möglichkeiten, die Entwicklererfahrung zu verbessern, und die meisten in dieser Diskussion sind wie
"Flutter ist noch nicht perfekt und deshalb brauchen wir DSX"
normalerweise ohne konkrete Argumente darüber, wie oder warum DSX das lösen oder verbessern würde.

@Zoechi ,

Sie könnten versuchen, eine Weile mit Flutter so zu arbeiten, wie es derzeit ist, und dann angemessene Argumente liefern, warum Sie glauben, dass JSX/DSX besser ist als einfaches Dart, und zwar auf sachliche Weise, anstatt nur "wegen persönlicher Präferenz" oder "weil es besser ist". .

Wieder einmal ist Plain Dart oder DSX einfach eine Frage des Stils, es hat keinen Sinn, darüber zu streiten, was besser ist. Es ist nur eine persönliche Präferenz und die Leute haben ihre Gründe, sich für das eine oder andere zu entscheiden.

Was in der React World passiert ist, ist, dass Sie, sobald Sie mit JSX gegangen sind, einfach nicht mehr zurückgehen. Wie andere oben erwähnt haben, werden Sie nach einer Weile von JSX abhängig. JSX wurde von anderen außerhalb von React's World (Typescript, Vue) übernommen und passt hervorragend zu Flutter.

und Sie behaupten, die einzig denkbare Lösung dafür sei DSX?

Was die Community braucht, sind generische Vorverarbeitungsfunktionen mit Quellkartenunterstützung, die in die Dart-Tools (Compiler, Analyser, IDE usw.) integriert sind, damit DSX oder etwas Besseres von der Community entwickelt und vollständig in Flutter integriert werden kann (Debugger, Auto- vollständig usw.).

Es gibt unbegrenzte Möglichkeiten, die Entwicklererfahrung zu verbessern, und die meisten in dieser Diskussion sind wie
"Flutter ist noch nicht perfekt und deshalb brauchen wir DSX"
normalerweise ohne konkrete Argumente darüber, wie oder warum DSX das lösen oder verbessern würde.

Sicher, bei diesem Ticket geht es nicht um eine allgemeine „Verbesserung der Entwicklererfahrung“. Es ist sehr spezifisch und es geht darum, JSX-Unterstützung in Flutter zu erhalten. Die Community will DSX als Alternative zum reinen Dart-Weg.

Ich kann mir nicht vorstellen, dies zu verwenden (aber ich bin bereit, es zu versuchen). Ich glaube nicht, dass dies eine Wunderwaffe ist, aber es gibt so viel Enthusiasmus, dass es sich lohnt, es zu tun.

Ich denke, Google sollte die Sprachbarrieren beseitigen, damit die Community bauen kann, was sie will.

Mir sind keine Hindernisse bekannt, die jemanden außerhalb der Flutter/Dart-Teams von Google daran hindern, etwas JSX-ähnliches für Dart/Flutter zu schreiben. Ich würde gerne Fehler auf diesen sehen, wenn jemand es versucht. (Es ist auch möglich, dass ich sie in den Kommentaren oben übersehen habe, da ich zugebe, nicht jedes Wort dieses sehr langen Fehlers gelesen zu haben.) :) :)

Danke! Schön, so viel Enthusiasmus zu sehen!

@eseidelGoogle ,

Wie könnten Intellij und/oder VS Code (mit Dart-Code) Haltepunkte setzen und Code aus einer .dsx-Datei schrittweise durchlaufen? (Ich meine, das ist keine .dart-Datei). Wie wäre es mit der Funktion zur automatischen Vervollständigung aus der .dsx-Datei (wie bei einer .dart-Datei)?

Sie haben viel in die Werkzeuge investiert, aber die Werkzeuge unterstützen keine Vorverarbeitung (mit Quellkarten) einer neuen Sprache (wie DSX), die sich nahtlos in Dart/Flutter transpiliert.

Ein Transpiler ist verfügbar, aber es gibt keine einfache Möglichkeit, ihn vollständig zu integrieren:
https://spark-heroku-dsx.herokuapp.com/index.html

PS Dieses Ticket ist nur die Hälfte der Kommentare !!!
https://github.com/flutter/flutter/issues/15922

@cbazza gibt es irgendwo ein Repo mit diesem Compiler? Es wäre großartig, den Code zu teilen und die Community dazu zu bringen, ihn zu hacken, auch wenn er nicht perfekt ist.

@jonahwilliams , nein, der DSX-Transpiler-Code wurde nicht veröffentlicht, weil es dafür viel zu früh ist.
Sie können einfach zwei handgeschriebene äquivalente Dateien (.dsx und .dart) verwenden, um Vorverarbeitungsfunktionen wie Haltepunkte, Stepping, automatische Vervollständigung usw. zu testen.

Sobald die Tools die Vorverarbeitung mit einer Art Quellkarten unterstützen, kann ich diese zum Transpiler hinzufügen und entsperrt werden. Dies würde es auch anderen ermöglichen, nach Herzenslust zu experimentieren.

Ich arbeite nicht an Flutter, aber es scheint irgendwie unvernünftig zu sein, bestimmte Tools zum Nutzen anderer zu fordern, sich dann aber auch zu weigern, frühen Quellcode oder Beispiele dafür zu veröffentlichen, womit die Tools integriert werden sollen.

Für das, was es wert ist, kenne ich keine Sprache oder kein Toolkit, das Vorverarbeitungs-Hooks jeglicher Art bereitstellt - wahrscheinlich, weil es einfach nicht einfach ist, gibt es viele Eckfälle und Annahmen rund um die Sprache und Syntax.

Wenn Sie Quellkarten (https://pub.dartlang.org/packages/source_maps) generiert haben, stelle ich mir vor, dass es ziemlich trivial ist, zumindest eine grundlegende Unterstützung in einer IDE zu erhalten, unabhängig von Dart/Flutter. Aber noch einmal, dies sind alles Vermutungen, ohne zu wissen, was Ihre Werkzeuge tun und wie Sie erwarten würden, dass sie funktionieren.

@matanlurey , die Unterstützung der Vorverarbeitung über Quellkarten ist ein generischer Mechanismus, der nicht von einem bestimmten Transpiler abhängt. Es ist eine Funktionalität, die jede denkbare Zukunftssprache unterstützen soll. Der Chrome-Browser/Debugger unterstützt es recht gut und ich kann jede Sprache debuggen, die in JS transpiliert wird.

Zum Testen können Sie sich jede einfache Art von Transpiler ausdenken, um zu zeigen, wie Quellkarten verwendet werden. Schreiben Sie zum Beispiel einen trivialen Transpiler, der Dart/Flutter-Code mit einer Leerzeile zwischen jeder Zeile der Originaldatei generiert. (.d2 => .dart, .d2 ist eine Dart/Flutter-Datei, die .dart-Datei enthält eine Leerzeile zwischen jeder Zeile in der Originaldatei).

Ja, ich kann an der Generierung einer Quellkarte für eine Testdatei arbeiten.

Flutter zögert derzeit, NativeScript, ReactNative, Android, Web und andere Entwickler zufrieden zu stellen, die an ähnliche XML-Layouts gewöhnt sind. Sie haben Wichtigeres zu tun, also lasst uns auflösen und schlafen gehen.

Ich wünschte, Amy, die Befürworterin von JSX Syntax, würde einige Tage damit verbringen, wirklich mit Flutter zu arbeiten, bevor sie weiter jammerte. Ich kam von einem Xaml-basierten System, habe mich aber schnell daran gewöhnt. Probieren Sie es einfach aus.

@escamoteur
Hey, Escamoteur. Glaubst du, ich habe nicht viel Zeit damit verbracht, Flattern zu lernen?
In flutter.io/tutorials/layout/ am Ende des Abschnitts „Widgets packen“ funktioniert der im Tutorial angegebene Code nicht.
Ich habe das Problem unter dem Flatterproblemblock erwähnt, aber niemand möchte sich darum kümmern.

• Dart-Code: 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 Gibt es einen Zusammenhang zwischen Ihrem Kommentar und dem Thema dieser Ausgabe?

@Zoechi
Escamoteur sagte, er hoffe, dass der Befürworter von JSX Syntax nur ein paar Tage damit verbringen würde, wirklich mit Flutter zu arbeiten, bevor er weiter jammere.
Dieser Kommentar zeigt, dass wir wirklich viele Tage damit verbracht haben, mit Flutter zu arbeiten, und die Anfrage von JSX ist wirklich unsere Herzensangelegenheit.

Group Dart: „Dart-Syntax ist viel besser und JSX/DSX ist einfach nicht gut“
Gruppe JSX/DSX: „JSX/DSX-Syntax ist viel besser und Dart ist einfach nicht gut“

Ich kann nicht die einzige Person sein, die das sieht? Beide Seiten machen gültige Argumente für und gegen ihre Position. Ich denke, was hier verloren geht, ist, dass @cbazza nicht nur Kritik hatte, sondern auch etwas dagegen getan hat. Der Versuch, die Lücke zwischen Webentwicklern/reagieren/reagieren-nativ und Flutter zu schließen, um Flutter zu nutzen.

Und meine 2 Cent ... Als Full-Stack-Entwickler habe ich Erfahrung mit einer Vielzahl von Sprachen und Ansätzen ... JSX ist eine meiner bevorzugten Arten, Code zu schreiben, und ich hoffe, es wird eine alternative Syntax zu Darts geben ... Und ich sage nicht, dass die aktuelle Syntax schlecht ist, ich bevorzuge nur den JSX-Stil.

Ich muss diesem Zitat der Gruppe JSX/DSX widersprechen

Dart ist einfach nicht gut

Dart ist eine sehr gute und robuste Sprache, niemand disst die Sprache. Die Diskussion dreht sich nicht um Dart, sondern um eine synthetische Schicht darüber, die die meisten UI-Entwickler bereits heute verwenden, und wir schlagen vor, dass Flutter so etwas einbaut.

• Android hat XML-Layouts.
• iOS hat Storyboard XIB (XML)
• GTK+ hat XML für Pango usw.
• Qt hat QML (YAML-ähnlich)
• Xamarin verfügt über XAML

Die meisten dieser Frameworks und Sprachen verfügen über UI-Auszeichnungssprachen, die die View- von der Controller-Logik trennen. Dann kommt React mit einem anderen Ansatz daher (den wir hier vorschlagen) und ich denke, wir müssen uns einig sein, dass RN derzeit in Bezug auf Benutzerwachstum und Popularität fliegt, und ich kann mich irren, aber hauptsächlich wegen JSX.

...

Ist es wirklich so ein verrückter Vorschlag, dass wir diese Art von Feedback vom Flutter-Team/Benutzern bekommen müssen?

@birkir und alle von ihnen bringen eine Menge Probleme mit sich, die Flutter nicht hat \o/
Eine weitere Sprache ist nicht erforderlich.
Sie können die Ansicht auch in Flutter trennen, sogar mit der gleichen Sprache.

@birkir In diesem Thread geht es zu 100% um Dart und Syntax.

Die Diskussion dreht sich nicht um Dart, sondern um eine synthetische Schicht darüber, die die meisten UI-Entwickler bereits heute verwenden, und wir schlagen vor, dass Flutter so etwas einbaut.

Es geht also nicht um Dart ... aber Flutter muss etwas anderes als Dart für Layouts verwenden? Scheint, als ob Sie sagen, Dart sei nicht gut genug, während Sie gleichzeitig behaupten, dass dies nichts mit Dart zu tun hat?

Ich glaube nicht, dass es an diesem Punkt wichtig ist, das Flutter-Team hat dieses Feedback gesehen (auf die Anfrage nach einem JSX/DSX-Ansatz) und sie wollen ihren ursprünglichen Weg fortsetzen. Ich denke, es könnte besser gehandhabt werden, aber es scheint nicht so, als wären sie dagegen, dass die Community Lösungen entwickelt.

Ich bin froh, dass es eine weitere plattformübergreifende Option gibt ... wird Apple der nächste sein, der etwas anbietet? Und vielleicht sehen sie, was so viele von uns an React/React-Native mögen? IDK, wenn sie etwas kochen.

das Flutter-Team hat dieses Feedback gesehen (auf Anfrage eines JSX/DSX-Ansatzes) und sie

Dieser Fehler ist noch offen, weil wir noch nicht herausgefunden haben, was wir hier machen wollen. Wir schauen uns die Experimente (z. B. cbazza's) gespannt an, um zu sehen, wie die Leute sie verwenden. Wir planen, irgendwann einen Hook im Build-System für Codegen-Tools wie dieses bereitzustellen, obwohl wir dies wahrscheinlich nicht in naher Zukunft tun werden. Langfristig hoffen wir, mit dem, was wir hier lernen, die Entwicklung von Dart als Sprache zu beeinflussen. Dies könnte bedeuten, etwas wie E4X/H4X/JSX/DSX zu Dart selbst hinzuzufügen. Oder vielleicht erfahren wir, dass niemand es wirklich benutzt, also werden wir nichts tun. Oder vielleicht braucht jeder etwas anderes, also sind Codegen-Hooks und benutzerdefinierte Pakete wie das von cbazza die Antwort. Wir wissen es noch nicht.

@jstansbe - Apple denkt, dass Cross-Plattform IPhone, IPad & Mac OS bedeutet. Es ist wahrscheinlicher, dass sie Türme auf dem ummauerten Garten hinzufügen, als etwas plattformübergreifendes zu bauen :)

Ich denke, wenn es möglich wäre, das Widget auf andere Weise einzurücken und zu formatieren, wäre es ähnlicher wie jsx und benutzerfreundlicher für Benutzer, die Erfahrung mit XML und HTML haben (fast alle Android-Entwickler) ... überprüfen Sie diesen Code im 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
      ],
    ),
  );

Überprüfen Sie diesen Dart-zu-jsx-Code

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

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

und vergleichen Sie mit diesem anderen Format, das eher htmlish ist

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

Dies ist ein bisschen ähnlicher und jetzt müssen Sie nur noch von links nach rechts sehen, um die verschiedenen Widgets zu bemerken, die html/xml/jsx ähneln

Die Element-(Widget-)Attribute haben mehr Einrückung als die neuen Widgets, sodass dies den Code besser verstehen und überprüfen kann

Wäre toll, wenn ich dieses Format auf den verschiedenen Iden automatisch einrücken könnte, im Moment mache ich das von Hand ....

Nachdem ich alle Kommentare hier gelesen und privat mit meinen Freunden (einheimische Entwickler mobiler Apps, Java/kotlin/objective-c/swift-Typen) diskutiert habe, meine Beobachtung:

Die Leute fragen nach zwei Dingen,

• __Bessere Lesbarkeit und einfacheres Schreiben__. Eine tiefe Verschachtelung, gemischt mit einigen Syntaxgeräuschen (Klammern, Semikolon, new , child , children ) ist bei der aktuellen Art der Codierung ärgerlich.
• __Stil/Design vom Code trennen__. Visuelle Trennung ist gut zum Lesen (Unterscheidung des Stils von zwingendem Code durch einen Blick) und eine echte Trennung ist gut für Tools (z. B. IDE mit Layout-Editor).

Es gibt auch hauptsächlich zwei Gruppen mit unterschiedlichen Meinungen,

• Verbesserung der aktuellen Syntax, ohne eine weitere Komplexität einzuführen, um das Problem zu lösen.
  Es gab bereits einige Verbesserungen in dieser Richtung. Zum Beispiel das optionale new , const in Dart 2.0 und das vorgeschlagene virtual "closing tag" comments Feature.
• Einführung zusätzlicher Auszeichnungssprachen (JSX-ähnlich oder XML-ähnlich), um das Problem zu lösen.

Sie können derzeit nicht ohne Weiteres feststellen, welches besser ist. Lassen Sie also einfach die Community zuerst ihre Experimente durchführen und treffen Sie die endgültige Entscheidung (akzeptieren oder ablehnen) später.

@hooluupog virtuelle schließende Tag-Kommentare funktionieren bereits seit einiger Zeit in IntelliJ, AS, VSCode

@Hixie

Dieser Fehler ist noch offen, weil wir noch nicht herausgefunden haben, was wir hier machen wollen. Wir schauen uns die Experimente (z. B. cbazza's) gespannt an, um zu sehen, wie die Leute sie verwenden.

Die Leute können meine Experimente nicht verwenden, weil sie im Moment nicht nahtlos in Flutter eingebettet werden können; Es bleibt also ein Außen-/Online-Experiment, bei dem die Leute nur das Potenzial sehen können.

Wir planen, irgendwann einen Hook im Build-System für Codegen-Tools wie dieses bereitzustellen, obwohl wir dies wahrscheinlich nicht in naher Zukunft tun werden. Langfristig hoffen wir, mit dem, was wir hier lernen, die Entwicklung von Dart als Sprache zu beeinflussen.

Können Sie zeitlich genauer sagen, wann wir mit einigen Bewegungen bei den Änderungen des Build-Systems rechnen können, um die Vorverarbeitung zu unterstützen? Sprechen wir von einem Monat, einem Quartal, sechs Monaten, einem Jahr, 2 Jahren, einem Jahrzehnt, einem Jubiläum usw

Dies könnte bedeuten, etwas wie E4X/H4X/JSX/DSX zu Dart selbst hinzuzufügen.

Bitte lesen Sie die oberen Absätze der JSX-Spezifikation, um zu sehen, dass die Dart-Sprache nicht geändert werden muss, da JSX/DSX keine Semantik hat und nicht dazu gedacht ist, von Engines implementiert oder in Sprachen integriert zu werden. Es ist für die Verwendung in einem Präprozessor (Transpiler) vorgesehen. DSX könnte mit Flutter & on Web verwendet werden, um React-Dart genau wie React.js zu erstellen, jedoch mit der Dart-Sprache.

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

Oder vielleicht erfahren wir, dass niemand es wirklich benutzt, also werden wir nichts tun.

Wie können Menschen etwas nutzen, das ihnen überhaupt nicht zur Verfügung steht, und dann zu dem Schluss kommen, dass nichts getan werden muss, weil Menschen es nicht nutzen? Das erinnert mich so sehr an Melissa McCarthys Sean Spicer-Imitation auf SNL über das "Reiseverbot" ... "zirkuläre Verwendung des Wortes" :)

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

Oder vielleicht braucht jeder etwas anderes, also sind Codegen-Hooks und benutzerdefinierte Pakete wie das von cbazza die Antwort. Wir wissen es noch nicht.

Vorverarbeitungsfunktionen sind dringend erforderlich, um Experimente zu ermöglichen. Ohne sie geht nichts voran und Sie werden nichts Neues lernen.

Die Leute können meine Experimente nicht benutzen

Ich glaube, Sie unterschätzen, wie bereitwillig Menschen Dinge ausprobieren, auch wenn sie noch nicht ganz ausgefeilt sind. Zum Beispiel könnte jemand einfach ein Shell-Skript schreiben, das flutter run umschließt, um zuerst die Vorverarbeitung durchzuführen, und dann flutter run . Ich habe selbst ein Skript, das Hot Reload umschließt, um etwas Ähnliches zu tun (ich führe zuerst den Analysator aus, und nur wenn es erfolgreich ist, sende ich das Hot Reload-Signal an das flutter -Skript).

Können Sie zeitlich genauer sagen, wann wir mit einigen Bewegungen bei den Änderungen des Build-Systems rechnen können?

Nicht wirklich (siehe zB https://en.wikipedia.org/wiki/Forward-looking_statement , warum es schwierig sein könnte, solche Aussagen zu machen), aber wahrscheinlich nicht in den kommenden Wochen.

Es besteht keine Notwendigkeit, die Dart-Sprache zu ändern

Das ist durchaus möglich. Ich sage nur, dass wir auf der Grundlage dieser Experimente zu einer beliebigen Anzahl von Schlussfolgerungen gelangen können, von „nichts tun“ bis „radikale neue Merkmale zur Sprachsyntax hinzufügen“ und alles dazwischen. Der Punkt ist, dass wir noch keine Entscheidungen getroffen haben und sehr offen dafür sind, zu erfahren, was auf der Grundlage all dieser Diskussionen und Experimente getan werden muss.

Fügen Sie JSX dem Rückstand hinzu und lassen Sie es im Gladiator-Stil mit den über einer Million anderen dringenden Anforderungen konkurrieren?

React ist für das Web geschrieben und benötigt daher eine einfache Lösung zum Schreiben von HTML. JSX wurde nicht populär, weil es die beste Lösung zum Schreiben von Benutzeroberflächen ist, sondern weil es die beste Lösung zum Schreiben von HTML ist.

Flutter hat diese Einschränkung nicht, also sollten wir uns nicht aus den falschen Gründen mit einer mittelmäßigen, ausführlichen Lösung zufrieden geben.

Wenn wir die Ausführlichkeit reduzieren wollen, lasse ich mich lieber zB von Anko (https://github.com/Kotlin/anko/wiki/Anko-Layouts) inspirieren. Dort können Sie überall neue lokale Variablen definieren und normale for-Schleifen verwenden, um die Liste der untergeordneten Elemente dynamisch zu erstellen, wodurch der Code leichter verständlich wird. Außerdem würde der LayoutBuilder für das Auge einfacher werden, da jede Verschachtelungsebene sowieso bereits eine Lambda-Funktion ist (keine Notwendigkeit, ein zusätzliches Builder-Lambda zu übergeben). Wie auch immer, das ist nur zur Inspiration und ich denke nicht, dass Flutter das 1:1 kopieren sollte.

React ist für das Web geschrieben und benötigt daher eine einfache Lösung zum Schreiben von HTML. JSX wurde nicht populär, weil es die beste Lösung zum Schreiben von Benutzeroberflächen ist, sondern weil es die beste Lösung zum Schreiben von HTML ist.

React Native ist weder Webentwicklung noch verwendet es HTML. Fragen Sie erfahrene React-Entwickler (oder lesen Sie diesen und den anderen JSX-Thread vollständig) und Sie werden sehen, dass JSX von vielen React-Entwicklern als der beste Weg zum Schreiben von Benutzeroberflächen angesehen wird.

Dort können Sie überall neue lokale Variablen definieren und normale for-Schleifen verwenden, um die Liste der untergeordneten Elemente dynamisch zu erstellen, wodurch der Code leichter verständlich wird.

Diese Aussage zeigt deutlich, dass Sie JSX nicht kennen. JSX (wie in DSX) verwendet alle Programmierkonstrukte (for-Schleifen usw.) aus der Hosting-Sprache (Javascript/Dart).

Dieses Ticket ist nur an JSX-ähnlicher Funktionalität interessiert, für andere Ansätze (wie Anko) erstellen Sie bitte Ihr eigenes Ticket zur Diskussion dort.

React Native ist weder Webentwicklung noch verwendet es HTML. Fragen Sie erfahrene React-Entwickler (oder lesen Sie diesen und den anderen JSX-Thread vollständig) und Sie werden sehen, dass JSX von vielen React-Entwicklern als der beste Weg zum Schreiben von Benutzeroberflächen angesehen wird.

React kam lange vor React Native heraus. Das ursprüngliche Design von JSX basiert auf dem Rendern von HTML, nicht auf nativen Benutzeroberflächen. Niemand konnte ein einziges überzeugendes Argument dafür vorbringen, was JSX besser macht. Durch Vergleich

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

zu

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

Sie haben keinen aktuellen Vergleich durchgeführt und fügen einfach mehr Zeug in eine einzelne Zeile ein. Sie müssen es vergleichen mit:

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

Beachten Sie, dass alle hässlichen {<{<>} />} - und schließenden </...> -Tags verschwunden sind.

Diese Aussage zeigt deutlich, dass Sie JSX nicht kennen. JSX (wie in DSX) verwendet alle Programmierkonstrukte (for-Schleifen usw.) aus der Hosting-Sprache (Javascript/Dart).

Nein, Sie können in JSX keine if-Anweisungen oder for-Schleifen (oder switch oder andere Anweisungen) verwenden:

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

Nur Ausdrücke sind erlaubt. Sie müssen also bedingte Operatoren verwenden ( c ? x : y , was else if sehr hässlich macht) und Array.map usw. (was auch sehr hässlich sein kann) oder Teile Ihres Codes in die verschieben oben in der Renderfunktion oder in einer separaten Hilfsfunktion. Dasselbe gilt natürlich für Flutter. Anko hat diese Einschränkung nicht und macht das Schreiben (einigen) UI-Codes natürlicher.

Ich denke, in einer Diskussion über die Einführung von JSX ist es durchaus berechtigt und notwendig zu fragen, ob das tatsächlich die beste Lösung ist oder ob wir etwas Besseres finden können. Andernfalls verschwenden wir Ressourcen für die falschen Aufgaben.

React kam lange vor React Native heraus. Das ursprüngliche Design von JSX basiert auf dem Rendern von HTML, nicht auf nativen Benutzeroberflächen.

Beim ursprünglichen Design von JSX geht es um die bekannte Art, Baumstrukturen zu erstellen/manipulieren, die sich besonders bei der Arbeit mit der Benutzeroberfläche zeigen. Denken Sie an Komponentenhierarchien (https://facebook.github.io/jsx/), die in der Webentwicklung, nativen Entwicklung, jeder UI-Entwicklung usw. auftauchen.

Niemand konnte ein einziges überzeugendes Argument dafür vorbringen, was JSX besser macht.

Das ist der Punkt, wir wollen den aktuellen Weg nicht ersetzen, wir wollen einen alternativen Weg hinzufügen, der den React-Entwicklern vertraut ist.

Ihr Anko-Vorschlag wäre Android Kotlin-Entwicklern bekannt, also schlagen Sie in einem separaten Ticket eine Spezifikation vor, die mit der aktuellen Flutter-Hierarchie funktioniert. Sobald ich sehe (oder eine Online-Version Ihrer Spezifikation versuche), könnte ich sehen, ob sie mit der aktuellen Flutter-Widget-Hierarchie generiert/interoperieren kann.

Nein, Sie können in JSX keine if-Anweisungen oder for-Schleifen (oder switch oder andere Anweisungen) verwenden:

Nicht, dass ich Ihnen das empfehlen würde, aber es ist möglich: Erstellen Sie eine anonyme Funktion und rufen Sie sie auf.

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

Ich denke, in einer Diskussion über die Einführung von JSX ist es durchaus berechtigt und notwendig zu fragen, ob das tatsächlich die beste Lösung ist.

Es gibt nicht die beste Lösung, es geht nur darum, die Wahl zu haben, die Wahl zu haben, etwas Vertrautes zu verwenden, das direkt auf Flutter-Widgets abgebildet wird und keinen Overhead hinzufügt.

Übrigens, versuchen Sie Folgendes auf meinem Online-Transpiler unter:
https://spark-heroku-dsx.herokuapp.com/index.html

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

und du bekommst:

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

DSX ist JSX ähnlich, aber für Dart & Flutter, daher hat es eigene Funktionen, die unter dem obigen Link beschrieben werden.

Wenn ich das sehe, erhalte ich Flashbacks von XML-Layouts von Android. Ich denke nicht, dass es eine gute Idee ist, dies zu implementieren. Jetzt, wo Sie nicht einmal new und const schreiben müssen, sieht es sogar noch besser aus.

@charafau Können Sie ein Beispiel/Bild/Link von "XML-Layouts von Android" teilen, auf die Sie sich beziehen?

Nein, @wkornewald. Wenn „JSX nicht populär wurde, weil es die beste Lösung zum Schreiben von UIs ist, sondern weil es die beste Lösung zum Schreiben von HTML ist“, warum verwendet React immer noch JSX zum Erstellen einer mobilen App und einer Desktop-App? Sogar Ihre Github-Desktopanwendung, die plattformübergreifende mobile Walmart-App und die Tesla-App sowie Skype werden ebenfalls von RN entwickelt.

React fügt keine for-Schleife in das JSX-Tag ein, da es bei dem Konzept von React um die Komponente geht. Der obere Teil ist die Logik und der untere Teil ist der JSX, und das ist immer so. Alles wird in viele Komponenten zerlegt und zu einem großen Bauteil zusammengefügt.

Tatsächlich sind die meisten Leute hier, die gegen JSX nur raten können, JSX ist eine Art HTML, XML oder eine weniger ausführliche Lösung.

@JonathanSum

Die meisten Leute hier, die gegen JSX nur vermuten können, ist JSX eine Art HTML

Ich denke, es liegt eher daran, dass es außer persönlichen Vorlieben keine anderen Argumente für JSX/DSX gab. Das ist natürlich in Ordnung, wie oben bereits besprochen, aber bitte unterstellen Sie nicht, dass die Leute gegen JSX sind, weil sie es nicht verstehen, wenn es keine Liste guter sachlicher Argumente gibt, die zeigen, wo JSX besser ist als einfaches Dart.

Ich denke, es liegt eher daran, dass es außer persönlichen Vorlieben keine anderen Argumente für JSX/DSX gab.

Nicht wirklich, viele wurden vorher gegeben, einfach beide Threads vollständig lesen. Ich habe diese 2 Dinge bereits erwähnt:
(1) Kein 'Kind'- und 'Kinder'-Zeug mehr
(2) einfach für Tools von Drittanbietern zu manipulieren (parsen, analysieren und regenerieren)

Mit (2) können Sie das Markup erweitern, um Dinge zu tun, die nur mit Dart nicht möglich sind; zum Beispiel der Spread-Operator von DSX oder das Generieren vieler Funktionsparameter aus einem kleineren Satz.

Andere haben viele gute Punkte geliefert, aber ich grabe es nicht für Sie aus;)

(1) wie erwähnt können solche Sachen auch im Dart geändert/verbessert werden und es gab auch schon Diskussionen. Dies wird einfach nicht vor der Veröffentlichung von Dart 2 passieren.
Einfach anzunehmen, dass DSX alle möglichen neuen Features zulässt und Dart nicht, ist meiner Meinung nach kein faires Argument.
(2) Ich bin mir ziemlich sicher, dass dies auch mit Dart möglich ist, und es gibt natürlich bereits einen Parser für Dart.

Andere haben viele gute Punkte geliefert, aber ich grabe es nicht für Sie aus;)

Es ist nicht nötig, sie für mich auszugraben, aber das kommt häufig vor und Sie können andere vielleicht davon überzeugen, dass Sie tatsächlich stichhaltige Argumente haben.
Ich habe die Diskussion verfolgt und kann mich nicht an gute sachliche Argumente erinnern, und das mag für andere genauso sein. Wenn Sie sie zusammenfassen, können Sie einfach einen Link zur nächsten Frage posten.

Wie bereits erwähnt, kann ich persönliche Vorlieben als gültiges Argument akzeptieren, aber wenn Sie behaupten, auch viele sachliche Argumente zu haben, dann denke ich, dass es berechtigt ist, darum zu bitten, darauf hingewiesen zu werden.

Sie fragen immer wieder nach „gültigen Argumenten“ und wenn sie gegeben werden, lehnen Sie sie ab als „Zukunft Dart wird dies haben“ oder „Dies ist kein gültiges Argument“.

Tatsache ist, dass Dart/Flutter derzeit überall laute untergeordnete Elemente hat, wenn ein Widget erstellt wird, und XML/DSX nicht. Im Moment ist es ein sehr stichhaltiges Argument für die Verwendung von DSX, um dieses Kind/Kinder-Rauschen zu entfernen. Kannst du das einfach als gültiges Argument akzeptieren? (Nur weil Sie sagen, dass Dart das in Zukunft haben wird, macht es das Argument nicht ungültig).

Es ist auch eine Tatsache, dass das Parsen von XML viel einfacher ist als das Parsen der vollständigen Dart-Sprache, und jede Sprache da draußen hat einen XML-Parser, während nur Dart einen vollständigen und vollständigen Dart-Sprachparser hat. Können Sie sehen, dass dies auch ein gültiges Argument ist?

Es gibt viele gültige Argumente, sie sind einfach nicht gültig für Sie und deshalb habe ich aufgehört, darüber zu streiten. Wenn die Leute daran interessiert sind, was gesagt wurde, lesen Sie einfach die 2 Threads zu JSX vollständig. Ich habe kein Interesse daran, Sie davon zu überzeugen, DSX zu verwenden, Sie sind mit einfachem Dart zufrieden, sei es so; Ich bin nicht.

Argumente für eine optionale DSX-Syntax:

1) Bringen Sie mehr Entwickler ein, die von React (Web und nativ) kommen, und ziehen Sie sie an
2) Bessere Erfahrung beim Portieren von React Native-Komponenten in Flutter-Widgets
3) Fördert die Konsistenz von untergeordneten/untergeordneten Eigenschaften in Widgets
4) Lesbarkeit des Codes (meinendes Argument)
5) Betrachten Sie die logischen Linting getrennt von den Dart-Flusen
6) Eröffnet eine Welt für UI-Building-Tools
7) Öffnet das Ökosystem für Präprozessoren

DSX+1

DSX+1

Ich hätte gerne ein paar Vor- und Nachteile geschrieben, aber nachdem ich all diese Kommentare gelesen habe, habe ich das Gefühl, ich werde alles immer wieder wiederholen.
Hören Sie auf, so naiv und ignorant zu sein, niemand sagt, dass Sie gezwungen sind, UIs mit DSX zu schreiben, es ist einfach eine Option (bessere Alternative).
Es gibt einen Grund, warum Sie JS auf 101203103 verschiedene Arten schreiben können.

Nun, es gibt immer die Option, ein Analyse-Plug-in zu schreiben, das DSX parst und sie in reguläre Dart-Funktionsaufrufe umwandelt, sodass der Compiler keine zusätzliche Arbeit leisten muss.

Die eigentliche Frage ist, ob Analyse-Plugins im Kontext des Compilers gelten.

Wenn Sie mich fragen, sollte DSX nur Opt-in sein, idealerweise über eine Art Plug-in. Ich denke, es ist äußerst unnötig, es der Sprache selbst hinzuzufügen, da sich dann serverseitige und Webbenutzer von Dart an die Änderungen anpassen müssen, nicht nur Flutter-Benutzer. Die überwiegende Mehrheit des in Dart geschriebenen Codes benötigt nicht einmal im Entferntesten XML-Syntax, daher ist es eine schlechte Entscheidung, sie allen aufzuzwingen.

TLDR; Wenn Sie DSX so sehr wollen, schreiben Sie ein Analyse-Plugin und bringen Sie es selbst zu Dart. Das Internet wird dich lieben, du wirst Tausende von Github-Sternen bekommen und du wirst dich wie React fühlen. Gewinnen.

PS: Ich werde sogar gegen dich antreten, um es zu tun

Nun, es gibt immer die Option, ein Analyse-Plug-in zu schreiben, das DSX parst und sie in reguläre Dart-Funktionsaufrufe umwandelt, sodass der Compiler keine zusätzliche Arbeit leisten muss.

Derzeit gibt es in der Dart-Sprache keine Möglichkeit, dies ohne Hacks zu implementieren (denken Sie an Rennbedingungen, rekursive Importe und so weiter). Dies muss auf einer Ebene integriert werden, auf der alles wie erwartet funktioniert, heißes Nachladen, statische Analyse usw.

Wenn Sie mich fragen, sollte DSX nur Opt-in sein, idealerweise über eine Art Plug-in. Ich denke, es ist äußerst unnötig, es der Sprache selbst hinzuzufügen, da sich dann serverseitige und Webbenutzer von Dart an die Änderungen anpassen müssen, nicht nur Flutter-Benutzer. Die überwiegende Mehrheit des in Dart geschriebenen Codes benötigt nicht einmal im Entferntesten XML-Syntax, daher ist es eine schlechte Entscheidung, sie allen aufzuzwingen.

Wenn Sie den Thread lesen, war das die Idee vom ersten Tag an. Wir wollen nur die Unterstützung von Flutter/Dart, um einen Transpiler zu machen.

TLDR; Wenn Sie DSX so sehr wollen, schreiben Sie ein Analyse-Plugin und bringen Sie es selbst zu Dart. Das Internet wird dich lieben, du wirst Tausende von Github-Sternen bekommen und du wirst dich wie React fühlen. Gewinnen.

Lesen Sie den Thread, dies wurde bereits von @cbazza getan (Analyzer-Plugin wird es nicht schneiden)

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

PS: Ich werde sogar gegen dich antreten, um es zu tun

Toll! Schon allein eine Theorie, wie dies funktionieren würde, wäre interessant zu sehen.

SGTM. Ich schätze, wir warten dann alle auf eine Art Vorverarbeitungsunterstützung.

Ich bevorzuge die Builder-Syntax, als Parameter über den Konstruktor zu übergeben

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

wie in https://fblitho.com/

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

DSX+1

Ich verstehe die Argumente für JSX, aber ich denke, es gibt genauso viele Leute (selbst eingeschlossen), die den Gedanken hassen, XML in eine Programmiersprache zu stopfen. Es fühlt sich einfach falsch an (aber ich verstehe total , dass andere nicht so denken).

Da es nahezu unmöglich ist, einmal implementierte Features wieder wegzunehmen, empfehle ich das Vorsorgeprinzip. Lassen Sie uns sehen, wie sich einige der neueren Dart 2-Syntaxfunktionen auswirken, bevor wir uns zu einer wesentlichen Änderung der Art und Weise verpflichten, wie Flutter-Apps erstellt werden.

@wseltsam
Ich kann dich verstehen. Früher war ich gegen JSX und habe js mit xml/html gemischt ... dann habe ich es versucht. Nach ein paar Monaten mit React habe ich mich in JSX verliebt. Zwei Killervorteile sind:

1. keine neue Syntax und Dienstprogramme
2. keine Übergabe von Variablen, Funktionen etc. mehr

@wstrange ,

Da es nahezu unmöglich ist, einmal implementierte Funktionen zu entfernen,

Das ist nicht selbstverständlich, wer hätte gedacht, dass Google MathML aus Chrome entfernen würde?

Lassen Sie uns sehen, wie sich einige der neueren Dart 2-Syntaxfunktionen auswirken, bevor wir uns zu einer wesentlichen Änderung der Art und Weise verpflichten, wie Flutter-Apps erstellt werden.

Es ist überhaupt keine Änderung an der Art und Weise, wie Flutter-Apps erstellt werden, es ist nur eine alternative Methode, die die aktuelle Methode nicht ändert, und vor allem ist es einfach eine andere Syntax als die Klassenbibliothek. Ein einfacher Transpiler führt das Mapping durch, ohne Informationen aus Flutter-Klassen zu benötigen, sodass es sowohl für den Code von jedermann als auch für Flutter jetzt und in Zukunft gut funktioniert.

@Bessonov ,

Ja, Sie kennen React erst, wenn Sie ein paar Monate damit arbeiten und dann erkennen, was für eine phänomenale Bibliothek es für den Umgang mit Komponentenhierarchien ist.

@cbazza Ich könnte genau dasselbe über Flutter sagen. Verbringen Sie einige Wochen damit und Sie werden JSX nicht vermissen.

Die Reaktion sagt uns alles.

Wie jetzt, +1 fast das Doppelte -1

@escamoteur ,
Ja, eine sehr faire Aussage, aber ich habe viel Zeit mit Flutter verbracht und kann mit Sicherheit den Wert sehen, den DSX dazu beitragen würde. Wie @leedstyh bemerkt hat, führen DSX-Fans das Rennen mit fast 2 zu 1 an, was ziemlich erstaunlich ist, wenn man bedenkt, dass die Leute in diesem Forum Flutter-Leute sind.

Ich habe eine Frage:

Bei Verwendung der DSX-Syntax gehen wir implizit davon aus, dass das/die verschachtelte(n) Kind(er) vom Typ Widget ist/sind. Was ist, wenn wir ausdrücklich angeben möchten, dass verschachtelte untergeordnete Elemente ein bestimmter Untertyp von Widget sein sollen?

Wenn ich beispielsweise möchte, dass untergeordnete Elemente meines benutzerdefinierten Widgets nur eine Liste von Containern akzeptieren, kann ich die untergeordneten Elemente mit List<Container> kommentieren, und die IDE gibt einen Fehler aus, sobald ich etwas anderes als Container einfüge. Soweit mir bekannt ist, gibt es bei der Verwendung von dsx keine Möglichkeit, Typsicherheit wie folgt zu erzwingen. Vielleicht können wir beim Kompilieren der App einen Fehler haben, aber ich denke, der Fehler, der beim Tippen ausgelöst wird, ist immer noch eine bessere Erfahrung.

Ich denke, wir sollten jedem etwas Zeit geben, um es auszuprobieren und sich mit der Flattermethode vertraut zu machen, um die Benutzeroberfläche zu deklarieren, zumindest nach der Veröffentlichung von v1. Dann könnten wir uns diese Funktion genauer ansehen.

@sandangel ,

Sehr guter Fang !!! Ich werfe meinen virtuellen Hut vor Sie. Mein erster Prototyp hatte von Anfang an einige Löcher, die mir bewusst waren und nur darauf warteten, dass die Leute sie finden und sich melden. Ich hatte nur gehofft, dass die Leute daran interessiert sind, über die Technologie zu diskutieren, anstatt darüber zu streiten.

Die Lösung, die ich dafür habe, besteht darin, den Array-Typ als weiteren Parameter für den Namespace bereitzustellen. Da der Namensraum groß wird, können wir die Kurzform für „Kinder“ auf „*“ setzen.

Wenn in Beispiel 2 unter https://spark-heroku-dsx.herokuapp.com/index.html Aktionen ein Array von „Container“ anstelle des standardmäßigen „Widget“ wären, würde es wie die folgenden Alternativen aussehen:

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

Hallo @cbazza , danke für deine Antwort.

Ich freu mich auf deine Lösung. Missbrauchen wir den XML-Namespace, wie in w3shool-XML-Namespaces beschrieben?

Wie es heißt, wird der Namensraum hauptsächlich verwendet, um den Namenskonflikt im XML-Dokument zu lösen.

Wenn also jemand das obige XML liest, könnte er denken, dass Sie ein Container-Tag unter dem Namensraum „Kinder“ des Namensraums „Aktionen“ deklarieren, nicht dass Sie erzwingen, dass alle verschachtelten Kinder ein Container sein müssen. Es verwirrt mich, wenn ich Ihre vorgeschlagene Syntax zum ersten Mal lese, ohne die obige Erklärung zu lesen.

Könnten wir etwas Besseres haben?

DSX ist kein XML, es ist XML-ähnlich, also muss es nicht der XML-Semantik folgen, ähnlich wie die Angular-Template-Sprache ;) Wie auch immer, ich bin immer offen für bessere Alternativen oder Vorschläge und würde gerne eine Diskussion hier führen.

Von React-native kommend unterstützte ich zuerst die JSX-ähnliche Implementierung und mochte die verschachtelten Objekte nicht, aber ich fange an, OOP zu genießen und alles als Objekt zu sehen!

Für die Leute, die von React-native kommen, empfehle ich dieses Plugin sehr! https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer

@klartank
Können Sie Ihre Erfahrung mit React-Native (JSX), Flutter (OOP) und Ihrer Reise von einem zum anderen erweitern?

@cbazza Ich denke, dass die Winkelvorlagensyntax der XML-Semantik folgt, und wie ich weiß, gibt es keinen Konfliktanwendungsfall zwischen der Winkelsyntax und dem XML-Dokument.

In Typoskript haben wir Unterstützung für die generische Komponente .
Also ich denke, wir könnten so etwas haben:

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

Aber auch hier wird die generische Komponente für die Typprüfung der Eigenschaftseingabe verwendet. Ich weiß nicht, ob die obige Syntax in diesem Anwendungsfall eine richtige semantische Bedeutung hat.

Ich habe wirklich das Gefühl, dass das Flutter-Team die aktuelle API speziell für die neue Art der Deklaration der Benutzeroberfläche erstellt hat, von der sie annahmen, dass sie besser als JSX ist, und jede Anstrengung, die wir versuchen, die JSX-Syntax an die aktuelle API zu binden, lässt sie nur unnatürlich / unbequem aussehen.

Die Reaktion sagt uns alles.

Wie jetzt, +1 fast das Doppelte von -1

Das hat nichts zu bedeuten.

Außer diejenigen, die alle Flutter-Ausgaben beobachten, verdoppeln die, die auf dieser Ausgabe landen, weil sie bereits an JSX gewöhnt sind (und explizit danach suchen). Das bedeutet also eher, dass _die Leute, die eine JSX-ähnliche Erfahrung wollen, doppelt so viele Leute sehen, die alle Ausgaben sehen, die mit -1_ abgestimmt haben. (imho, ein Teil der Leute, die +1 wählen, hat Flattern noch nicht einmal wirklich ausprobiert)

@sandangel ,

Ich denke, dass die Winkelvorlagensyntax der XML-Semantik folgt, und wie ich weiß, gibt es keinen Konfliktanwendungsfall zwischen der Winkelsyntax und dem XML-Dokument.

Sicher, aber JSX verwendet keinen Namensraum, daher ist dies kein interessantes XML-Feature.

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

Da Sie die „Kinder“ außer Aktion in ein eigenes Tag aufgeteilt haben, erinnert mich das irgendwie an das neue Fragment-Tag von React. Es ist sicher eine Balance zwischen Ausführlichkeit und Prägnanz.

Ich habe wirklich das Gefühl, dass das Flutter-Team die aktuelle API speziell für die neue Art der Deklaration der Benutzeroberfläche erstellt hat, von der sie annahmen, dass sie besser als JSX ist, und jede Anstrengung, die wir versuchen, die JSX-Syntax an die aktuelle API zu binden, lässt sie nur unnatürlich / unbequem aussehen.

Die Art und Weise, wie Flutter die Benutzeroberfläche im Code deklariert, ist nichts Neues. Vielleicht ist die Verwendung von DSX für Sie unnatürlich/unbequem, für JSX-Entwickler ist dies jedoch nicht der Fall. JSX/DSX ist perfekt für Flutter, es passt wie angegossen und wenn Sie keine Handschuhe mögen, gehen Sie mit bloßen Händen ;)

@ a14n ,

Das hat nichts zu bedeuten.

das geht sicher!!! Sie können mit "Gefühl", "Denken", "Verdacht", "meiner Meinung nach", "Meinung" argumentieren, aber dies sind Daten, ein konkreter Datenpunkt. Wenn die Daten nutzlos sind, sollten sie nicht gesammelt werden. Ich denke, die Daten sind nutzlos, weil sie Ihr Bild nicht malen.

@cbazza Ich meine, wenn wir versuchen, die Frage zu beantworten, die ich oben über das Erzwingen von Untertypen von Widgets für Kinder/Kinder habe, habe ich das Gefühl, dass Dart-Code einen besseren Job macht als JSX.

DSX ist kein XML, es ist XML-ähnlich, sodass es nicht der XML-Semantik folgen muss

Sicher, aber JSX verwendet keinen Namensraum, daher ist dies kein interessantes XML-Feature.

Ich bin mir nicht sicher, aber ich habe einige Ihrer Kommentare oben gelesen und ich denke, Sie haben den JSX/XML-Knoten austauschbar erwähnt. Wie auch immer, ich persönlich denke, dass die Verwendung von Namespace als Lösung nicht ideal ist.

Einfach vergleichen

<actions:children:Container>

</actions:children:Container>

und

actions: <Container>[]

Syntax.

@sandangel ,

Ja, die Tagging-Syntax ist für diesen Fall ausführlicher, und deshalb habe ich die Kurzform für Kinder als '*' erwähnt. Wie auch immer, dieser Fall ist die Ausnahme und nicht die Regel. Meistens müssen Sie nicht einmal 'Kinder' angeben, geschweige denn 'Container'; aber die Funktionalität muss vorhanden sein, um alle möglichen Anwendungsfälle abzudecken.

@a14n Abstimmung ist Abstimmung, heißt es sicher.

Ich respektiere dein Gefühl, vielleicht stimmt es. Aber selbst mit einem umgekehrten Verhältnis (1 zu 2) bedeutet das immer noch 33 % Benutzerbasis. Können Sie sagen, dass 33 % ein kleiner Anteil sind?

Leute, die eine JSX-ähnliche Erfahrung wollen

Ja, einige Leute schauen zu. Das bedeutet auch, dass _das Fehlen von JSX-ähnlichem Verhalten einer der Gründe ist, die Menschen davon abhalten, sich für Flutter zu entscheiden_.

Flutter zielt auf mehr Entwickler ab, nicht nur diejenigen, die alle Ausgaben lesen.

@jstansbe
Ich bin ein autodidaktischer Programmierer, und wie die meisten Autodidakten habe ich mit Javascript angefangen.
Dann fing ich an, React und React-Native zu lernen. Ich denke, in den letzten Jahren, besonders nach ES6, wurde OOP-Stil zu Javascript hinzugefügt.

Leute wie ich sind also nicht an den OOP-Programmierstil gewöhnt. Obwohl React native Component Klassen sind, genau wie Widgets in Flutter.

JSX verbirgt irgendwie das reine OOP-Bild. Im Grunde verbirgt es, was unter der Haube passiert. Hinweis: React wurde für Webentwickler entwickelt, und Webentwickler sind an die HTML-Syntax gewöhnt. Aus diesem Grund ist JSX unter Webentwicklern so beliebt.

Reines OOP halte ich persönlich für größere Projekte für sinnvoller.

@clarktank ,

Wenn Sie über Computersprachen sprechen, müssen Sie Folgendes beachten:
(1) Syntax – die Zeichen und Wörter, aus denen die Sprache besteht
(2) Semantik – die Bedeutung dieser Zeichen und Wörter

Beispielsweise sehen Funktionsaufrufe in vielen Sprachen wie folgt aus (dh haben die folgende Syntax):

a = someFunction(param1, param2)

Stellen Sie sich nun vor, dass eine andere Sprache entscheidet, eckige Klammern anstelle von runden Klammern für Funktionsaufrufe zu verwenden; es würde wie folgt aussehen:

a = someFunction[param1, param2]

Die Sache hier ist, dass die Syntax anders ist, aber die Semantik die gleiche ist. Ich meine, beide machen im Grunde Funktionsaufrufe, aber mit einer anderen Syntax.

JSX verbirgt irgendwie das reine OOP-Bild. Im Grunde verbirgt es, was unter der Haube passiert.

Überhaupt nicht wahr. JSX/DSX ist nur eine andere Syntax als genau dasselbe (die Semantik ist dieselbe). Im Fall von JSX erstellen XML-Tags einfach React-Komponenten (genau wie Sie es in reinem Javascript tun können). Im Fall von DSX erstellen XML-Tags einfach Flutter-Widgets (genau wie Sie es in Pure Dart tun können). Die Syntax ist anders, aber sie generiert genau dasselbe, sodass sie unter der Haube identisch ist.

Hinweis: React wurde für Webentwickler entwickelt, und Webentwickler sind an die HTML-Syntax gewöhnt. Aus diesem Grund ist JSX unter Webentwicklern so beliebt.

JSX ist beliebt, weil es eine großartige Möglichkeit ist, Komponentenbaumhierarchien zu verwalten, sei es für die Entwicklung von Web-, Mobil- oder anderen Benutzeroberflächen. Beachten Sie im folgenden Code, dass Sie nicht wissen, ob die Dropdown-Komponente beispielsweise für das Web oder für Mobilgeräte bestimmt ist.

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

Reines OOP halte ich persönlich für größere Projekte für sinnvoller.

Wie ist das? (wenn man bedenkt, dass die Verwendung von JSX/DSX oder Pure Javascript/Dart genau dasselbe unter der Haube generiert).

@cbazza

Ich habe React-Native fast ein Jahr lang verwendet und hatte keine Ahnung, dass JSX-Elemente Objekte sind, die instanziiert werden, bis ich mit Flutter/Dart anfing. Aus meiner Sicht verbirgt es das OOP-Bild, obwohl es, wie Sie sagten, semantisch dasselbe unter der Haube tut!

In großen Anwendungen könnte JSX auch so hässlich werden wie stark verschachtelte Objekte. Syntaktisch würde ich also lieber konsistent bleiben, als einen anderen Stil einzuführen, der genauso verwirrend sein könnte.

@clarktank ,

In großen Anwendungen könnte JSX auch so hässlich werden wie stark verschachtelte Objekte. Syntaktisch würde ich also lieber konsistent bleiben, als einen anderen Stil einzuführen, der genauso verwirrend sein könnte.

Für mich ist es tatsächlich ein Vorteil, wenn es anders aussieht als der Rest des Codes.

(Ich entschuldige mich im Voraus für die Textwand.)

Als jemand, der weder React-Native noch Flutter lange genug verwendet hat, um mich als definitive Quelle dafür zu betrachten, ob rohes Dart oder JSX/DSX "besser" ist, war dieser Thementhread ziemlich faszinierend zu lesen. Es gibt jedoch ein paar Dinge, auf die ich gerne meine 0,02 $ setzen würde.

Zunächst stimme ich verschiedenen Leuten darin zu, was JSX eigentlich ist und wie es Entwicklern zugute kommt. In erster Linie wurde JSX als eine Form von „dynamischem HTML“ entwickelt, das in bestehenden Javascript-Code eingebunden werden kann. Es ist unverzichtbar für JS-basierte Webplattformen wie React, da es Webentwicklern ermöglicht, sauber und effizient mit dem DOM zu interagieren, ohne sich mit dem schrecklichen nativen Weg (oder dem nur geringfügig besseren jQuery-Weg) herumschlagen zu müssen. Außerdem fördert JSX naturgemäß die UI-Entwicklung, die leicht von den zugrunde liegenden Daten entkoppelt werden kann, wodurch eine gut organisierte Projektstruktur gefördert wird. In dieser Umgebung ist JSX ein Werkzeug, um eine höhere Produktivität zu ermöglichen, und ich denke, dass es praktisch unmöglich wäre, dem zu widersprechen.

Wie sich dieser Absatz auf React-Native bezieht, ist, dass es, obwohl es sich um eine mobile Entwicklungsplattform handelt, direkt von React abstammt. Daher wurden fast alle Syntax und Paradigmen noch ursprünglich mit Blick auf die Webentwicklung erstellt. Das ist beabsichtigt - RNs ganzer Trick ist, dass Sie "plattformübergreifende mobile Apps mit React erstellen" können, also soll es sich _angeblich_ wie Webentwicklung anfühlen, wenn Sie es verwenden. RN-Apps sind auch überwiegend in Javascript geschrieben, daher ist die Einbeziehung von JSX eine naheliegende. JSX unterstützt die RN-Entwicklung aus fast denselben Gründen wie bei der Webentwicklung. (Ich denke wirklich, dass dies ein wichtiger Grund dafür ist, dass zumindest in RN der JSX-Ansatz so viel häufiger verwendet wird als der native Ansatz. RN selbst _fühlt sich nur wie eine Webplattform an, daher geht der web-natürlichere Ansatz unweigerlich vorherrschend werden.)

Flutter hingegen hat keine solche Designphilosophie. Es soll eine rein native plattformübergreifende Lösung sein, und obwohl es angibt, dass es von React-Native inspiriert wurde, schreibt es viel mehr wie eine native Desktop- oder mobile App als eine Web-App. Es läuft auch mit Dart und nicht mit Javascript, was vom Standpunkt der Integration von etwas wie JSX aus gesehen eine wichtige Überlegung ist. Während die JS-DOM-Funktionen schrecklich ausführlich sein können (sowohl wegen des Funktionsdesigns als auch wegen der JS-Sprache selbst), erleichtert Dart als Sprache viel mehr sauberen UI-deklarativen Code, während Flutter größtenteils gute Arbeit leistet UI-Konstruktoren kurz halten. Zum anderen ( wie @sandangel betonte ) ist Dart eine statisch typisierte Sprache, so dass die Natur von JSX, die für eine dynamisch typisierte Sprache wie JS entwickelt wurde, in Fällen, in denen beispielsweise ein UI-Konstruktor eine Widget eines bestimmten Typs, die einzige Lösung, die nur zur Ausführlichkeit beiträgt. Persönlich fühlt es sich wie eine Lösung an, die im Laufe der Zeit unweigerlich zu einer aufgeblähten und schwer zu wartenden DSL führen wird, da sie einer wachsenden Anzahl von Anwendungsfällen Rechnung tragen muss, die einem System innewohnen, für das es nicht vorgesehen war benutzt für.

Daher sehe ich wirklich nicht, wie JSX/DSX die Produktivität der Flutter-Entwicklung fördern würde, abgesehen davon, dass es nur eine Frage der persönlichen Präferenz ist. Beide Syntaxen sind insgesamt ungefähr gleichwertig in der Ausführlichkeit, und wo man in bestimmten Fällen an Ausführlichkeit verliert, gleicht dies die Klarheit aus (z. B. die schließenden XML-Tags). Es läuft im Wesentlichen darauf hinaus, ob jemand mit einem weborientierten Hintergrund (React/RN, Angular usw.) oder mit einem nativen Hintergrund (Java/Kotlin/Swift, WPF/UWP usw.) zu Flutter kommt, der bestimmt, welcher Ansatz, den sie bevorzugen würden. Sogar allein in diesem Thread gibt es viele Benutzergeschichten, die sagen, dass sie anfangs extrem skeptisch gegenüber JSX waren, aber nach ein paar Monaten der Verwendung ihre Meinung geändert haben zu "kann nicht ohne". (Obwohl der zynische Teil von mir darauf hinweisen möchte, dass ihnen das Gleiche für den einheimischen Dart-Ansatz passieren könnte, wenn sie ihm eine Chance geben würden.)

Abgesehen davon kann ich mir nicht wirklich vorstellen, zuzustimmen, dass DSX offiziell vom Flutter-Team als Alternative zu nativen UI-Konstruktoren unterstützt werden sollte. Obwohl es als Lösung eines Drittanbieters vollkommen in Ordnung ist (und alle Requisiten an @cbazza für die tatsächliche Implementierung), passt es nicht wirklich zur Kernnatur von Flutter als nicht auf Webtechnologie basierende Plattform. Daher mehr Leistung für jeden, der DSX in seinen eigenen Projekten verwenden möchte, aber ich würde mich der Meinung anschließen, dass es viele andere wichtigere Dinge gibt, für die das Flutter-Team seine Zeit aufwenden könnte und sollte.

Nun, da das gesagt ist, obwohl ich nicht wirklich damit einverstanden bin, dass DSX offiziell unterstützt wird, denke ich, dass es ein offizielles UI-Format von _irgendeiner_ Art geben sollte. Wie @birkir betonte, hat fast jede große native UI-Plattform, sei es Desktop oder Mobile, zusätzlich zum direkten codebasierten Ansatz ein UI-Format (und die meisten von ihnen werden sowieso in den codebasierten Ansatz vorverarbeitet). Die Trennung von UI-Dateien und Logikdateien war schon immer der empfohlene Weg, um das MVVM-Muster anzunehmen (was mich übrigens bei JSX immer in die Irre geführt hat). Ich würde daher argumentieren, dass Flutter etwas Ähnliches hat - anstelle eines Inline-UI-DSL-Formats sollte es ein separates UI-Format haben, das dazu bestimmt ist, in eine eigene Datei abseits des Dart-Codes zu gehen.

Als Teil dieser Denkweise habe ich tatsächlich am vergangenen Wochenende an diesem Ende gearbeitet. Wenn ich einen Moment schweigen darf , ich habe ein Projekt entwickelt, das ich "FLUI" getauft habe, das mein Versuch ist, zu zeigen, wie ein solches Format aussehen könnte . Anstatt mit einer vorhandenen DSL (oder einer modifizierten Version) zu arbeiten, habe ich eine völlig neue entwickelt, die sich von YAML inspirieren lässt, und ich habe mein Bestes versucht, dem „Gefühl“ des Flutter-Konstruktor-Ansatz-Layouts nahe zu bleiben. Zugegeben, es ist eine _sehr_ frühe Implementierung, daher erwarte ich nicht wirklich, dass es keine massiven Probleme gibt, aber ich habe die Quelle für das Prozessorskript (in C#/.NET Standard geschrieben) hinzugefügt, damit die Leute spielen können damit, wenn sie wollen. :)

Sowohl als React/RN- als auch als Flutter-Benutzer bin ich mit der Idee von „DSX“ nicht einverstanden.

DSX würde nichts bringen. JSX wird in React verwendet, weil die JS-Syntax schrecklich ist. Aber im Fall von Flutter ist das Erstellen von Widgets super einfach.

Der Klassiker:

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

Es ist bereits sofort lesbar, leicht zu schreiben, typ-/generisch kompatibel und ohne unnötige Duplizierung.

Die einzige Beschwerde, die Sie möglicherweise mit der aktuellen Syntax haben könnten, ist "Es ist schwer zu wissen, wo sich die schließende Klammer eines Widgets befindet."

Aber andererseits löst das Dart-Plugin der offiziell unterstützten IDEs dieses Problem. Wenn wir also den Code von vorher in sagen wir vscode öffnen, werden wir sehen

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

Wie für "Es ist schwer, gelegentlichen Code von UI-Code zu unterscheiden", gelten die Reaktionsregeln auch für Flattern:

Widgets sollten entweder dumm oder intelligent sein. Intelligente Widgets haben keine UI-Logik. Dumme Widgets haben nichts als UI-Logik.

Wenn Sie diesem Muster folgen, sollten Sie niemals in eine Situation geraten, in der Sie die Benutzeroberfläche nicht von den anderen unterscheiden können.
Dies gilt umso mehr, wenn Sie einem BLoC-Muster folgen; die die Trennung von Business und UI stark erzwingen.

JSX wird in React verwendet, weil die JS-Syntax schrecklich ist

Sehr eigensinnige Aussage und einfach nicht wahr.

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

Sehr eigensinnige Aussage und einfach nicht wahr.

Es gibt viele nicht benötigte Zeichen in der Standardreaktionssyntax.
Vergleichen wir die Wortwiederholung und die Anzahl der Zeichen für jede Syntax (ohne Funktionsdefinition, Einrückung und 'Rückkehr').

Ohne JSX reagieren:

• 133 Zeichen, davon 3 Klammern, 3 Klammern, 3 : , 4 , und 11 Leerzeichen
• React.createElement zweimal geschrieben

JSX:

• 104 Zeichen, mit 2 Klammern, 3 Klammern, 1 : , 4 <> und 5 Leerzeichen
• Container und Text zweimal geschrieben

Pfeil:

• 99 Zeichen, mit 2 Klammern, 4 : , 3 , und 4 Leerzeichen
• Keine Wiederholung

In Bezug auf die Zeichen ist der offensichtliche Gewinner hier die Dart-Syntax.

Jetzt müssen wir auch andere Dart-Besonderheiten berücksichtigen.

Dart gibt Single Child vs. Multi Child ein, hat const Konstruktoren und erlaubt Generika und sogar positionierte Parameter. JSX unterstützt nichts davon.

Ein paar Beispiele, die schlecht in JSX konvertiert werden würden:

Nicht immer children :

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

OR

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

const Konstruktor für das Widget selbst

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

Generika

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

positionierte Requisiten:

Text("foo")

Benannter Konstruktor

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

Builder (Dart unterstützt keinen Union-Typ, daher kann children nicht sowohl ein Widget als auch eine Funktion sein)

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

@rrousselGit

Wie bereits mehrfach erwähnt, ist DSX einfach anders
Syntax und es ist eine Obermenge von Dart, also alles, was Sie damit machen können
Dart können Sie es in DSX tun. Sie können auch beides kombinieren
Syntaxen, wie Sie es für richtig halten. Offensichtlich hast du nicht einmal nachgesehen
heraus, was einige der DSX-Funktionen sind, die zur Unterstützung entwickelt wurden
Pfeil:
https://spark-heroku-dsx.herokuapp.com/index.html

-1---------------------------------------
Im Dart:

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

OR

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

Im DSX:

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

OR

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

-2---------------------------------------
Im Dart:

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

Im DSX:

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

-3---------------------------------------
Im Dart:

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

Im DSX:

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

  }}
  child={child}
/>

-4---------------------------------------
Im Dart:

Text("foo")

Im DSX:

<Text ["foo"]/>

-5---------------------------------------
Im Dart:

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

Im DSX:

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

-6---------------------------------------
Im Dart:

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

Im DSX:

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

Aber dann ist das Argument, eine einfachere Umwandlung von Reagieren zu Flattern zu haben, hinfällig. Da sich JSX radikal von Ihrem Prototyp unterscheidet:

<MyAppBar>
    <title:Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    </title:Text>
</MyAppBar>

Und keines Ihrer Beispiele hier oder von Ihrem Link vereinfacht den Code tatsächlich oder verbessert die Lesbarkeit

So sehr ich mich auf Ihr Gefühl beziehen kann, JSX zu vermissen (das Gleiche beim Starten von Flattern), nach einiger Erfahrung fühlt sich die native Syntax eigentlich ziemlich gut an

Als Randnotiz gibt es eine viel bessere Lösung für Ihre Trennung von Bedenken. Das ist eine Vorlagendatei
Sie könnten eine xml/yaml-Datei neben Ihrem Widget haben. Und dann verwenden Sie die fantastischen Tools zur Codegenerierung, die dart bietet.

Ich bevorzuge lieber eine:

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

kombiniert mit a

// main.xml
<strong i="19">@theme</strong> ThemeData

<Container  color={@theme.cardColor} />

die dann mit einem benutzerdefinierten Code-Gen die folgende Dart-Datei generiert:

part of 'main.dart';

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

Das Endergebnis ist sogar besser als ein "DSX" für die Trennung von UI/Logik. Es ist auch besser für potenzielle UI-Generatoren. Und es ist viel einfacher zu implementieren mit built .

Da sich JSX radikal von Ihrem Prototyp unterscheidet:

Wirklich !!! Das einzig Radikale in diesen Diskussionen war die Reaktion der Neinsager.

Wie es im Titel dieses Tickets heißt, ist DSX JSX-ähnlich, es ist nicht JSX-identisch, sonst hätte es JSX heißen sollen; und die Ergänzungen dazu sind geringfügig und bieten Entwicklern Optionen.

Du könntest es schreiben wie:

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

Hummmm, Sie scheinen "Trennung von Bedenken" mit "Trennung von Technologie" zu verwechseln. Diese Dinge sind sehr unterschiedlich; Das Trennen von Dart-Code und Markup-Code in verschiedenen Dateien ist einfach eine „Trennung der Technologie“ und bietet keinen der Vorteile der „Trennung von Anliegen“. Ein Problem wäre hier eine Komponente/ein Widget, das wiederverwendbaren Code sauber kapselt, es spielt keine Rolle, dass innerhalb dieser Komponente/dieses Widgets unterschiedliche Technologien verwendet werden.

Auch das Trennen von Technologien, wie Sie es empfehlen, ist JSX/DSX, das die Hostsprache für alle seine zwingenden Konstrukte (für Schleifen, Funktionsaufrufe, if-Anweisungen usw.) verwendet, stark unterlegen.

Nach vielen hier geposteten Codes und Beispielen ( insbesondere ) komme ich zu dem Schluss, dass JSX im Gegensatz zu DSX und Dart viel mehr Wert zu JS hinzufügt. Aber ein Feature ist aus meiner Sicht sehr wichtig: Closing Tags. Mögen:

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

reduziert viel kognitive Komplexität in tiefen Strukturen wie hier im Gegensatz zu:

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

Aber gut, wenn Sie es so verwenden:

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

es gibt einen kleinen Gewinn.

Wie im Titel dieses Tickets angegeben, ist DSX JSX-ähnlich, aber nicht JSX-identisch

Sie haben mein "Aber dann ist das Argument, eine einfachere Umwandlung von Reagieren zu Flattern zu haben, ungültig."

Die Hälfte der Argumente für DSX lautet „JSX ist beliebt bei React, das brauchen wir auch hier“. Aber Sie schlagen etwas anderes (und komplexeres) als JSX vor.
Bei der anderen Hälfte geht es darum, die Benutzeroberfläche vom Code zu trennen. was eine Vorlagendatei auch kann.

Auch das Trennen von Technologien, wie Sie es empfehlen, ist JSX/DSX, das die Hostsprache für alle seine zwingenden Konstrukte (für Schleifen, Funktionsaufrufe, if-Anweisungen usw.) verwendet, stark unterlegen.

Nicht wahr. Sie könnten if und so etwas in Ihrer Vorlagendatei tun. Sehen Sie sich cshtml oder eckige Vorlagen an.

Das Ding ist eine Template-Datei, die man, sofern man schon einen Parser dafür hat, in weniger als einer Woche voll funktionsfähig zum Flattern umsetzen könnte.
Sei es yaml, xml, cshtml oder html mit Direktiven.

Während ein DSX viel Arbeit erfordern würde.

@Bessonov Sie haben kürzlich virtuelle Kommentare zu unterstützten IDEs hinzugefügt, um das schließende Tag zu simulieren.

In Ihrem Vscode sehen Sie also Folgendes:

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

Die Vorteile des Schließens von Tags. Ohne sie eingeben zu müssen

@rrousselGit

Sie haben kürzlich virtuelle Kommentare zu unterstützten IDEs hinzugefügt, um das schließende Tag zu simulieren.

Ja, das habe ich im zitierten Kommentar gesehen. Aber es ist nicht dasselbe. Dies führt zu einer Ausrichtungsverschiebung und stört den Lesefluss. Und das hilft mir nicht in anderen IDEs und Textverarbeitungsprogrammen.

Das Ding ist eine Template-Datei

IMHO-Vorlagen leiden unter NIH-Syndrom. Ich sage nicht, dass der Ansatz, PHP und HTML zu mischen, der richtige Weg ist, dies zu tun. React zeigt aber mit JSX, wie es besser geht.

@rrousselGit

Sie haben mein "Aber dann ist das Argument, eine einfachere Umwandlung von Reagieren zu Flattern zu haben, ungültig."

Nein, ich habe den Kommentar überhaupt nicht verpasst, es macht einfach keinen Sinn, dass Sie mir sagen, dass Leute, die von JSX kommen, DSX zu komplex finden werden.

Die Hälfte der Argumente für DSX...

Es gibt viele Gründe, sich für DSX zu entscheiden, aber mit Alternativen wählen die Leute aus welchen Gründen auch immer sie bevorzugen, was sie bevorzugen.

Nicht wahr. Sie könnten if und stuff in Ihrer Vorlagendatei tun. Sehen Sie sich cshtml- oder Winkelvorlagen an.

Das Ding ist eine Template-Datei, die man, sofern man schon einen Parser dafür hat, in weniger als einer Woche voll funktionsfähig zum Flattern umsetzen könnte.
Sei es yaml, xml, cshtml oder html mit Direktiven.

Während ein DSX viel Arbeit erfordern würde.

Ganz im Gegenteil, DSX implementiert nur 2 XML-Transformationen und erhält alles andere kostenlos von der Hosting-Sprache. Stellen Sie sich den Aufwand vor, der versucht, die Leistungsfähigkeit von Dart in Ihrer neuen Vorlagensprache neu zu implementieren. Nein danke, ich nehme Dart.

Nein, ich habe den Kommentar überhaupt nicht verpasst, es macht einfach keinen Sinn, dass Sie mir sagen, dass Leute, die von JSX kommen, DSX zu komplex finden werden.

Gleiches gilt für die aktuelle Dart-Umsetzung.

Jedenfalls glaube ich nicht, dass wir uns hier gegenseitig überzeugen können. Also werde ich nur ein paar weitere Gründe auflisten, warum ich JSX im Flattern nicht mag, und dann "warten und sehen".

1. Die Widget-Erstellung unterscheidet sich von React

Im Gegenzug ist es die Bibliothek, die die Erstellung von Komponenten übernimmt. JSX ist in Ordnung, weil es sagt: "Kümmere dich nicht darum, wie die Dinge funktionieren. Wir erledigen die Dinge für dich".

Beim Flattern ist das nicht der Fall. Wir instanziieren bei jedem Build-Aufruf manuell ein neues Widget. Dies ist wirklich wichtig zu verstehen, und JSX würde es weniger klar machen.

Und in Fortsetzung dieser Logik:

2. Die Leute denken vielleicht, dass <Foo /> etwas Besonderes tut, was new Foo() nicht tut

<Foo /> in einer Methode fühlt sich besonders an. Es scheint, als würde es etwas Fremdes tun, das in das Framework eingebaut ist. Was in React zutrifft, wo Komponenten in ein React.Element werden.
Dies übersetzt in reagieren in <Foo /> != new Foo() und haben keinen direkten Zugriff auf Foo .

Dies gilt nicht für Flattern und kann zu Verwirrung führen.

Ebenfalls :

<Foo>
  <Bar />
</Foo>

Als Reaktion darauf wird Bar niemals instanziiert, wenn Foo sein untergeordnetes Element niemals verwendet. Und Foo wird instanziiert, nachdem die Methode render zurückkehrt.
Beim Flattern ist dies umgekehrt. Sowohl Bar als auch Foo werden sofort erstellt

Dies würde möglicherweise dazu führen, dass React-Entwickler nicht optimierten Flutter-Code erstellen.

3. Im Allgemeinen ist Dart/Flattern nicht JS/react

Wenn wir JSX in Dart hinzufügen, kann ich bereits die Probleme mit Type Union sehen oder tun können
return foo && <Component /> oder das kommende asynchrone Rendering in React.
Begründet mit einem "Wir haben bereits JSX, also können wir das auch haben!"

Ich würde eine proprietäre Syntax oder gar keine Syntax bevorzugen, um nicht die neueste JSX/React-Funktion in Dart implementieren zu müssen

4. JSX macht einige Dart-Besonderheiten unklar

Ein kleines Beispiel, Scaffold erfordert für appbar einen PrefferedSizeWidget .
Wenn wir Scaffold mit JSX erstellt haben, würden die Leute erwarten, dass Sie jedes beliebige JSX durch ein anderes ersetzen können. Was nicht wahr ist

Ich meine, es macht es sehr unklar, warum wir das tun können

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

aber nicht

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

@rrousselGit

Jedenfalls glaube ich nicht, dass wir uns hier gegenseitig überzeugen können. Also werde ich nur ein paar weitere Gründe auflisten, warum ich JSX im Flattern nicht mag, und dann "warten und sehen".

Ich bin mit vielem, was Sie gesagt haben, nicht einverstanden, aber ich weiß Ihre Bemühungen zu schätzen, da Sie sich die Zeit nehmen, gründlich über das Thema nachzudenken.

1. Die Widget-Erstellung unterscheidet sich von React

Für mich spielt es keine Rolle, weil dies nur ein Implementierungsdetail ist, konzeptionell, sobald Sie etwas XML sehen, in React ist es eine Komponente, in Flutter ist es ein Widget.

1. Völker mögen denken macht etwas Besonderes, was new Foo() nicht tut

Ich denke, die Leute werden ziemlich schnell lernen, dass Dart/DSX nicht Javascript/JSX ist.

1. Generell ist Dart/Flatter nicht JS/React

Ja, wir einigen uns endlich auf etwas, aber obwohl sie unterschiedlich sind, ist der gemeinsame Nenner, dass es sich um deklarative UI-Frameworks handelt, und ich denke, dass deklarative Baumstrukturen mit JSX/DSX gut gehandhabt werden. Es hält Sie an der Denkweise der deklarativen Programmierung fest.

Wenn wir JSX in Dart hinzufügen, kann ich bereits die Probleme mit der Typunion sehen oder in der Lage sein, return foo && <Component /> oder das bevorstehende asynchrone Rendering in Reaktion zu bringen.
Begründet mit einem "Wir haben bereits JSX, also können wir das auch haben!"

Wir fügen JSX nicht in Dart hinzu, wir fügen DSX hinzu, es ist anders, hat aber Ähnlichkeiten mit JSX und Vertrautheit ist eine große Sache.

Ich würde eine proprietäre Syntax oder gar keine Syntax bevorzugen, um nicht die neueste JSX/React-Funktion in Dart implementieren zu müssen.

Warum verwenden Sie also mit dieser Argumentation Dart? es sieht Java ziemlich ähnlich und ist doch anders als Java; zum Teufel damit, lassen Sie uns all diese Java-Schlüsselwörter und -Konzepte verwerfen und uns etwas einfallen lassen, das Erland vage ähnelt, das Sie nur mit einer Hand programmieren können, während Sie eine Brezel-Yoga-Bewegung auf dem Gipfel des Mount Everest machen ;)

1. JSX macht einige Dart-Besonderheiten unklar

Nicht wirklich, wenn Sie unvergleichliche Widgets verbinden, spuckt der Dart-Compiler Fehlermeldungen aus, als ob Sie es in normalem Dart getan hätten. Ich kann nicht genug betonen, dass DSX einfach dünner syntaktischer Zucker ist, es gibt keine Magie, nur eine unterschiedliche Syntax zum selben Ding.

@cbazza Ich habe Stunden damit verbracht, Ihre Beiträge zu lesen, und ich schätze Ihre Bemühungen zu diesem Thema sehr. Aber ich denke, es ist (irgendwie) einfach, den Streit zu beenden. Denken Sie daran, dass Flux die offizielle State-Management-Lösung für React war, aber jetzt jeder Redux verwendet? Und wie viele Navigationsbibliotheken gibt es für React-Native? Erstellen Sie einfach ein DSX-Repo und lassen Sie die reagierenden Entwickler einspringen.

@rrousselGit

Ich habe noch nie die Syntax part / part of in Dart gesehen und habe Probleme, eine Dokumentation dafür zu finden. Ist es etwas, das Dart/Flutter offiziell unterstützt? Ich würde so etwas gerne in FLUI verwenden.

@cbazza

Mit der DSX-Begründung dreht man sich immer im Kreis. DSX ist nicht JSX. DSX ist JSX-ähnlich. DSX soll eine vertraute Syntax für React-Entwickler sein. DSX ist nur denken syntaktischer Zucker für Dart. Die Leute werden lernen, dass DSX nicht JSX ist. (Und so weiter.)

Während ich verstehe, was Sie mit all diesen Erklärungen sagen wollen, denke ich, dass die Tatsache, dass Sie sie immer wieder machen müssen, ein großes Problem in Bezug auf die Natur von DSX im Allgemeinen offenbart, und es ist ein Punkt, den rrouselGit ebenfalls angesprochen hat. Auch wenn Sie immer wieder sagen, dass DSX _nicht_ JSX ist, werden Leute, die es finden, denken, dass es so ist, und das ist ein Problem. JSX und die Leute, die es verwenden, stammen aus einem Ökosystem, das sich konzeptionell auf grundlegender Ebene so sehr von Dart/Flutter unterscheidet. Daher ist es nicht unbedingt eine gute Sache, ein Feature für "Vertrautheit" zu entwickeln. Einer der offensichtlicheren Gründe dafür ist, wie bereits erwähnt wurde, dass die Leute so etwas versuchen werden:

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

Da sie von Javascript/JSX stammen, erwarten sie, dass diese Syntax in DSX funktioniert. Wenn dies nicht der Fall ist, wird es zu einem Punkt kognitiver Dissonanz, der ihr Interesse nicht nur an DSX, sondern an Flutter als Ganzem _verletzen_ kann. Vertrautheit ist vorteilhaft, wenn sie als Mittel verwendet wird, um Menschen an etwas Neues heranzuführen, aber das kann ein zweischneidiges Schwert sein – wenn 90 % der Funktionen gleich sind, können die restlichen 10 % nur dazu dienen, zu frustrieren und zu ärgern.

Ein weiteres Problem mit DSX ist, dass es in naher Zukunft wahrscheinlich keine nahtlos integrierte Funktion sein wird, unabhängig davon, ob es sich um ein Plug-in eines Drittanbieters handelt oder ob es offiziell von Flutter übernommen wird. Wie Sie selbst gesagt haben, benötigt es nicht nur vom Flutter-Team, sondern auch vom Dart-Team offizielle Unterstützung, damit es wirklich mit dem Debugging- und Deployment-Prozess von Flutter funktioniert. Andernfalls würde DSX ohne Vorverarbeitung und Werkzeugunterstützung nur mit externen manuellen Konvertierungstools funktionieren, was nur ein weiterer (möglicherweise langwieriger) Schritt ist, den Entwickler durchlaufen müssen.

Während ich das hier schreibe, ist mir noch etwas eingefallen. Es gab mehrere Pro-JSX-Leute in diesem Thread, die JSX gelobt haben und sagten, dass der „Separation of Concerns“-Ansatz beim UI-Design wirklich der einzige Weg ist, wie sie jemals wieder in Betracht ziehen werden, UIs zu entwickeln. Wenn das der Fall ist, warum ist React das einzige Framework mit Marktpräsenz, das es verwendet? Sowohl native als auch plattformübergreifende mobile App-Frameworks sind bei ihren Storyboards, ihren XML-Dateien, ihren XAML-Dateien und anderen solchen UI-Definitions-DSTs geblieben. Sogar andere beliebte JS-Frameworks wie Angular und das aufstrebende Vue verfolgen immer noch den Ansatz der „Trennung von Technologien“. React-Entwickler sprechen davon, dass JSX der Weg der Zukunft ist, aber ich habe noch nie gesehen, dass es irgendwo anders als in React in einem Framework auftaucht, das wirklich Anklang gefunden hat.

@andrewackermann

part / part of ist eine bestehende Dart-Funktion. Es verbindet irgendwie zwei Dateien zu einer. Wird normalerweise zur Codegenerierung verwendet.

Es gibt einige reale Szenarien, die eine solche Technik verwenden. Wie json_serializable , das eine toJSON -Methode und eine fromJSON -Factory für Klassen basierend auf ihren Eigenschaften generiert.

part / part of allein machen eigentlich nichts. Der interessante Teil ist, wenn Sie es mit etwas wie source_gen kombinieren .

@sunnyqm

Ich glaube nicht, dass das Einfügen von Code in ein Repo mein Problem lösen würde, da es bei dem aktuellen Problem darum geht, DSX richtig in Flutter-Tools zu integrieren, um eine großartige Entwicklererfahrung mit Debugger, automatischer Vervollständigung usw. bei der Arbeit an .dsx-Dateien zu bieten.

Benutzern zu sagen, dass sie DSX verwenden können, aber keinen Debugger verwenden oder die automatische Vervollständigung genießen können, ist für mich ein Nichtstarter. Wenn jemand helfen möchte, muss ich einen Weg finden, Dart Tools und dem VS Code Dart-Plug-In vollständige Vorverarbeitungsunterstützung (mit Source Map) hinzuzufügen ist eine Obermenge von Dart, kompiliert aber alles bis hinunter zu Dart) würde einfach funktionieren.

@andrewackermann

Ich muss mich für nichts rechtfertigen, ich bin sehr zuversichtlich, dass DSX ein Hit wird, und allein für dieses Ticket interessieren sich fast 100 Leute dafür.

Andernfalls würde DSX ohne Vorverarbeitung und Werkzeugunterstützung nur mit externen manuellen Konvertierungstools funktionieren, was nur ein weiterer (möglicherweise langwieriger) Schritt ist, den Entwickler durchlaufen müssen.

Der DSX-Transpiler ist unglaublich schnell und kann .dsx-Dateien schneller in .dart-Dateien umwandeln, als Sie blinken können, sodass die Geschwindigkeit kein Problem darstellt. Ich versuche nur, die Feature-Parität zu erreichen, um es für die Leute zu einem Kinderspiel zu machen, DSX zu verwenden.

Wenn das der Fall ist, warum ist React das einzige Framework mit Marktpräsenz, das es verwendet? Sowohl native als auch plattformübergreifende mobile App-Frameworks sind bei ihren Storyboards, ihren XML-Dateien, ihren XAML-Dateien und anderen solchen UI-Definitions-DSTs geblieben.

Erstellen Sie einfach eine Zeitleiste und Sie werden die Entwicklung der Benutzeroberfläche sehen. Die Entwicklung von Android und iOS auf ihre derzeitige Art und Weise begann vor über 10 Jahren, sodass 10 Jahre alte Techniken verwendet werden (völlig zwingende Techniken). Die reaktiven (deklarativen) UI-Entwicklungstechniken begannen vor etwa 8 Jahren für das Web zu erscheinen. React erschien vor 5 Jahren und war das erste Reactive-Framework, das Technologien nahtlos mit JSX kombinierte. Vue ist jetzt das neueste Reactive-Framework, das die älteren Techniken der „Trennung von Technologien“ unterstützt, aber auch JSX unterstützt. Auf Mobilgeräten ist Flutter das Neueste und verwendet Reactive-Framework-Techniken wie React und könnte DSX genauso nutzen wie Vue JSX. Vue tötet Angular, weil es den Entwicklern Wahlmöglichkeiten bietet und nicht übermäßig eigensinnig ist.

Das Problem mit separaten Vorlagendateien besteht darin, dass die imperativen Programmierkonstrukte dort (if, for loop usw.) im Vergleich zu dem, was in der für die Geschäftslogik verwendeten Programmiersprache verfügbar ist, so schwach sind. Die Kombination der beiden, wie es JSX tut, ist für mich eindeutig die Zukunft.

React-Entwickler sprechen davon, dass JSX der Weg der Zukunft ist,

Es ist !!!

aber ich habe es noch nirgendwo anders als in React in einem Framework gesehen, das wirklich Anklang gefunden hat.

Vue verwendet JSX

@cbazza

Ich muss mich für nichts rechtfertigen, ich bin sehr zuversichtlich, dass DSX ein Hit wird, und allein für dieses Ticket interessieren sich fast 100 Leute dafür.

Ich sage nicht, dass Sie sich für irgendetwas rechtfertigen müssen. Damals, als du darauf bestanden hast, dass das Flutter-Team diesen Vorschlag aufgreift und selbst umsetzt, ja, hätte ich gesagt, du hättest eine ganze Menge zu rechtfertigen. Jetzt, wo Sie versuchen, es selbst zu tun, können Sie tun, was immer Sie wollen, für jede Rechtfertigung, die Sie für ausreichend halten, und für mehr Macht für Sie. Ich nenne nur die Gründe, warum ich sehe, dass es vielleicht nicht so einfach oder so beliebt ist, wie Sie zu denken scheinen, und ich lege Ihnen den Ball ins Feld, um ihnen die Stirn zu bieten.

Der DSX-Transpiler ist unglaublich schnell und kann .dsx-Dateien schneller in .dart-Dateien umwandeln, als Sie blinken können, sodass die Geschwindigkeit kein Problem darstellt. Ich versuche nur, die Feature-Parität zu erreichen, um es für die Leute zu einem Kinderspiel zu machen, DSX zu verwenden.

Ich gehe davon aus, dass Sie es an dieser Stelle bisher auf UIs und Apps getestet haben, die eine triviale Größe haben. Was ist mit nicht-trivialen? Was ist mit denen, die in Grenzfälle fallen? Auch die tatsächliche Zeit, die der Prozess benötigt, ist nicht der einzige relevante Teil – allein die Tatsache, dass der Entwickler eine weitere Checkliste mit manuellen Aktionen durchgehen muss, bevor er mit dem Bauen beginnen kann, ist für viele Menschen schon abschreckend genug.

Außerdem müssen Sie den Quellcode des Projekts noch veröffentlichen, sodass niemand Ihren Prozess durchgehen, Ihre Ergebnisse überprüfen und Verbesserungen vorschlagen konnte. An diesem Punkt kann Sie wirklich nur jeder beim Wort nehmen, dass es sowohl bequem als auch leistungsfähig ist.

Vue verwendet JSX

Ich benutze Vue jetzt seit fast einem Jahr, und in dieser Zeit habe ich eine ganze Reihe von Open-Source-Projekt-Repos durchgesehen, um zu sehen, wie verschiedene Dinge gemacht werden. Obwohl ich mich keineswegs als Vue-Meister betrachte, möchte ich sagen, dass ich in keinem einzigen von ihnen JSX tatsächlich verwendet habe - die Leute scheinen den .vue -Ansatz (template -script-styling) über den Render+JSX-Ansatz. Ich wusste selbst nicht, dass Vue JSX unterstützt (zumindest über ein Babel-Plugin), bis ich nach Ihrer Antwort die Vue-Dokumentation durchsucht und im Abschnitt Renderfunktion einen winzigen Informationsausschnitt darüber entdeckt habe.

Aber das ist irrelevant für meine Gesamtaussage. Vue ist immer noch ein Javascript-Framework. Flutter ist es mit Sicherheit nicht. Daher gibt es viele Gründe, die JSX zum neusten und großartigsten Ding in einer Javascript-zentrierten Umgebung machen, die sich nicht in Dart+Flutter übersetzen lässt, von denen viele bereits in diesem Thread behandelt wurden.

Es ist !!!

Bis ich sehe, dass es sich in einer Nicht-Javascript-Entwicklungsumgebung durchsetzt, werde ich respektvoll widersprechen.

Vue verwendet JSX

Vue spec hat eine Vielzahl von Verwendungen. JSX ist einfach "da". Aber es ist nicht die vorherrschende Syntax
Sie könnten JSX an Angular anschließen, wenn Sie wollten. Obwohl es niemand tut

React-Entwickler sprechen davon, dass JSX der Weg der Zukunft ist,
Es ist !!!

Ein großer Kandidat für die Zukunft sind Web-Komponenten. Und sie werden direkt in HTML verwendet, ähnlich wie in Angular oder der gängigsten Form von Vue

@andrewackermann

Allein die Tatsache, dass der Entwickler eine weitere Checkliste mit manuellen Maßnahmen durchlaufen muss, bevor er mit dem Bauen beginnen kann, ist für viele Menschen schon abschreckend genug.

Wer hat was von manuellen Aktionen gesagt? Habe ich mich nicht klar ausgedrückt, dass ich versuche, eine vollständige nahtlose IDE-Integration (bestmögliche Benutzererfahrung für Entwickler) zu erhalten?

Außerdem müssen Sie den Quellcode des Projekts noch veröffentlichen, sodass niemand Ihren Prozess durchgehen, Ihre Ergebnisse überprüfen und Verbesserungen vorschlagen konnte.

Wie hat das etwas mit Leuten zu tun, die DSX verwenden? Ich benutze JSX seit über 2 Jahren und könnte mich nicht weniger für den Quellcode interessieren. Müssen Sie sich den Quellcode des Dart-Compilers ansehen, um in Dart programmieren zu können?

Was ich sagen möchte, ist, dass ich in keinem einzigen von ihnen JSX tatsächlich verwendet habe - die Leute scheinen den .vue-Ansatz (Template-Script-Styling) massiv dem Render + JSX-Ansatz vorzuziehen.

JSX ist eine neue Ergänzung, daher wird es einige Zeit dauern, bis es sich verbreitet, aber der wichtige Punkt ist, dass Vue andere Ansätze akzeptiert, ohne Entwickler zu zwingen, „den richtigen Weg und den einzigen Weg“ zu verwenden, damit die Dinge in Vue erledigt werden sollten.

Vue ist immer noch ein Javascript-Framework. Flutter ist es mit Sicherheit nicht.

Riiiiight, also statt JSX nutzt man DSX mit Flutter.

@rrousselGit

Ein großer Kandidat für die Zukunft sind Web-Komponenten.

Webkomponenten sind Zoobies, tot, aber immer noch am Laufen; Sie sind so weit verbreitet wie Kängurus in Kanada. Ich könnte tagelang weitermachen, aber um nicht abzuschweifen...
https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/

@cbazza

Wer hat was von manuellen Aktionen gesagt? Habe ich mich nicht klar ausgedrückt, dass ich versuche, eine vollständige nahtlose IDE-Integration (bestmögliche Benutzererfahrung für Entwickler) zu erhalten?

Sie sagten auch, dass Sie dafür Unterstützung bei der Vorverarbeitung durch das Flutter/Dart-Team benötigen. Liege ich da falsch?

Wie hat das etwas mit Leuten zu tun, die DSX verwenden? Ich benutze JSX seit über 2 Jahren und könnte mich nicht weniger für den Quellcode interessieren.

JSX wurde von Facebook für React entwickelt, einem strengen Vorschlags-/Design-/Implementierungs-/Iterationsprozess unterzogen und dann Jahre, bevor Sie es in die Hände bekamen, in die Welt entlassen. Es wurde rigoros getestet und hat sich immer wieder in realen Umgebungen bewährt. Es ist eine ausgereifte Technologie. Es gibt keinen Grund, für so etwas ein Datenblatt zu verlangen.

DSX hingegen wird heute von Ihnen und einer Handvoll Leuten entwickelt. Sie haben eloquent darüber gesprochen, was es kann und kann, aber alles, was wir tatsächlich _gesehen_ haben, ist eine kleine Handvoll speziell erstellter Codeschnipsel und Ihr Wort, dass sie vom Transpiler generiert wurden. Leute, die es sogar ausprobieren wollen und mögliche Änderungen oder Verbesserungen vorschlagen, können dies nicht, also haben sie keinen Grund, Ihre Bemühungen über "Yay JSX!" hinaus zu unterstützen.

Ich beschuldige Sie nicht der Lüge oder so etwas, ich sage nur, dass JSX ein Maß an Vertrauen erworben hat, das DSX nicht hat. Wie wollen Sie also einige Köpfe verdrehen, wenn Sie die Leute nicht daran herumbasteln lassen?

JSX ist eine neue Ergänzung, daher wird es einige Zeit dauern, bis es sich verbreitet, aber der wichtige Punkt ist, dass Vue andere Ansätze akzeptiert, ohne Entwickler zu zwingen, „den richtigen Weg und den einzigen Weg“ zu verwenden, damit die Dinge in Vue erledigt werden sollten.

JSX ist jetzt seit fast 2 Jahren in Vue. Und im Gegensatz zu Vue selbst ist JSX eine bereits vorhandene Technologie, die keiner Einführung bedarf, insbesondere für Personen, die mit React vertraut sind. Wenn JSX die Vue.js-Welt im Sturm erobern würde, kann ich nicht umhin zu glauben, dass dies bereits geschehen wäre. (Vor allem, wenn es Anzeichen dafür gibt, dass so viele Leute nach JSX in Flutter schreien, wie Sie behaupten.)

Riiiiight, also statt JSX nutzt man DSX mit Flutter.

JSX und DSX sind das gleiche syntaktische Konzept. Das Problem ist, dass, wo JSX auf einer schwach typisierten dynamischen Sprache wie JavaScript aufgebaut wurde, DSX auf einer stark typisierten statischen Sprache wie Dart aufgebaut wird. Das bedeutet, dass es viele Probleme gibt, die DSX berücksichtigen muss, die JSX nicht musste, wenn es etwas anderes als eine Nischenimplementierung von „JSX für Flutter“ sein soll, und es werden einige _geniale_ Modifikationen erforderlich sein, damit DSX wirklich funktioniert ohne es zu aufgebläht zu machen, um die Behauptung zu rechtfertigen, dass es visuell prägnanter ist.

Und um die Widerlegung "DSX ist nur Dart, wenn DSX etwas nicht kann, verwenden Sie einfach Dart" anzusprechen, dann wäre meine Gegenwiderlegung, wenn ich immer wieder auf Dart zurückgreifen müsste, wenn ich auf ein Szenario stoße, das DSX nicht tut nicht handhabe, warum sollte ich dann nicht die ganze Zeit Dart benutzen?

Und um auf die Gegenargumente für diese Lesart „Du kannst, wenn du willst, DSX ist nur eine Option“ einzugehen, dann verkaufst du dich wirklich unter Wert. Auch wenn es wirklich nur "eine Option" sein soll, muss es dennoch etwas auf den Tisch bringen, das die Leute davon überzeugt, es zu benutzen. Sie selbst haben gesagt, dass DSX nicht JSX ist, also werden Leute, die nur JSX wollen, nicht bekommen, was sie wollen. Das bedeutet, dass es einige handfeste Gründe geben muss, die über den „JSX-ähnlichen Reiz“ hinausgehen, damit die Leute es verwenden wollen.

Wenn Sie nur ein Tool bauen, das Sie selbst verwenden möchten, dann ist das alles strittig und Sie können verrückt werden. Aber wenn Sie tatsächlich etwas bauen, das andere verwenden sollen, dann müssen Sie es in eine solide Form bringen, warum Sie denken, dass sie es sollten.

Webkomponenten sind Zoobies, tot, aber immer noch am Laufen; Sie sind so weit verbreitet wie Kängurus in Kanada. Ich könnte tagelang weitermachen, aber um nicht abzuschweifen...

Etwas off-topic, aber ich möchte darauf hinweisen, dass Webkomponenten wirklich ein vielversprechender Blick in die Zukunft sind, auch wenn die Unterstützung für sie langsamer als tar hinzugefügt wird. Stellen Sie sich das so vor: React tut, was es tut, weil es im Wesentlichen die Idee von Webkomponenten nur in Javascript implementiert. Stellen Sie sich vor, wie viel besser es wäre, wenn diese Funktionen vom Browser unterstützt würden und von der Leistung ohne Sandbox profitieren würden und nicht durch DOM-Manipulation arbeiten müssten? (Zugegeben, es könnte noch 20 Jahre dauern, bis wir es herausfinden, aber trotzdem ...)

@andrewackermann

Tut mir leid, Alter, ich habe nicht die Zeit, endlos zu streiten und zu wiederholen, was ich vorher gesagt habe, immer und immer wieder; Wir werden uns sowieso nicht einigen, also viel Glück mit deinem FLUI.

Sie haben eloquent darüber gesprochen, was es kann und kann, aber alles, was wir tatsächlich gesehen haben, ist eine kleine Handvoll speziell erstellter Codeschnipsel und Ihr Wort, dass sie vom Transpiler generiert wurden.

Der Online-DSX-Transpiler ist seit Februar 2018 live und jeder kann ihn verwenden, sodass Sie sich nicht auf mein Wort verlassen müssen. Drücken Sie 'Compile' und es kompiliert, was auf der linken Seite geschrieben ist, und platziert die Ergebnisse auf der rechten Seite. Öffnen Sie den Debugger und Sie sehen den ausgeschriebenen AST.
https://spark-heroku-dsx.herokuapp.com/index.html

Das Problem ist, dass, wo JSX auf einer schwach typisierten dynamischen Sprache wie JavaScript aufgebaut wurde, DSX auf einer stark typisierten statischen Sprache wie Dart aufgebaut wird.

Es macht überhaupt keinen großen Unterschied, wie das OOP-Konzept (Object Oriented Programming) und die Syntax für "Klassen". Es ist fast identisch in typlosem Javascript oder typisiertem Dart; Dasselbe gilt für 'if'-Anweisungen, 'for'-Anweisungen usw

es muss immer noch etwas auf den Tisch bringen, das die Leute davon überzeugt, es zu verwenden.

Anscheinend tut es das schon für 100 Personen in diesem Ticket; und das ist 100-mal größer als nur ich, wenn ich es benutze; gut genug für mich.

@cbazza

Tut mir leid, Alter, ich habe nicht die Zeit, endlos zu streiten und zu wiederholen, was ich vorher gesagt habe, immer und immer wieder; Wir werden uns sowieso nicht einigen, also viel Glück mit deinem FLUI.

Ich streite nicht nur um des Arguments willen oder wegen einer tiefsitzenden Anti-JSX-Voreingenommenheit mit Ihnen. Ich versuche, Sie dazu zu bringen, Fragen zu beantworten, die beantwortet werden müssen. Sie entwickeln ein Tool, das Sie vermutlich für andere verwenden möchten, haben aber immer noch keinen überzeugenden Grund angegeben, _warum_ sie es verwenden sollten, abgesehen von den vagen und subjektiven Vorteilen von "Vertrautheit" und "weil es besser ist". Ersteres ist, wie ich bereits sagte, nicht unbedingt eine gute Sache, und letzteres ist noch eine Behauptung ohne greifbare Unterstützung.

Wenn Sie möchten, dass Ihr Tool ein Erfolg wird, muss es in Stein gemeißelt sein, was Sie tun und warum Sie es tun, und Sie müssen dies so tun, dass es anderen leicht vermittelt werden kann. Das soll nicht heißen, dass Sie ein Produkt erst herstellen können, wenn es _allen_ gefällt, aber klare und prägnante Ziele sind entscheidend für die Gestaltung und Umsetzung. Andernfalls werden Sie nur mit einem richtungslosen Dienstprogramm enden, das bestenfalls ein Nischenprodukt sein wird und sehr glücklich sein wird, wenn es in Produktionscode jeglicher Größenordnung endet.

Der Online-DSX-Transpiler ist seit Februar 2018 live und jeder kann ihn verwenden, sodass Sie sich nicht auf mein Wort verlassen müssen. Drücken Sie 'Compile' und es kompiliert, was auf der linken Seite geschrieben ist, und platziert die Ergebnisse auf der rechten Seite. Öffnen Sie den Debugger und Sie sehen den ausgeschriebenen AST.

Ich habe nicht einmal gesehen, dass dieser Link ein funktionierendes Beispiel ist. Ich habe Herokuapp noch nie zuvor verwendet und es sah nur nach einem Kernstück oder so aus, also liegt das an mir. :P

(Obwohl ich darauf hinweisen möchte, dass das Basteln an einer Online-Sandbox nicht dasselbe ist wie das Testen des Transpilers in einer praktischeren Umgebung.)

Es macht überhaupt keinen großen Unterschied, wie das OOP-Konzept (Object Oriented Programming) und die Syntax für "Klassen". Es ist fast identisch in typlosem Javascript oder typisiertem Dart; Dasselbe gilt für 'if'-Anweisungen, 'for'-Anweisungen usw

Sie mussten sich bereits mit einem solchen Unterschied beim starken Tippen von Kindern auseinandersetzen. Was ist mit der starken Typisierung von Attributen? Was ist mit Widgets in verschiedenen Bibliotheken mit demselben Namen? Was passiert, wenn jemand ein Widget mit mehr als einem namenlosen Positionsargument erstellt? Was passiert, wenn wir zwei Bibliotheken importieren, die Widgets mit demselben Namen haben? Was passiert in einem Szenario, an das ich nicht gedacht habe, taucht auf, um den inhärenten Unterschied zwischen Systemen wie Javascript und Dart weiter zu demonstrieren? Ich muss sagen, dass Sie in diesem Diskussionspunkt so leichtfertig sind, dass ich mir Sorgen um die Langlebigkeit von DSX in einer realen Umgebung mache.

Anscheinend tut es das schon für 100 Personen in diesem Ticket; und das ist 100-mal größer als nur ich, wenn ich es benutze; gut genug für mich.

Auch hier sind es 100 Personen, die das Thema auf der Grundlage von „Consider JSX-like syntax inside dart code“ positiv bewertet haben. Sie haben dafür gestimmt, weil sie _JSX_ wollen, und wie Sie so gerne betont haben, ist DSX nicht JSX. Warum sonst sollten sie DSX verwenden? Weil die Inline-XML-ähnliche UI-Deklaration "die Zukunft" ist? Wieder sehe ich es einfach nicht.

Wir haben bereits darüber gesprochen, dass JSX in Vue keine Traktion bekommt, aber es gibt auch die beiden React-Alternativen, die in dem von Ihnen verlinkten Webkomponenten-Artikel erwähnt werden: Inferno und Preact. Soweit ich das beurteilen kann, haben beide in der JS-basierten Web-App-Entwicklungswelt überhaupt keine Wellen geschlagen, obwohl sie auch nativ JSX-ähnliche Syntax unterstützen. Ich denke wirklich, dass die Leute genau darüber nachdenken müssen, _warum_ Leute JSX in React mögen, denn nach allem, was man hört, scheint es einfach nicht an JSX selbst zu liegen. Wenn _diese_ Frage beantwortet werden kann, dann können wir uns auf "zukünftige" Innovationen zubewegen, anstatt einfach nur dieses eine Feature aus dieser einen Bibliothek, die uns gefiel, überall dort einzusetzen, wo wir persönlich denken, dass es sein sollte.

Wenn ich nur daran denke, wie viel Energie allein in diese Diskussion investiert wurde und was hätte gut gemacht werden können, um die derzeitigen Rahmenbedingungen zu verbessern, macht mich das traurig.

@andrewackermann

Das Problem ist, dass, wo JSX auf einer schwach typisierten dynamischen Sprache wie JavaScript aufgebaut wurde, DSX auf einer stark typisierten statischen Sprache wie Dart aufgebaut wird.

Tut mir leid, aber das ist kein Problem. Außerdem macht das überhaupt keinen Sinn. Außerdem verwenden wir JSX mit TypeScript.

@escamoteur absolut!

@escamoteur Ich bin da bei dir. _Die 100._

@Bessonov

Tut mir leid, aber das ist kein Problem. Außerdem macht das überhaupt keinen Sinn. Außerdem verwenden wir JSX mit TypeScript.

React wurde nicht für TypeScript entwickelt. Es wurde für Javascript entwickelt. Alle Widget-Definitionen, Attribute, Eigenschaften und alles andere wurde für die Verwendung in der dynamischen Umgebung von JavaScript entwickelt, sodass die Typsicherheit von TypeScript keine neuen Faktoren für die Interaktion von JSX mit React einführt. Dies ist ein weiteres Beispiel dafür, wie JSX für eine völlig andere Umgebung als Flutter entwickelt wurde.

@andrewackermann
Warum denkst du, dass es wichtig ist? JSX ist eine Möglichkeit, eine Schnittstelle zu beschreiben. Es ist von sich aus sprachagnostisch. Schau hier . Es ist kein JavaScript. Aber warum geht das nicht mit JSX? (Außerdem gibt es davon (noch) keine Implementierung)

Und ... weißt du ... Flow kommt auch von fb:

Flow ist ein statischer Typechecker für JavaScript.

Bitte hören Sie auf, Argumente für und gegen Erweiterungen zu verkaufen, die Sie nie verwenden. Ich benutze JSX jeden Tag und bin zufrieden damit ATM, obwohl ich sehr skeptisch war. Ich kann mir vorstellen, dass sich JSX in anderen Mustern entwickelt, wie es bei AngularJS der Fall war.

Und vielleicht hilft dieses Thema, bessere Muster für Dart zu finden? DSX ist nur ein Vorschlag. Sehen Sie sich das obige Beispiel für das Builder-Muster oder andere hier vorgestellte Sprachoptimierungen an. Und, naja, vielleicht ist deine Grippe ein besserer Weg? Ich weiß nicht. Aber lasst es uns herausfinden und uns gegenseitig helfen, ihre Vorschläge zu verbessern, anstatt über schlechte Dinge in den Vorschlägen anderer zu diskutieren.

Ich möchte vorschlagen, dieses Thema zu schließen und ein neues übergeordnetes Thema mit begrenzter Konversation zu eröffnen. Alle Vorschläge zur Verbesserung der Art und Weise, wie Flatter verwendet werden kann, in eigenen Themen sachlich mit Liebe und ohne Hass diskutieren.

Ja, die Menge an Hass hier ist episch, bedenke nur Folgendes:
Es gibt 3587 offene Tickets, wenn Sie sie nach "Daumen runter" sortieren, erhalten Sie
1 (dieser) mit 57 "Daumen runter"
3586 (andere Tickets) mit 1 oder weniger "Daumen runter"

@Bessonov

Warum denkst du, dass es wichtig ist? JSX ist eine Möglichkeit, eine Schnittstelle zu beschreiben. Es ist von sich aus sprachagnostisch. Schau hier. Es ist kein JavaScript. Aber warum geht das nicht mit JSX? (Außerdem gibt es davon (noch) keine Implementierung)

Es ist eine Möglichkeit, die Benutzeroberfläche _in Javascript_ zu beschreiben (daher der "JS"-Teil des Namens). Und nein, da es sich um ein Inline-DSL handelt, ist es _nicht_ sprachunabhängig. Und selbst wenn es so wäre, macht es das immer noch nicht zur "besseren Wahl", da es viele wirklich sprachagnostische DSLs gibt, die für UI-Deklarationen völlig unzureichend wären.

Und ... weißt du ... Flow kommt auch von fb:

Flow ist genau wie TypeScript: ein statisches Typprüfungssystem für Javascript. Es ist weder ein React-Tool, noch wurde React dafür entwickelt, damit verwendet zu werden. React ist in erster Linie eine Javascript-Bibliothek, und JSX wurde für die Verwendung mit React entwickelt. Welche sekundären Tools und Dienstprogramme auch immer in die React-Entwicklung eingeführt werden, ist letztendlich irrelevant für die React+JSX-Interoperabilität.

Bitte hören Sie auf, Argumente für und gegen Erweiterungen zu verkaufen, die Sie nie verwenden. Ich benutze JSX jeden Tag und bin zufrieden damit ATM, obwohl ich sehr skeptisch war. Ich kann mir vorstellen, dass sich JSX in anderen Mustern entwickelt, wie es bei AngularJS der Fall war.

Ich habe JSX verwendet, und obwohl ich eine persönliche Meinung dazu habe, habe ich diese Meinungen bewusst aus dieser Diskussion herausgelassen. Hätten Sie meine vorherigen Kommentare gelesen, wüssten Sie tatsächlich, dass ich JSX dafür gelobt habe, dass es die UI-Entwicklung in React revolutioniert hat. Abgesehen von einigen leicht tangentialen Kommentaren, die ich über die Marktdurchdringung von JSX als Ganzes gemacht habe, beziehen sich meine Argumente speziell auf JSX _in Flutter_. Und zu diesem Thema gibt es keine praktische Grundlage, um die Wirksamkeit von DSX zu bestimmen, also können wir nur untersuchen, wie JSX an anderen Orten implementiert wurde, und diese Untersuchung verheißt nicht allzu viel Gutes.

Es sei denn natürlich, Sie verwenden DSX ebenfalls jeden Tag und können uns die praktischen Vorteile der Verwendung von DSX in Flutter erläutern?

Und vielleicht hilft dieses Thema, bessere Muster für Dart zu finden? DSX ist nur ein Vorschlag. Sehen Sie sich das obige Beispiel für das Builder-Muster oder andere hier vorgestellte Sprachoptimierungen an. Und, naja, vielleicht ist deine Grippe ein besserer Weg? Ich weiß nicht. Aber lasst es uns herausfinden und uns gegenseitig helfen, ihre Vorschläge zu verbessern, anstatt über schlechte Dinge in den Vorschlägen anderer zu diskutieren.

_Das mache ich gerade._ DSX wird als UI-Lösung für Leute vorgeschlagen, die mit JSX vertraut sind. Es gibt wichtige Designelemente in JSX, die für eine völlig andere Umgebung als Dart und Flutter gedacht waren. _Diese Unterschiede müssen angegangen werden, damit DSX erfolgreich ist._ Ich bin kein _Hasser_. Ich versuche, eine konstruktive Diskussion zu fördern und die wichtigen Fragen zu stellen. Doch alle Antworten, die ich erhalten habe, liefen auf subjektive Tautologie hinaus ("JSX ist gut, weil es die Zukunft ist, und es ist die Zukunft, weil es gut ist"), abweisendes Handwinken mit entscheidenden Designpunkten ("DSX muss nicht Rechenschaft ablegen für Unterschiede zwischen JS und Dart, weil es keine gibt") oder einfach nur feindselig ("Sie mögen JSX offensichtlich nicht, also hören Sie auf, über DSX zu reden").

Nur mit reinem Lob macht man kein erfolgreiches Produkt. Es muss auch der Kritik standhalten und Rechenschaft ablegen. Leute, die auftauchen und sagen: „OMG, ja, bitte, mach DSX“, sind zwar erhebend, aber nicht hilfreich. Es gab mehrere Personen in diesem Thread, die vollkommen berechtigte Kritik an DSX geäußert haben, sowohl an seinem ursprünglichen Design als auch an dem Konzept als Ganzes. Und zum größten Teil müssen viele dieser Kritikpunkte noch direkt angesprochen werden, wobei die allgemeine Haltung ablehnend ist.

Meine einzige Befürchtung ist, dass all diese bedingungslose Liebe zu JSX die Leute davon abhält, DSX objektiv zu betrachten. Ich verstehe, warum ihr so ​​etwas wie JSX in Flutter wollt, und ich kann es nachvollziehen – meine Meinung, dass Flutter eine dedizierte UI-DSL benötigt, hat mich dazu veranlasst, flui zu entwickeln. Aber wenn die einzigen Leute, denen es erlaubt ist, über DSX zu sprechen, diejenigen sind, die nur Gutes darüber zu sagen haben, dann _wird_ es scheitern.

Können wir die Diskussion auf dieses Thema fokussieren?
Tatsächlich sehe ich keinen Grund, dieses Thema offen zu halten.

Dart Team gab an, dass sie andere Prioritäten haben. Und die professionelle JSX-Seite hat sich bereit erklärt, ihre eigene DSX-Implementierung zu erstellen

Vielleicht sollten wir einfach ein paar Open-Source-Repositorys haben, die verschiedene Lösungen vorschlagen (auch wenn sie kaum funktionieren). Wie DSX oder Vorlagen.
Und ziehen Sie dann in Betracht, von Flutters readme oder awesome_flutter zu diesen Repos umzuleiten. Und wenn irgendetwas eine DSX-Implementierung blockiert, erstellen Sie ein weiteres Problem mit den Einzelheiten.

Dann lass die Community ihre Arbeit machen.

Lassen Sie es offen, da die Leute weiterhin neue Tickets eröffnen werden, die nach JSX fragen (wie es bereits zweimal vorgekommen ist).

Lassen Sie es offen, da die Leute weiterhin neue Tickets eröffnen werden, die nach JSX fragen (wie es bereits zweimal vorgekommen ist).

Der Unterschied besteht hier darin, dass wir jetzt wie folgt antworten könnten:

„Wir haben vorerst nicht vor, dies in Dart/Flatter zu implementieren. Aber Sie können sich die Community-Alternativen [hier] und [dort] ansehen oder [diese Ausgabe] lesen.“

und schließen Sie das Problem als Duplikat.

Ein Ort für Kommentare und Abstimmungen und das ist hier. Die Anfrage nach JSX-ähnlicher Funktionalität geht nicht weg und das Ticket wird geöffnet, weil es Unterstützung für Flutter-Tools benötigt (Compiler & VS Code IDE) und ich habe die Ticketanfrage mit diesen Informationen aktualisiert (erster Kommentar). Wenn eine enorme Anzahl von Leuten danach fragt, wird dies dem Flutter-Team einen Anreiz geben, Ressourcen dafür einzusetzen.

Es sieht so aus, als ob sich die meisten Kontroversen hier zu diesem Zeitpunkt nicht um JSX drehen, sondern um DSX. Ich würde vorschlagen, die DSX-Diskussion in einen eigenen Thread aufzuteilen und diesen allgemein JSX zu überlassen.

Letztendlich ist DSX nur eine Möglichkeit, JSX etwas näher zu kommen, also sollten wir diese beiden Diskussionen nicht in einem Thread vermischen.

Großes Nein dafür, ich denke wirklich, dass nur 1 Sprache ein großer Gewinn ist, jsx-Syntax wird mit mehr Dingen wie der Trennung von xml von js usw. kommen ... Nicht gut.

das ist meine Meinung.

Das ist das längste und sinnlose Github-Problem, das ich je gesehen habe.

@cbazza Gute Arbeit 👍
DSX+1

@BarryYan , danke

Bitte vermeiden Sie diese Art von Kommentaren, sei es "+1" oder "Danke".
Dies sendet eine E-Mail an alle Abonnenten für nichts Interessantes.

Bitte vermeiden Sie diese Art von Kommentaren, sei es "+1" oder "Danke".
Dies sendet eine E-Mail an alle Abonnenten für nichts Interessantes.

Nichts Interessantes für dich !!!
Bitte vermeiden Sie es, anderen zu sagen, was sie sagen oder tun können, und konzentrieren Sie sich nur auf das, was Sie sagen oder tun können.

@cbazza

Alter, das ist grundlegende Etikette. Jede neue Nachricht in diesem Thread sendet eine E-Mail an alle, die ihn abonniert haben, daher ist es unhöflich, einen Kommentar zu posten, der nicht zur Diskussion beiträgt, weil er die Leute ohne Grund ärgert. Grundlegende Reaktionen wie „+1“ und „Danke“ können mit einer einfachen „Daumen hoch“-Reaktion übermittelt werden, also tun Sie das einfach.

Abgesehen davon, wenn sich dieser Thread wirklich darauf verlagert hat, darüber zu streiten, ob jemand eine „+1“-Nachricht posten sollte oder nicht, ist das ein großes Warnsignal, dass alle konstruktiven Diskussionen offiziell gestorben sind und wirklich geschlossen werden sollten (vielleicht dauerhaft). diesmal).

@andrewackermann ,

Verstanden, aber wenn Sie schon dabei sind, sollten Sie vielleicht auch die grundlegende Etikette berücksichtigen, während Sie diesen Thread mit Ihren Romanen (langes und fiktives Schreiben) in die Luft jagen.

Bitte hören Sie auf, FUD (Angst, Ungewissheit & Zweifel) mit Ihrem Spray-and-Pray-Sperrfeuer sinnloser Fragen (Sie wissen, so viel Mist an die Wand zu werfen und zu sehen, ob etwas kleben bleibt) und Forderungen zu verbreiten.

Nach all Ihren Schriften haben Sie DSX keinen Mehrwert gebracht, daher habe ich kein Interesse daran, mit Ihnen über dieses Thema zu diskutieren. Ihr Motiv ist jedoch offensichtlich, werben Sie für FLUI, während Sie DSX sprengen.

Sagen Sie mir etwas, haben Sie Antworten auf Ihre eigenen Fragen, wenn sie auf FLUI angewendet werden? Lassen Sie uns ein bisschen über FLUI diskutieren, oder?

@cbazza

Verstanden, aber wenn Sie schon dabei sind, sollten Sie vielleicht auch die grundlegende Etikette berücksichtigen, während Sie diesen Thread mit Ihren Romanen (langes und fiktives Schreiben) in die Luft jagen.

Die Tatsache, dass Sie sich auf meine Antworten beziehen, dass ich viel Zeit und Mühe investiert habe, um sie so gut durchdacht und unvoreingenommen wie möglich zu machen, als „langes und fiktives Schreiben“, verdeutlicht viel über Ihren Charakter und Ihre Herangehensweise diese Diskussion. Ich versuche, Diskussionen über sehr reale Probleme im Zusammenhang mit der Implementierung von JSX in Flutter anzuregen, während Sie jeden mit jeder Form von gegensätzlicher Meinung beschimpfen. Wer von uns ist der größere Übeltäter der grundlegenden Etikette?

Bitte hören Sie auf, FUD (Angst, Ungewissheit & Zweifel) mit Ihrem Spray-and-Pray-Sperrfeuer sinnloser Fragen (Sie wissen, so viel Mist an die Wand zu werfen und zu sehen, ob etwas kleben bleibt) und Forderungen zu verbreiten.

Das einzige, was ich „verlange“, ist, dass Sie die zahlreichen Probleme, die von vielen Leuten bezüglich DSX angesprochen werden, mit mehr als nur einer Handbewegung oder offener Feindseligkeit ansprechen. Für jemanden, der eine signifikante Änderung/Ergänzung des Funktionsumfangs von Flutter vorschlägt, halte ich das für keine unangemessene Erwartung.

Nach all Ihren Schriften haben Sie DSX keinen Mehrwert gebracht, daher habe ich kein Interesse daran, mit Ihnen über dieses Thema zu diskutieren. Ihr Motiv ist jedoch offensichtlich, werben Sie für FLUI, während Sie DSX sprengen.

Ich bitte _you_, Ihre Position zu verteidigen. Sie haben wiederholt gesagt, dass JSX/DSX die beste Zukunft ist, müssen aber noch erklären, wie oder warum. Mehrere Leute haben berechtigte Bedenken zu DSX geäußert, aber anstatt sie anzusprechen, winken Sie ab, indem Sie sich hinter dem Gegenargument „wenn Sie es nicht mögen, verwenden Sie es nicht“ verstecken. Mein "Motiv" ist, Sie dazu zu bringen, Fragen zu beantworten, die bezüglich _irgendeines_ technischen Projekts gestellt werden müssen, in erster Linie, warum Leute es jemals anstelle von Alternativen verwenden sollten. (Und wie ich bereits erklärt habe, ist Vertrautheit kein ausreichender Grund.)

Soweit es FLUI betrifft, schlage ich lediglich eine alternative Lösung für das Gesamtproblem vor (deklarative UI-Syntax für Flutter) und fordere die Leute auf, das Gleiche zu tun, was ich mit DSX tue – aufrichtige und konstruktive Kritik. Ich sage nicht, dass FLUI objektiv besser ist als DSX – ich schlage eine Alternative vor, die sich aus einem anderen Ansatz zur UI-Entwicklung ergibt, und bitte die Leute, sich ihre eigene Meinung zu bilden.

(Ich möchte auch darauf hinweisen, dass ich abgesehen von meiner anfänglichen Erwähnung, in der ich einen möglichen alternativen Ansatz zur GUI-Darstellung vorschlug, das einzige Mal, dass ich überhaupt über FLUI gesprochen habe, war, als Sie es angesprochen haben. Also, wie funktioniert es? macht es Sinn, dass mein Hintergedanke darin besteht, es zu fördern, wenn Sie mehr darüber sprechen als ich?)

Sagen Sie mir etwas, haben Sie Antworten auf Ihre eigenen Fragen, wenn sie auf FLUI angewendet werden? Lassen Sie uns ein bisschen über FLUI diskutieren, oder?

FLUI ist nicht DSX - es muss nicht _jede_ Frage beantworten, die ich Ihnen bezüglich DSX gestellt habe, da viele von ihnen spezifisch für das Design von DSX sind. Das heißt aber nicht, dass es keine eigenen Fragen gibt, die beantwortet werden müssen, und nein, ich habe nicht alle diese Antworten. Das ist _warum_ ich kritische Diskussionen schätze - FLUI/DSX werden dem Gericht der öffentlichen Meinung nicht standhalten, wenn sie es nicht überleben können, ein paar Mal über die Kohlen geharkt zu werden. Dies ist jedoch nicht der geeignete Ort, um FLUI zu diskutieren. Wenn Sie ausführlich über FLUI diskutieren möchten, hat das Projekt ein eigenes Issue-Board , also zögern Sie nicht, dort zu posten.

Anstatt auf Kritik zu reagieren, waren Sie stattdessen defensiv und ausweichend, so sehr, dass Sie direkt für die zwei getrennten Fälle (annähernd drei) verantwortlich sind, in denen dieser Thread vorübergehend geschlossen werden musste, weil die Dinge zu heiß wurden. Ich breche also mit der "Etikette" und sage einmal: Legen Sie Ihr Ego ab, interpretieren Sie keine Kritik mehr als persönlichen Angriff und beantworten Sie die wichtigen Fragen. Entweder das, oder Frieden mit DSX schließen, das nie vom Boden abhebt.

andrewackerman Gute Arbeit 👍
+ 1

@andrewackermann

Gut gemacht

Alter, du bekommst ein Kompliment von @jstansbe , das viel mehr Informationen vermittelt als ein Daumen nach oben und ein Daumen nach unten für das Kompliment?

Offensichtlich haben Sie sich meinen Hinweis auf die Länge nicht zu Herzen genommen, aber ziehen Sie keine Schlüsse über meinen Charakter, weil Sie mich überhaupt nicht kennen.

Die Tatsache, dass Sie sich auf meine Antworten beziehen, dass ich viel Zeit und Mühe investiert habe, um sie so gut durchdacht und unvoreingenommen wie möglich zu machen

Das schätze ich und ich lese all Ihre 'langen Schriften' und beantworte alles: Auf keinen Fall, aber wenn ich richtig antworte, verstehen Sie meine Antwort nicht und schließen daraus, dass ich abweisend bin.

Es ist für mich offensichtlich, dass Sie mit JSX nicht sehr erfahren sind, Sie verstehen wirklich nicht, wie es funktioniert. Anstatt also zu verdoppeln, besitzen Sie es einfach und ich werde es ausführlicher erklären. Zum Beispiel führt JSX & DSX nur die folgenden 2 Transformationen durch (mehrmals zuvor erwähnt):

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

Alles andere wird von der Wirtssprache gehandhabt, also zum Beispiel: wie handhabt sie den Import von gleichnamigen Komponenten; Antwort: Wirtssprache. Ich bin nicht abweisend, es ist die Art und Weise, wie es entworfen wurde und die Quelle seiner Stärke. Sie sehen, wenn Sie Markup und Programmierung in separate Dateien trennen, beginnen Sie, die Programmierung innerhalb des Markups mit einfachen Konstrukten für „if“ usw. zu duplizieren. Am Ende bauen Sie eine deklarative Programmiersprache innerhalb des Markups auf, die niemals so mächtig sein kann wie die Hauptprogrammiersprache. Indem Sie also das Markup in die Programmiersprache einbringen, haben Sie das Beste aus beiden Welten, und das ist die Stärke von JSX/DSX.

Beachten Sie oben bei (2), dass die Transformation <Widget> fest codiert und das nicht immer der Fall ist, also können Sie das jetzt bei Bedarf angeben, wie zuvor besprochen. Schauen Sie sich die Transformationen an und jetzt stammen alle Symbole aus der Quelle oder können angegeben werden, damit es in Zukunft keine größeren magischen Fallstricke gibt.

während Sie irgendjemanden mit irgendeiner Form von gegensätzlicher Meinung beschimpfen.

Das ist nicht wahr, Sie können eine gegenteilige Meinung haben, aber Sie können nichts Wahres behaupten, wenn ich das Gegenteil beweisen kann.

Für jemanden, der eine signifikante Änderung/Ergänzung des Funktionsumfangs von Flutter vorschlägt, halte ich das für keine unangemessene Erwartung.

Aber das ist die Sache, ich wollte, dass das Flutter-Team DSX implementiert, aber dann habe ich es getan, also müssen sie allgemeine Dinge implementieren, die nicht von DSX abhängen, und DSX ist nicht der einzige Nutznießer. Die Browser-js-Engine unterstützt Source Maps, die ein Ökosystem neuer Sprachen im Browser ermöglichten, die in js transpiliert wurden; es ermöglichte die Erstellung von Dart !!! und mehrere andere (Coffeescript, Typescript, Reason, etc). Dart könnte jetzt das Gleiche tun und von dem Ökosystem profitieren, das es hervorbringen hilft, alle Boote steigen.

Ich bitte Sie, Ihre Position zu verteidigen.

Ich habe es schon viele Male gemacht und die Schlussfolgerung ist, dass Plain Dart oder DSX von der Benutzerpräferenz abhängen; und das Wichtigste ist, eine Option anzubieten, anstatt die Menschen in eine Richtung zu zwingen.

in erster Linie, warum die Leute es jemals gegenüber den Alternativen verwenden sollten.

Ich würde DSX verwenden, weil ich es bevorzuge, wie Leerzeichen oder Tabulatoren, die Definition vor oder nach dem Variablennamen einzugeben. Es hat keinen Sinn, dafür zu kämpfen, akzeptieren Sie einfach, dass Menschen unterschiedliche Vorlieben haben; Es gibt mehr als einen Programmiereditor, richtig?

Vertrautheit ist kein ausreichender Grund

Nur Ihre Meinung, warum verwenden wir „if“-Anweisungen in fast allen Sprachen, „for“-Anweisungen, „class“ und jetzt „asyn/await“.

Dies ist jedoch nicht der geeignete Ort, um FLUI zu diskutieren. Wenn Sie ausführlich über FLUI diskutieren möchten, hat das Projekt ein eigenes Issue Board, also zögern Sie nicht, dort zu posten.

Sehr gut, jetzt hast du meinen Respekt gewonnen.

Sie sind direkt verantwortlich für die zwei getrennten Fälle (fast drei), bei denen dieser Thread vorübergehend geschlossen werden musste, weil die Dinge zu heiß wurden.

Selbst wenn es wieder geschlossen wird, wird es die Leute nicht davon abhalten, nach JSX-ähnlichen Fähigkeiten zu fragen.

Lassen Sie Ihr Ego hinter sich, interpretieren Sie Kritik nicht mehr als persönlichen Angriff und beantworten Sie die wichtigen Fragen.

Ich habe kein Ego, aber ich habe ein aufbrausendes Temperament, also gibt es keinen Zweifel, wenn mich jemand verärgert (es kommt sofort heraus). Um dich nicht zu beleidigen, aber deine Fragen waren nicht wichtig.

Entweder das, oder Frieden mit DSX schließen, das nie vom Boden abhebt.

Sie sind nicht das Maß für den Erfolg und Sie wissen nicht, was ich vorhabe.

Alter, du bekommst ein Kompliment von @jstansbe , das viel mehr Informationen vermittelt als ein Daumen nach oben und ein Daumen nach unten für das Kompliment?

Sie haben anscheinend den Sarkasmus in seinem Kommentar nicht mitbekommen. (Er hat buchstäblich alles getan, was ich gesagt habe, nicht zu tun.) Obwohl es ein lustiges Trolling ist, das ich zu schätzen weiß, ist es hier nicht angebracht. Und wenn er zufällig aufrichtig war, dann entschuldige ich mich für meine abfällige Art, aber mein Punkt bleibt bestehen - diese Art von Kommentar ist hier _noch_ nicht angebracht.

Es ist für mich offensichtlich, dass Sie mit JSX nicht sehr erfahren sind ...

Hat Sie mein Haftungsausschluss in meinem allerersten Kommentar zu diesem Thread vielleicht auf einen Tipp hingewiesen?

... du verstehst wirklich nicht, wie es funktioniert.

Sie setzen mich damit gleich, dass ich nicht viel Erfahrung mit JSX habe und dass ich überhaupt nicht weiß, wie es funktioniert? Obwohl ich noch nie an einem ernsthaften React-Projekt gearbeitet habe, habe ich meinen fairen Anteil am Basteln geleistet. Ich verstehe sehr gut, wie es _funktioniert_.

Alles andere wird von der Wirtssprache gehandhabt, also zum Beispiel: wie handhabt sie den Import von gleichnamigen Komponenten; Antwort: Wirtssprache.

Und das macht Sinn, wenn die Auszeichnungssprache und die Wirtssprache unterschiedlich sind. Bei JSX ist die Auszeichnungssprache als _Erweiterung_ der Wirtssprache konzipiert. Als solches wurde JSX als Erweiterung von JS konzipiert, und deshalb funktioniert es so gut wie es funktioniert. DSX ist eine Implementierung von JSX für Dart.

Sie sehen das Problem dort nicht? Eine Auszeichnungssprache, die als Erweiterung einer Sprache konzipiert ist und in eine grundlegend andere Sprache umgebaut wird. Es ist _unvermeidlich_, dass es eine Menge Probleme, Grenzfälle und Überlegungen gibt.

Sie sehen, wenn Sie Markup und Programmierung in separate Dateien trennen, beginnen Sie, die Programmierung innerhalb des Markups mit einfachen Konstrukten für „if“ usw. zu duplizieren. Am Ende bauen Sie eine deklarative Programmiersprache innerhalb des Markups auf, die niemals so mächtig sein kann wie die Hauptprogrammiersprache.

Erstens besteht die ganze Idee hinter der Trennung von Markup und Programmierung darin, dass, wenn Sie es richtig machen, eine klare Trennung zwischen den beiden besteht, die zu _kein_ Duplizierung führt.

Zweitens, wenn Sie etwas viel Komplexeres als if s und for s in Ihrem UI-Code machen (das sind Konstrukte, die in vielen Markup-Lösungen leicht gehandhabt werden können), dann würde ich das argumentieren Es ist sowieso ein Zeichen dafür, dass in Ihrem Design etwas nicht stimmt. Wenn Sie komplexe Logik in Ihre UI-Konstrukte integrieren, ist dies gemäß den MVC/MVVM-Designprinzipien ein potenzielles Zeichen für stinkenden Code, und Sie sollten sowieso ernsthaft über eine Neugestaltung nachdenken.

(Das soll nicht heißen, dass Sie mit JSX keine deklarative Benutzeroberfläche in der MVVM-Manier schreiben können, aber es ist nur etwas, das für wenig objektiven Gewinn Ärger einlädt. Warum etwas verwenden, in dem Sie Code schreiben _können_, der standardkonform ist, wenn Sie es verwenden können? etwas, das es schwierig macht, Code zu schreiben, der _nicht_ ist_?)

Das ist nicht wahr, Sie können eine gegenteilige Meinung haben, aber Sie können nichts Wahres behaupten, wenn ich das Gegenteil beweisen kann.

Du hast nichts "bewiesen". Sie haben eine Reihe subjektiver Behauptungen aufgestellt, die noch mit irgendeiner begründenden Logik untermauert werden müssen. (Obwohl dieser letzte Beitrag zu Ihrer Ehre eine große Verbesserung darstellt.)

Aber das ist die Sache, ich wollte, dass das Flutter-Team DSX implementiert, aber dann habe ich es getan, also müssen sie allgemeine Dinge implementieren, die nicht von DSX abhängen, und DSX ist nicht der einzige Nutznießer.

Sie verlangen immer noch, dass sie nicht triviale Dinge tun, also liegt es an Ihnen, sie und den Rest von uns davon zu überzeugen, warum sie das tun sollten und warum es so wichtig ist, dass sie andere Dinge auf ihrer To-do-Liste streichen sollten.

Die Browser-js-Engine unterstützt Source Maps, die ein Ökosystem neuer Sprachen im Browser ermöglichten, die in js transpiliert wurden; es ermöglichte die Erstellung von Dart !!!

Es liegt in der Natur von JS selbst, dass so etwas leicht machbar ist (relativ gesehen), so sehr, dass Dart bei weitem nicht die einzige Sprache ist, die einen Transpiler zu JS hat. Wie ich schon oft betont habe, ist Dart nicht JS. Es ist statisch und stark typisiert, was bedeutet, dass viele Dinge, die in JS einfach zu erledigen wären, in Dart enorm komplex sind.

Ich würde DSX verwenden, weil ich es bevorzuge, wie Leerzeichen oder Tabulatoren, die Definition vor oder nach dem Variablennamen einzugeben. Es hat keinen Sinn, dafür zu kämpfen, akzeptieren Sie einfach, dass Menschen unterschiedliche Vorlieben haben; Es gibt mehr als einen Programmiereditor, richtig?

Nach dieser Logik sollte ich eine UI-Lösung erstellen, in der Sie Konstrukte mit hexadezimal codierter Brailleschrift definieren. Ich meine, wenn alles, was wirklich zählt, persönliche Vorlieben sind, muss ich nur sagen, dass „einige Leute es bevorzugen“, um seine Existenz zu verteidigen, richtig?

Sie entwickeln ein Tool, das andere verwenden sollen, also brauchen Sie Argumente, die über „einige Leute mögen es vielleicht“ hinausgehen, um überzeugend zu wirken. Wenn Sie es nicht in Worte fassen können, _warum_ sie es über etwas anderem verwenden sollten, was lässt Sie dann glauben, dass sie es tun werden? Und was gibt es, um Sie dazu anzuregen, _sicherzustellen_, dass sie dies beim Entwerfen des DSX-Funktionsumfangs tun werden?

Nur Ihre Meinung, warum verwenden wir „if“-Anweisungen in fast allen Sprachen, „for“-Anweisungen, „class“ und jetzt „async/await“.

Erstens wurden diese Schlüsselwörter (abgesehen von async/await ) aufgrund der immensen Popularität von Sprachen wie C und BASIC im Laufe mehrerer Jahrzehnte zum allgemeinen Programmierlexikon. Wie ich bereits erwähnt habe, ist JSX in seiner Langlebigkeit alles andere als bewiesen – es gibt es seit 5 Jahren und es gibt noch keine nennenswerte Verwendung außerhalb von React, obwohl die Option verfügbar ist.

Zweitens gibt es einen großen Unterschied zwischen Vertrautheit und Konvention. if , while , for , struct , class , enum , try/catch/finally , async/await ... das sind alles großartige Möglichkeiten, ein Konzept verbal darzustellen. Es gibt Gründe, die Verwendung dieser Schlüsselwörter zu verteidigen, die darüber hinausgehen, dass sie nur das sind, womit die Leute vertraut sind – sie machen konzeptionell Sinn. (Das bedeutet natürlich nicht, dass sie Konstanten sind. Manche Sprachen machen if ... then . Manche machen if ... elif , während andere if ... else if machen und wieder andere if...endif . Manche machen foreach , andere from . Und so weiter und so fort.)

In der Zwischenzeit passt das Argument, JSX zu verwenden, weil es „vertraut“ ist, nicht in dieselbe Kategorie. JSX ist eine Möglichkeit, deklarative UI darzustellen, aber es ist weder die einzige noch die beliebteste. Darüber hinaus wurde es für die Verwendung in einer bestimmten Umgebung entwickelt, sodass die Verwendung in einer anderen Umgebung Vertrautheit in eine schlechte Sache verwandeln kann - Vertrautheit führt dazu, dass sie erwarten, dass es mehr oder weniger genau so funktioniert wie anderswo, also wenn es so ist führt das nicht zu einer mentalen Trennung, die Sie _vermeiden_ möchten.

Selbst wenn es wieder geschlossen wird, wird es die Leute nicht davon abhalten, nach JSX-ähnlichen Fähigkeiten zu fragen.

Sie fragen trotzdem danach, und das Problem wird trotzdem hierher umgeleitet. Ich sehe nicht, wie das Schließen des Threads das ändern würde.

Sie sind nicht das Maß für den Erfolg und Sie wissen nicht, was ich vorhabe.

Lies irgendein Buch über Produktdesign. In Kapitel eins geht es immer darum, eine Aussage, ein Manifest, einen Slogan, irgendetwas Greifbares und in einfachem Englisch Ausdrückbares zu erstellen, das beschreibt, was das Produkt ist und warum die Menschen sich darum kümmern sollten. Es gibt einen Grund dafür, dass die häufigste Form des Ratschlags für Amateurunternehmer darin besteht, einen „Elevator Pitch“ zu machen, etwas, das das Produkt und die Verlosung in 30 Sekunden oder weniger klar und prägnant kommuniziert. Wenn Sie nicht auf den Punkt bringen können, warum Menschen Ihr Produkt verwenden sollten, ist das ein Zeichen dafür, dass es an einer Identitätskrise leidet. Wenn der Gestalter des Produkts auf Kritik nicht angemessen reagieren kann, dann erweckt das den Eindruck von mangelndem Vertrauen in das eigene Produkt. Beides sind große rote Fahnen für Investoren.

In dieser Situation ist das Produkt DSX, und die Investoren sind Entwickler, die erwägen, es zu verwenden. Die einzigen Leute, die Sie hinter sich haben, sind Leute, die anscheinend alles mit "JSX" in der Beschreibung bedingungslos anfeuern würden. Jede andere Person in diesem Thread, die ich gefragt habe, was Sie tun, ist nach Ihrer Antwort scheinbar nicht überzeugt davongegangen.

Sie sitzen derzeit bei oder nahe einer Konversionsrate von 0 %, und _das_ ist, woher ich komme, wenn ich sage, dass Sie noch nicht angemessen auf Kritik reagieren müssen. Vielleicht ist es Ihnen egal, aber wenn Sie ernsthaft beabsichtigen, dass DSX ein UI-Deklarations-Markup-Plugin ist, das in realen Projekten verwendet und verwendet werden kann, sollten Sie vielleicht damit beginnen.

Aber andererseits sind Sie vielleicht eine Ausnahme.

Ok, diese Unterhaltung geht weit über die Art von Diskussionen hinaus, die wir in der Flutter-Community für akzeptabel halten, und deshalb werde ich diesen Thread sperren und den Fehler schließen. Bitte lesen Sie https://flutter.io/design-principles/#conflict -resolution für weitere Einzelheiten darüber, wie wir uns hier verhalten.

Wenn jemand Code zur Behebung dieses Problems beitragen möchte, wäre der nächste Schritt, ein Design für die Build-Systemintegration zu entwickeln, damit wir die Codegenerierung mit Gradle, Xcode, Hot Reload und Integration in vorhandene Apps durchführen können. Wenn jemand daran interessiert ist, daran mitzuarbeiten, zögert bitte nicht, mich zu kontaktieren. Ansonsten gehe ich davon aus, dass wir Anfang nächsten Jahres daran arbeiten werden. Sobald wir einen Mechanismus dafür haben, werden Lösungen wie DSX einfach in das Flutter-Ökosystem zu integrieren sein. Möglicherweise finden wir sogar Lösungen, die standardmäßig integriert werden sollten. In der Zwischenzeit arbeiten wir auch an Verbesserungen der Dart-Syntax, um zu sehen, ob wir das Schreiben von UI-Ausdrücken noch einfacher machen können.

Ich möchte darum bitten, dass die Leute keine neuen Fehler zu diesem Thema öffnen, es sei denn, es gibt etwas sehr Konstruktives und Neues, das es wert ist, angesprochen zu werden.