Flutter: Betrachten Sie JSX-like als React Native

Das wird schon lange gefragt:
https://github.com/flutter/flutter/issues/11609
Funktionsprototyp entwickelt:
https://spark-heroku-dsx.herokuapp.com/index.html
Das zeigt die Alternative und einige Vorteile ...

Das aktuelle Problem mit DSX dreht sich um die ordnungsgemäße Integration mit Flutter-Tools, 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.

Wenn du helfen kannst und möchtest, lass es mich wissen.

Ich kann nicht zustimmen. Insbesondere mit einer IDE wie Dart Code erhalten Sie virtuelle schließende Tags, die das Einlesen erheblich erleichtern. Mit Dart2, wo man new weglassen kann, wird es sogar noch besser.

Ich finde auch, dass es Sie davon abhält, zu große Widget-Bäume zu erstellen, ohne sie in kleinere, einfacher zu wartende Widget-Klassen zu zerlegen.

Ich verwende Android Studio. Ich sehe nicht einmal ein virtuelles schließendes Tag. Obwohl wir ein virtuelles schließendes Tag haben, ist es komplizierter als HTML, das jeder hasst. Dart ist nur eine Programmiersprache. Die Leute bei Google verstehen die Bedeutung der Vereinfachung nicht.

Ich glaube auch nicht, dass ich eine JSX-ähnliche Syntax möchte, aber ja, ich verwende IntelliJ und es muss etwas mit den Tools getan werden, damit der UI-Code leichter verständlich ist.

Ich finde auch, dass es Sie davon abhält, zu große Widget-Bäume zu erstellen, ohne sie in kleinere, einfacher zu wartende Widget-Klassen zu zerlegen.

Ich sehe nicht, wie das anders ist als bei JSX ... wenn der Baum größer wird, können Sie mit beiden in kleinere Unterbäume aufbrechen.

Ich glaube auch nicht, dass ich eine JSX-ähnliche Syntax möchte, aber ja, ich verwende IntelliJ und es muss etwas mit den Tools getan werden, damit der UI-Code leichter verständlich ist.

und es sollte auf allen Plattformen gut lesbar sein und nicht nur auf Intellij; Ich meine, es sollte einfach sein, auf Bitbucket zu lesen, wenn Code überprüft wird; und es sollte auch bei Verwendung eines beliebigen Editors gültig sein; Ich meine mit diesen "Kommentaranmerkungen", was passiert, wenn jemand, der "vi" verwendet, dort einen anderen Kommentar eingibt?

Dies ist ein Dup des gesperrten #11609
@sethladd ?

Entschuldigung, Sie sollten die "virtuellen schließenden Tags" in IntelliJ und Android Studio sehen.

cc @devoncarew , um zu überprüfen, welche Version das aktiviert hat, oder ob der Benutzer sich anmelden muss?

Wir danken Ihnen für Ihre Kommentare zu: JSX-ähnliche Syntax. Wir glauben, dass es in der Sprache, unseren Tools und Plugins Möglichkeiten gibt, die Bearbeitung von UI-Code zu vereinfachen.

Dies täuscht #11609 vor, aber ich möchte, dass @devoncarew oder @mit-mit eine Notiz darüber hinzufügen, wie "virtuelle schließende Tags" aktiviert werden können, wenn möglich.

Danke!

@JonathanSum , die abschließenden Labels sind in Android Studio 3.0 leider nicht verfügbar. Sie benötigen mindestens IntelliJ 2017.3 oder Android Studio 3.1. Android Studio 3.1 befindet sich derzeit im Release Candidate-Stadium, und wir planen, morgen ein Flutter-Plug-in mit Unterstützung dafür zu veröffentlichen.

Unabhängig von der Diskussion um eine JSX-ähnliche Syntax möchten wir daran arbeiten, das Schreiben von UI-Code in Dart zu vereinfachen, sowohl in IntelliJ / Android Studio als auch in VS Code. Das ist zunächst die abschließende Labelarbeit, aber auch die aktuelle Flutter Outline-Ansicht. Das zeigt die Struktur Ihrer build()-Methode in einer Gliederungsansicht und ermöglicht es Ihnen, durch die Widgets zu navigieren und ihre Eltern-/Kind-Beziehungen einfacher zu sehen. Das ist derzeit in IntelliJ verfügbar – wir gehen davon aus, dass wir es auch in VS Code bringen können.

@zoechi - Dies könnte ein Dup sein; aber der andere Thread wurde erhitzt und gesperrt. Sie haben also keine Möglichkeit, zu diesem Gespräch beizutragen. Ich denke nicht, dass Sie diesen Thread als Dummkopf schließen sollten, nur weil Sie es nicht mögen, wenn Leute nach einem Feature fragen. Dies sollte wahrscheinlich der neue Thread für Antworten für neue Leute sein, die kommen und JSX-Unterstützung (oder ähnliche Funktionalität) anfordern.

@sethladd - Bitte diesen Thread nicht sperren; Ich denke, dass es nützlich ist, wenn die Community die Vor- und Nachteile alternativer Layoutmethoden diskutiert. Ich hätte an #11609 teilgenommen, wenn es nicht gesperrt gewesen wäre.

Ich komme aus einem NativeScript-Hintergrund. Ich muss sagen, dass dies ein Bereich ist, in dem ich der Meinung bin, dass NativeScript erheblich einfacher zu verwenden ist als Flutter. Ich kann ziemlich komplexe Bildschirme in weniger als 5 Minuten zum Laufen bringen und das Design schnell iterieren. Fügen Sie dann den Code hinzu, der den Bildschirm ausführt.

In NativeScript haben wir tatsächlich die folgenden Dateien:

• screen.js / screen.ts (.ts wird in .js transpiliert, wenn Sie Typoskript bevorzugen). Dies ist die Hauptlogik für den angezeigten Bildschirm.
• screen.css (oder screen.android.css und/oder screen.ios.css ) ist eine viel eingeschränktere Version von CSS, unterstützt aber Dinge wie Höhe, Breite, Farbe, Hintergrund usw. Meistens Es wird nur eine einzelne CSS-Datei benötigt, aber gelegentlich, wenn Sie etwas Seltsames tun, können Sie Ihr CSS für Android und iOS trennen. Es hat volle Unterstützung für Klassen, Elemente und IDs, also kann ich TextArea.Login #Password machen und es wird sich tatsächlich auf diese spezifische Elementkette beschränken.
• screen.xml (wieder oder screen.android.xml und/oder screen.ios.xml ) - Dies ist das Bildschirmlayout. Sie können das Layout in JS codieren, wenn Sie möchten (im Grunde wie Flutter); aber das XML ist so viel einfacher. Beispiel:

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

Das Interessante ist, dass ActionBar nur eine spezifische Seitenkomponente ist (dh sie ist nur seitenspezifisch); Was also im Grunde passiert, ist die Seite des XML-Parsers See; erstellt ein neues Seitenelement; erstellt dann eine ActionBar-Komponente, die dann eine builderChild-Funktion auf der Page-Komponente ausführt; die Seitenkomponente überschreibt das standardmäßige builderChild und prüft, ob das untergeordnete Element eine ActionBar ist; wenn ja; dann weist es es intern der richtigen Variablen zu; andernfalls wird der Rest durch parent/super geleitet, der ihn dann automatisch den "child"- oder "children"-Komponenten zuweist. Das Build-System ist insofern unglaublich vielseitig, als jede Komponente entweder die builderchild-Funktion der übergeordneten Komponente verwenden oder sie überschreiben kann, um zusätzliche Elemente wie die Unterstützung <Label>Hi</Label> auszuführen und diese automatisch dem Textwert zuzuweisen. Dies macht es unglaublich einfach, das Layout ohne Code zum Laufen zu bringen.

Da die meisten Editoren eine gute XML-Bearbeitungsfunktion haben, wird es automatisch koloriert und mit der richtigen xsd-Definition intellij (& vscode) führt es eine automatische Überprüfung und eine begrenzte Kontextunterstützung durch.

Technisch gesehen ist eigentlich alles eine JavaScript-Komponente; Sie können dies alles manuell tun (wie es Flutter tut); Aber ich finde, dass das einfache Layout eines Bildschirms in NativeScript trivial ist. Und Sie brauchen weder JS noch CSS, wenn Sie anfangen; dann können Sie das CSS hinzufügen (normalerweise codieren Sie die CSS-basierten Eigenschaften nicht fest im Layout, aber Sie können, wenn Sie möchten).

Das Schöne daran; Es ermöglicht Webentwicklern, mit sehr wenig (wenn überhaupt) Umschulung direkt einzusteigen. In der Tat; Aufgrund seines flexiblen Renderers und seiner JS-Basis unterstützt NativeScript tatsächlich Angular und Vue, sodass Sie fast 95 % der Codebasis zwischen dem Web und Ihrer mobilen App teilen können, wenn Sie Angular oder Vue verwenden. Da es native Betriebssystemkomponenten wie React Native verwendet (keine Webansicht wie Cordova); Es ist wirklich ein anständiges plattformübergreifendes System (das ist meiner Meinung nach besser als React Native). Ich kann jedoch sehen, wo es einige Stärken gibt, die Flutter hat, die es zu einem guten ergänzenden Tool für einige mobile Entwicklungen machen, da es einige Apps gibt, bei denen NativeScript schlechter ist, und einige, für die es immer noch viel besser ist, und basierend auf den Antworten auf meine Ausgaben von Ian; wird in diesen Bereichen das deutlich bessere Werkzeug bleiben.

Es ist besser, diesen gesperrten Thread zu öffnen und diese Kommentare dorthin zu kopieren, damit wir eine Geschichte vollständiger Diskussionen haben.

@JonathanSum es geht nicht darum, ob jemand das Feature will oder nicht will,
Es geht darum, ob dies der Ort ist, um eine hitzige Diskussion darüber zu führen. Ich denke, Reddit oder ähnliches sind bessere Orte.

@cbazza - Ich bin nicht anderer Meinung; aber man muss in zukunft sehr aufpassen, dass man den menschen nicht unterstellt. Das entfacht nur die Diskussion, egal wie idiotisch Sie glauben, dass sie sind.

@zoechi - Eigentlich glaube ich, dass jede Diskussion über ein neues Feature hier sein sollte. Der Verlauf sollte gepflegt werden, damit John Doe, wenn er in einem Monat nach XYZ-Features sucht, :+1: ein vorhandenes Feature und/oder dazu beitragen kann.

Ich glaube nicht, dass der Thread wegen meiner Kommentare wirklich so lange gesperrt ist. Wenn das, was ich gesagt habe, so schlecht war, wie kommt es, dass ich alles andere kommentieren kann, wie zum Beispiel diesen Thread?

Der Thread ist gesperrt, weil das Flutter-Team daran kein Interesse hat und nur möchte, dass die Leute aufhören, darüber zu reden.

Lassen Sie uns die Diskussion in dieser Ausgabe bitte auf Anwendungsfälle und Beispiele für eine JSX-ähnliche Funktion konzentrieren.

Wenn NativeScript so gut ist, warum sollte man sich überhaupt mit Flutter beschäftigen, anstatt zu versuchen, Flutter wie NativeScript zu machen?
Ich komme von einer XML-basierten Plattform (Xamarin Forms) und dachte am Anfang, dass es schwieriger sein könnte, Code zu entwerfen, aber das ist nicht der Fall.
Im Gegenteil, es macht es sehr einfach, Ihr Design in separate Klassen zu zerlegen, die einfach zu warten sind.

JSX entwirft im Code !!!

@sethladd

Lassen Sie uns die Diskussion in dieser Ausgabe bitte auf Anwendungsfälle und Beispiele für eine JSX-ähnliche Funktion konzentrieren.

OK, lass uns über mein DSX-Design sprechen, das hier eingesehen werden kann:
https://spark-heroku-dsx.herokuapp.com/index.html

Es bietet eine direkte Zuordnung zur aktuellen Art und Weise, wie Widgets erstellt werden, und bietet dennoch eine JSX-ähnliche Variante, die sehr leicht und React-Entwicklern vertraut ist. Fehlt irgendetwas in diesem Design? Kann dieses Design alle möglichen Widgets in freier Wildbahn erzeugen?

Faustregel: Wenn Sie das Gefühl haben, dass ein Ausrufezeichen nicht ausreicht, sollten Sie sich wahrscheinlich von der Tastatur entfernen und eine Pause einlegen.

Ich bin ein Neuling bei Flutter und habe nur ein wenig Erfahrung mit Android und Java, und ich muss sagen, dass ich das, was Flutter bietet, viel besser finde als das, was hier vorgeschlagen wird. Ich neige dazu, zu finden, dass XML hässlich und unhandlich ist. Es ist so viel schöner, einen einzigartigen Schlusscharakter zu haben, als ein Meer vondas macht meinen Code 5x länger, ein Hass von mir beim Bearbeiten von Android XML, und nur virtuelle schließende Tags, die die überwiegende Mehrheit der IDEs, die Leute verwenden, unterstützen. Dies ist unglaublich nützlich, wenn Sie längere Strukturen entwerfen. Die ordentliche Verschachtelung von XML wiegt meiner Meinung nach die restlichen Nachteile nicht auf, besonders wenn 'child:/children:' fast genauso gute Arbeit leistet. Dart ist unglaublich sauber, und das ist ein Grund, warum ich es so sehr mag. Ich wäre unglaublich enttäuscht, wenn dies ruiniert werden würde.

Ich weiß, dass React es so macht, aber als ich das letzte Mal nachgesehen habe, sagt dieser Ort Flutter. Nur weil React es tut, heißt das nicht, dass wir es tun müssen - Sie sind nicht die Einzigen, die hierher springen! Ich stimme allen Punkten, die @escamoteur gemacht hat, sehr zu. Ich sehe keinen Sinn darin, noch eine weitere Sprache hinzuzufügen, mit der die Leute umgehen müssen, wenn sie Flutter verwenden. Wir verwenden bereits Dart, um das meiste davon zu programmieren, wir brauchen nicht viele andere Dinge zu beherrschen! Konsistenz und Einfachheit müssen geschätzt werden.

Einige Anmerkungen zu Ihren DSX vs. generierten Dart-Snippets:

1. Subjektiv: Ich sehe keine großen Lesbarkeitsgewinne. Ausführlichkeit ist ähnlich - wenn nicht ein bisschen länger. Das Dart-IDE-Plug-in bietet automatisch schließende Tags, die deklarative Markup-Endtags widerspiegeln. Wenn JSX Design in Code ist, dann sehe ich nicht, wie Widgets in Dart es nicht sind.

2. Mehrere Unterkünfte in <vars>

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

In der Lage zu sein, globale Stile zu definieren, die mehrere Eigenschaften mischen, ist eine nette Idee.
Wenn ich jedoch auf meine bescheidene Flattererfahrung zurückblicke, sehe ich nicht, wo ich diese verwenden würde.

Für Text scheint das meiste, was ich wiederverwenden muss, in TextStyle definiert zu sein, anstatt eine Mischung aus mehreren Eigenschaften zu sein. Vielleicht finden Sie ein anderes Beispiel als Text , wo das nicht der Fall ist.

Wenn ich mir TextStyle , finde ich das aktuelle unveränderliche + copy() großartig für die Wiederverwendung und Komposition in Dart:

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

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

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

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

Für wiederverwendbare Container , die denselben Stil teilen, denke ich, dass das Erstellen eines benutzerdefinierten zustandslosen Widgets besser funktioniert als ein extern definiertes <vars> . Meistens möchte ich auch eine Polsterung, eine Tinte, einen Gestenhörer oder einen Schatten.

Für jeden dieser Fälle müsste ich Container mit einem anderen Widget zusammenstellen: Material , Padding , Center usw. Wenn ich also ein benutzerdefinierte wiederverwendbare "Container"-Widgets, sehe ich keinen großen Vorteil darin, einen externen <vars> -Stil zu haben, der nur die Eigenschaften eines einzelnen Widgets in meiner wiederverwendbaren Widgets-Hierarchie definieren würde.

Ich sehe nicht, dass Flutters „Alles ist ein Widget“ gut mit „Mehrere Eigenschaften“-Stilen funktioniert.

1. In Ihren aktuellen DSX-Beispielen nicht hervorgehoben: Wie würden Sie eine Schnittstelle mit dynamischen Widgets codieren? Bedeutung: wie einige Widgets abhängig von einer Bedingung angezeigt oder nicht angezeigt werden.

Beim Designen in Dart ist es einfach und bequem, ein bestimmtes Widget zu children hinzuzufügen oder nicht.
Es ist auch sehr praktisch, ein Widget dynamisch mit einem anderen zu umschließen. Es macht die build()-Funktion flüssig und leicht verständlich.

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

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

    children.add(wb);

@SirComputer1 Der DSX-Vorschlag ist eine Ergänzung, der aktuelle Weg ändert sich nicht. Wenn Sie ihn also nicht mögen, verwenden Sie ihn nicht, sondern machen Sie so weiter wie bisher.

Das <var> -Ding wurde nur für die Demo gemacht, weil ich Dart nicht vollständig parsen wollte. Die endgültige Lösung würde <var> nicht enthalten, sondern eine beliebige dart-Variable verwenden. Auch das '@' wurde nur für die Demo verwendet, um das Parsen zu vereinfachen. Die endgültige Lösung würde es nicht beinhalten.

Vergessen Sie nicht, dass alles andere in der Datei Ihr normaler Dart-Code ist, den Sie also für alles andere verwenden können.

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

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

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

    children.add(wb);

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

Hören wir auf, DSX mit dem aktuellen Weg zu vergleichen, das eine konkurriert nicht mit dem anderen. Einige Leute werden JSX bevorzugen und dieser Thread ist für sie. Was ich wissen möchte, ist, wie ich DSX verbessern kann, um Dinge zu handhaben, für die es nicht funktioniert.

@escamoteur - Ich benutze normalerweise keinen Hammer als Schraubendreher. Ich bewerte die verschiedenen Technologien und verwende die richtige für den richtigen Anwendungsfall. Das bedeutet nicht, dass ihre Dinge auf jeder der Plattformen zum Besseren geändert werden können. :grins:

Zum Beispiel; Integration von Plugins von Drittanbietern. NativeScript ist wirklich König über jede andere plattformübergreifende Lösung. Nichts kommt auch nur annähernd an NativeScript heran; und Integration von Drittanbietern. Ich habe einen Kunden, der nach der Verwendung von https://github.com/vipulasri/Timeline-View fragt. Flattern praktisch unmöglich; NativeScript gibt mir ein paar Stunden Zeit und es wird wie jedes andere NS-Steuerelement funktionieren, wahrscheinlich sogar mit vollständig funktionierender Datenbindung. Auf der anderen Seite hat Flattern einige ernsthafte Stärken, wo NS-Flaggen ...

Verwenden Sie das richtige Werkzeug für den Job. :grins:

Ich neige dazu, das XML-basierte Bildschirmlayout zu mögen; aber ich verstehe, warum die Leute es nicht tun. Das Hinzufügen der Fähigkeit zum XML-basierten Erstellen bedeutet NICHT, dass die vorhandene Methode eliminiert wird; es ist nur komplementär ; Auswahl. Für diejenigen unter Ihnen, die sich nicht die Mühe gemacht haben zu lesen, ich kann die gleiche Anrufkette in NS ausführen, die wir in Flattern ausführen. Aber die Verwendung von XML ist viel weniger Tipparbeit und für mich einfacher zu lesen. Jeder hat seine Vorlieben...

Ich habe tatsächlich darüber nachgedacht, Flutter einen XML-basierten Renderer als POC hinzuzufügen. aber ich hatte keine Freizeit. Ich wollte nur zu dem Gespräch beitragen und sagen, dass ich gerne sehen würde, dass dies voranschreitet; aber ich erwarte eigentlich nicht, dass das Kernteam daran arbeitet. Ich denke, das NS-XML-Format könnte als Gemeinschaftsprojekt durchgeführt werden, bei dem diejenigen von uns, die sich dafür interessieren (dh wahrscheinlich ich :grinsen:), bereit wären, die Arbeit daran zu übernehmen. Meine größte Sorge @sethladd ist jedoch, ob ich viel Zeit mit einem Patch verbringe; Wird es abgelehnt, weil jemand im Kernteam diese Fähigkeit absolut ablehnt? Das möchte ich zuerst festnageln, bevor ich Zeit damit verschwende...

@NathanaelA Fantastische Perspektive !!!!!! und schau, ich habe viele Ausrufezeichen verwendet ;-) Du hast es buchstäblich auf den Kopf genagelt.

Ja, ich kann DSX, aber ich brauche eine Möglichkeit, es in das aktuelle Flutter-Build-System zu integrieren, also brauche ich das Engagement des aktuellen Flutter-Teams, bevor ich weitermache. Die IDE-Integration ist bei VS Code praktisch trivial, bei Intellij jedoch nicht so sehr (es sei denn, Google hat Zugriff auf die Intellij JSX-Unterstützung).

@zoech , nein! Ich denke, das ist ein Problem. Ich erinnere mich, dass ich eine Android-App mit nativem Java und XML entwickelt habe. Wir verwenden immer noch XML für den UI-Sprachteil. Ich denke, dass die Verwendung von Dart für Logik und Benutzeroberfläche etwas seltsam ist, und dieses Problem ist irgendwie offensichtlich. Außerdem hoffe ich nur, dass Google die UI-Idee von React in das Flattern einfügt. Der UI-Teil von React ist sehr leistungsfähig und prägnant.

@JonathanSum Ich habe viele Kommentare dazu gesehen.
Für mich sieht es immer noch nach etwas aus, das die Leute wollen, weil sie ihre Gewohnheiten nur ungern ändern, nicht weil es ein Vorteil für die Plattform ist.

Einige Leute mögen jsx, andere nicht. Warum unterstützen Sie nicht die beiden Möglichkeiten zur Implementierung der Benutzeroberfläche. Sie können jsx-ähnliche Syntax schreiben, und es wird endlich fertig sein, native Syntax zu flattern, warum nicht unterstützen?

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

@Zoechi

Für mich sieht es immer noch so aus, als würden die Leute es wollen, weil sie ihre Gewohnheiten nur ungern ändern

Dies ist eine faire Beobachtung, aber wäre es nicht besser für Flutter, ein Wegbereiter zu sein und so viel Reibung wie möglich für Menschen (außerhalb von Google) zu beseitigen, die Flutter übernehmen? Dieses Gate-Keeping-Verhalten gewinnt nicht die Herzen und Köpfe der Entwickler.

@yuu2lee4

Einige Leute mögen jsx, andere nicht. Warum unterstützen Sie nicht die beiden Möglichkeiten zur Implementierung der Benutzeroberfläche. Sie können jsx-ähnliche Syntax schreiben, und es wird endlich fertig sein, native Syntax zu flattern, warum nicht unterstützen?

Ausgezeichnete Frage. Angesichts der Tatsache, dass ich alle Arbeiten an DSX mache, das genau wie JSX ist, und @Hixie mir persönlich eine E-Mail geschickt hat, die sich über den Fortschritt freut, sehe ich nicht, warum ich es nicht unterstützen sollte, ich sehe nicht, warum ich nicht die Hand ausstrecken und sagen sollte 'Was kann ich tun um dir zu helfen? Was hindert Sie daran?'

Ehrlich gesagt fange ich an, diese Überschrift in eine ähnliche Richtung wie die vorherige zu denken ... was nicht helfen würde ...

@cbazza

@Hixie hat mir persönlich eine E-Mail geschickt, die sich über den Fortschritt freut.

Warum also nicht weitermachen und die anderen, die helfen können, sollen auch einsteigen und helfen? Wenn wir nicht wollen, dass dies wie der andere Thread auftaucht ... Ich denke, wir sollten diskutieren, was die Blöcke sind, wie wir vorgehen und wie wir es zum Laufen bringen und es veröffentlichen ... und Ich denke auch, dass das Flatter- und Dart-Team in gewisser Weise damit begonnen hat, die ausführliche Natur des Schreibens von Benutzeroberflächen zu reduzieren ...
Vielleicht kann das Team jetzt nicht mitmachen, aber ich glaube, wenn es eine gute Sache ist, von der ich glaube, dass es für mich in Ordnung ist, egal welcher Ansatz ... sie werden irgendwann aufholen ... also lasst uns mit @cbazza weitermachen Du tust und holst es heraus ... wie dieser Typ http://mutisya.com/ in den frühen Tagen, obwohl ich seinen Zustand nicht kenne ... Ich weiß auch, dass @NathanaelA helfen kann, weil er etwas beigetragen hat wirklich erstaunliche Sachen und Tools für Nativescript ... Lass es raus, um mehr Entwicklern mehr Optionen zu geben ...

@MichaelSowah
Der Grund, nicht mehr Zeit dafür zu investieren, ist wie @NathanaelA sagte:

Meine größte Sorge @sethladd ist jedoch, ob ich viel Zeit mit einem Patch verbringe; Wird es abgelehnt, weil jemand im Kernteam diese Fähigkeit absolut ablehnt? Das möchte ich zuerst festnageln, bevor ich Zeit damit verschwende...

Okay, hier ist, was ich habe:
(a) Ein Vorprozessor, der *.dsx-Dateien aufnimmt und *.dart-Dateien ausgibt.

Hier ist, was ich brauche:
(1) Jemand, der sich um die „VS Code“-Integration kümmert. Nach meiner Untersuchung sieht es einfach aus.
(2) Jemand, der herausfindet, wie man dem Flutter-Build-System Präprozessorfähigkeiten hinzufügt, damit das Debuggen richtig funktioniert. Ich meine, Code-Stepping würde auf den *.dsx-Dateien über so etwas wie Sourcemap usw. erfolgen.

Sobald die beiden oben genannten Punkte erledigt sind, haben wir ein erstes End-to-End-System, um den Ball ins Rollen zu bringen. Irgendwelche Abnehmer?

Wie Sie oben sehen können, erfordern (1) und (2) Änderungen im Flutter-Code, die das Flutter-Team ablehnen kann, sodass diese Funktion ohne Unterstützung/Verpflichtung hängen bleibt.

@cbazza großartig, also lassen Sie uns eines der Flutter-Teammitglieder hierher bringen, um uns mitzuteilen, ob sie bereit sind, eins und zwei aufzunehmen ... also, wen können wir hier finden, um uns beim Fortschritt zu helfen ...?

Für (2) ist es meiner Meinung nach am besten, das Dart-Team zu kontaktieren, wahrscheinlich über [email protected] oder deren Issue-Tracker? Ich glaube, eines der Ziele von Dart 2 war es, eine Infrastruktur für mehr Experimente mit der Sprache zu schaffen und die Community Experimente wie DSX erstellen zu lassen. Vielleicht können @anders-sandholm @mit-mit oder @mraleph Sie in die richtige Richtung weisen.

@sethladd Danke für die schnelle Antwort und könntest du auch die Ressource Personen kopieren und evtl
Dart-Team auch zu diesem Thread
@cbazza könnten Sie einspringen, um diesen Diskurs mit der aufgeführten Ressourcenperson in Gang zu bringen.
In Bezug auf die 'VS Code'-Integration bin ich sicher, dass @DanTup vielleicht daran interessiert sein könnte, zu helfen, sobald wir 2 aus dem Weg geräumt haben

Nur einige Gedanken

Okay, hier ist, was ich habe:
(a) Ein Vorprozessor, der *.dsx-Dateien aufnimmt und *.dart-Dateien ausgibt.

Dies ist wahrscheinlich alles, was Sie zum Starten benötigen, das und ein Dateibeobachter, um Änderungen neu zu erstellen - siehe FileSystemEntity . Die Herausforderung besteht darin, dass diese .dx Grammatik eine Obermenge von Dartlang ist, also müssten Sie auch Dart vollständig parsen. Dies wird schwierig, da im Gegensatz zu JavaScript < und > an mehr Stellen verwendet werden. Ich denke, der Dart-Parser ist bereits in Dart geschrieben und irgendwo im SDK-Repo, aber ich weiß nicht, wo

1. Für die vscode- und Intellij-Integration ist es nicht das Flutter-Build-System, sondern der Dart- Analysator , den Sie wollen. Ich denke, Sie können dafür ein Plugin erstellen, das das dx verbraucht, es in Dart transpiliert und dann die Ergebnisse wieder der Originaldatei zuordnet. So funktioniert das Winkelanalysator-Plugin , um Dinge wie die automatische Vervollständigung von HTML-Dateien bereitzustellen.

2. Sie möchten Build Runner , dies ist ein viel ausgefeilteres Paket zum Ausführen a .

@MichaelSowah
Ausgezeichnet, also nehme ich an, Sie übernehmen (1) & (2), damit ich mich auf den Transpiler konzentrieren kann?

@jonahwilliams
Ich weiß, das vollständige Dart-Parsing wird kompliziert und im Moment nicht wirklich notwendig, da ich meine Markierungen immer für die erste Veröffentlichung verwenden kann (https://spark-heroku-dsx.herokuapp.com/index.html)

Aber eines ist sicher, wir brauchen die IDE und den Debugger, die richtig funktionieren, sonst werden die Leute DSX nicht verwenden, weil der Kompromiss zu groß ist. Ich meine „Verwenden Sie DSX und vergessen Sie das symbolische Debugging“, kein sehr überzeugendes Angebot. Das ist auch der Grund, warum ich möchte, dass mindestens eine IDE unterstützt wird, und VS-Code wäre so einfach wie ein Kuchen (da es JSX bereits in ihren Typescript- und Javascript-Syntax-Definitions-JSON-Dateien unterstützt).

Betreff: IDE und Debugger, vermutlich durch Implementieren dieser Funktion innerhalb der Dart 2-Infrastruktur und des "gemeinsamen Frontends", sollten Sie in der Lage sein, den höheren Ebenen des Stacks zu ermöglichen, DSX zu erkennen. Ich empfehle, mit dem Dart-Team zusammenzuarbeiten und zu lernen, wie man die verschiedenen Teile des Common Front End und seiner APIs erkundet.

@MichaelSowah Ich habe die Leute von Dart in https://github.com/flutter/flutter/issues/15922#issuecomment -376960770 auf CC gesetzt

@NathanaelA wären Sie daran interessiert, bei (1) & (2) mitzumachen, da wir jetzt eindeutig Unterstützung vom Team haben

Nicht sicher; in diesem Moment -- ich bin mit mehreren Kundenprojekten überschwemmt. Aber ich wäre bereit zu prüfen, wie man sich in die Kompilierungspipeline einklinkt und möglicherweise Quellkarten erstellt. (dh 2) Aber es könnte ein paar Wochen dauern, bis ich das tun kann.

@NathanaelA Es gibt keine Eile oder so, also bist du gut :-)

Wenn DSX einfach Dart + Virtual closing tag ist, dann gibt es keinen wirklichen Vorteil. Ein Vorteil von dart ist, dass wir Funktionen und Variablen verwenden können, um einen Teil des Widgets zu erstellen und die Lesbarkeit zu erhöhen.

Auch mit DSX und Präprozessor verlieren wir die Hot-Reload-Fähigkeit in weniger als einer Sekunde, richtig @cbazza ?

Nein, DSX ist wie JSX und völlig anders als „Dart + Virtual Closing Tag“, was Sie heute mit Ihrem Widget-Baum und Ihrer IDE nur für Dart tun können.

DSX wird hier beschrieben:
https://spark-heroku-dsx.herokuapp.com/index.html

DSX ist Dart, also sind alle Vorteile von Dart, wie Sie sie beschreiben, vorhanden. Leute, die mit JSX vertraut sind, werden es sofort verstehen und lieben.

Nein, Sie werden nichts verlieren, nichts ändert sich für die normale *.dart-Datei, die Sie erstellen, Sie haben immer noch ein Hot-Reloading in weniger als einer Sekunde.
Wenn Sie jetzt eine *.dsx-Datei haben, wird sie zuerst in *.dart transpiliert, und dieser Vorgang ist schneller, als ich blinken kann !!! Daher wird es für DSX-Benutzer nicht wahrnehmbar sein.

Bevor dieser hier wieder geschlossen wird, lassen Sie mich beenden, was ich zuerst sagen möchte.
Die aktuelle Benutzeroberfläche des Flutter-Teils ist ein Problem, und ich versuche nicht, die Idee von React zu verkaufen.
Da die UI-Struktur von Flattern mit diesen Klammern im Kopf sehr schwer zu realisieren ist, müssen wir wirklich etwas verbessern. Ich empfehle dringend, React Native oder das Ganze wie React zu verwenden. React macht die Leute nicht nur leicht lesbar, es trennt auch einen riesigen UI-Code in verschiedene Gruppen. Dadurch kann ich einen sehr komplexen UI-Code schneller verwalten und einfach lesen. Andererseits weiß ich bei vielen Bäumen mit Klammern nur im Flattern nicht, wie ich sie lesen soll.

@JonathanSum hast du die letzte Version von Android Studio (3.1) mit schließenden Labels ausprobiert?

@14n Ja, ich sehe diese virtuellen schließenden Tags und Kommentare.

Ein großer XML-ähnlicher Widget-Baum kann genauso schwer zu lesen sein wie jedes andere große Ding, sei es Dart, JSON, YAML oder JSX. Es scheint nicht so, als ob JSX selbst das Problem der Lesbarkeit löst.

Ich hatte keine Probleme, vernünftig große Widget-Bäume mit der aktuellen Syntax zu lesen. Außerdem fördert Flutter die Komposition. Sobald ein bestimmtes Widget zu groß wird, ist es trivial, es in mehrere kleinere Widgets aufzuteilen.

Subjektive Meinung zum vorgeschlagenen DSX-Format:

1. Visuell kein wirklicher Vorteil und wieder - das Lesen eines großen XML-Baums kann genauso schmerzhaft sein, also scheint es nicht so, als würde es das Problem lösen. Die Förderung von Clean-Code-Praktiken würde zum Beispiel eigentlich Bedenken hinsichtlich der Lesbarkeit ausräumen, aber diese Praktiken können auf (fast) jede Syntax angewendet werden.
2. Erfordert das Erlernen einer anderen DSL/Syntax. Ich mag es wirklich, wirklich, wirklich, dass ich nur eine Syntax kennen muss – Dart – um alles zu tun – Layout, Stile, Animationen, Logik. Es ist so viel freundlicher für Anfänger und erfahrene Entwickler im Vergleich zu dem, was mit html/js/jsx/ts/coffee/css/sass/scss passiert ist. Tatsächlich halte ich dies sogar für einen großen Vorteil von Flutter gegenüber anderen Plattformen.

Abgesehen davon glaube ich, dass Dart verbessert werden kann, um ausdrucksstärker zu sein, wenn es zur Beschreibung von Benutzeroberflächen verwendet wird, obwohl ich es vorziehen würde, wenn es eher eine Erweiterung der bestehenden Dart-Syntax wäre als eine völlig neue DSL.

Bitte hören Sie auf zu versuchen, Flutter wie das "heiße neue Ding" zu machen. Es ist das heiße neue Ding für sich, lassen Sie es neue Paradigmen erkunden.

@naiveaiguy Ich finde es heiß. Es macht mich sehr produktiv und ermöglicht es mir, Code mit Browser- und Server-Apps zu teilen.
Ich brauche keinen Rummel für einen Sommer. Ich brauche etwas, das mir erlaubt, meine Arbeit zu erledigen.
Genau das machen Flutter und Dart.

Meine Gedanken zu diesem Thema spiegeln wider, was @pulyaevskiy in https://github.com/flutter/flutter/issues/15922#issuecomment -377666972 gesagt hat. Alle Beispiele, die ich gesehen habe und die nicht so lesbar sind, können normalerweise im vorhandenen Code aufgeräumt werden, und ich denke, es könnten kleinere Änderungen an Dart vorgenommen werden (ähnlich dem Entfernen von new/const), die es weiter verbessern könnten . Die Pflege eines ganz anderen Satzes von Dateien mit einer ganz anderen Syntax und einem ganz neuen Satz von Tooling-Code scheint ein hoher Preis für einen meiner Meinung nach relativ geringen Gewinn zu sein (FWIW, ich bevorzuge auch React ohne JSX).

Ich weiß nicht, ob es hier vollständig anwendbar ist, da das vorgeschlagene dsx auch normalen Dart-Code zulässt, aber jedes Mal, wenn ich jemanden über eine neue Syntax sprechen höre, werde ich an diesen großartigen Beitrag von Gilad A DOMain of Shadows erinnert. Diese Dinge sind immer komplizierter als man denkt. Es ist nicht so einfach, den Code einfach zu transpilieren, weil die Leute Echtzeitfehler, Codevervollständigung, Refactors, Tooltips usw. erwarten würden - es ist ein großes Unterfangen.

Anstatt eines funktionierenden Transpilers wäre ich mehr daran interessiert, einen Drei-Wege-Vergleich zwischen einem Code zu sehen, der als schwer lesbar gilt, wie er in dieser vorgeschlagenen Syntax aussehen würde und wie er aussehen würde, wenn Sie Änderungen daran vornehmen könnten die vorhandene Dart-Syntax, ohne alle Klammern zu ersetzen. Zum Beispiel, etwas, das ich in React mag, ist, dass Kinder als varargs als letzter Parameter übergeben werden - ich denke, child und children fügen viel Rauschen in Flutter hinzu - vielleicht gibt es dort Raum für Verbesserungen . Es gibt auch einige Diskussionen darüber, ob das Ändern der Formatierung oder das Hervorheben von Widget-Klassennamen hilfreich sein könnte. Es sieht so aus, als ob ein Extract Widget -Refaktor unterwegs ist, um große Build-Methoden einfach zu zerlegen. Und natürlich hat IntelliJ die Flutter Outline-Ansicht, mit der Sie den Code in einem Baum sehen können und die Auswahl mit der Cursorposition im Editor synchron bleibt (und ich hoffe wirklich, etwas Ähnliches in VS Code zu bekommen, obwohl es blockiert ist von einigen VS Code-Features wie diesem, also fühlen Sie sich frei, es zu 👍!).

@pulyaevskiy
Ich verstehe, was Sie sagen, aber Experimentieren ist gut, es ist der Weg zur Evolution. Selbst wenn mein Experimentieren mit DSX fehlschlägt, hoffe ich, dass andere mit vielen anderen Dingen experimentieren und die besten Ideen da draußen zusammenbringen, um erstaunliche Technologie zu schaffen.

@sethladd
Vielen Dank für die Hinweise.
Würde mich freuen, von @anders-sandholm @mit-mit oder @mraleph zu hören
wie man mit der Dart 2-Infrastruktur und dem 'gemeinsamen Frontend' arbeitet.
Ich werde das mit @NathanaelA untersuchen.

@DanTup

Diese Dinge sind immer komplizierter als man denkt. Es ist nicht so einfach, den Code einfach zu transpilieren, weil die Leute Echtzeitfehler, Codevervollständigung, Refactors, Tooltips usw. erwarten würden - es ist ein großes Unterfangen.

Ja du hast Recht. Mein Kommentar "trivial, kinderleicht zu implementieren" bezog sich nur darauf, den Editor dazu zu bringen, die .dsx-Syntax zu erkennen. Ich habe mir Intellij angesehen und sie benötigen dafür einen vollständigen Sprachparser (das ist also komplex), während VS Code mit den Syntaxdateien viel einfacher war, und ich habe auch festgestellt, dass die Typescript/Javascript-Syntaxdateien bereits Unterstützung für JSX hatten (und DSX nur hat geringfügige Änderungen gegenüber JSX).

Wir werden Sie sicherlich um Hilfe/Anweisungen bitten, um unsere Experimente in Gang zu bringen.

Zusammengefasst habe ich:
(a) Ein Vorprozessor, der *.dsx-Dateien aufnimmt und *.dart-Dateien ausgibt.
https://spark-heroku-dsx.herokuapp.com/index.html

Ich brauche Hilfe bei:
(1) Jemand, der sich um die „VS Code“-Integration kümmert.
(2) Jemand, der herausfindet, wie man dem Flutter-Build-System Präprozessorfähigkeiten hinzufügt, damit das Debuggen richtig funktioniert. Ich meine, Code-Stepping würde auf den *.dsx-Dateien über so etwas wie Sourcemap usw. erfolgen.

@NathanaelA hilft bei (2).

Also suche ich immer noch Leute, mit denen ich helfen kann (1)
Irgendwelche Abnehmer? @birkir @yuriy-manifold @tehfailsafe @alexkrolick @sanketsahusoft

@DanTup - Ich bin kein Profi in JSX, aber ich kann für das XML-Format von NativeScript sprechen. Ich kann:

Jede Eigenschaft, die die Klasse StackLayout unterstützt, kann dem XML hinzugefügt werden. Es ist also eine Eins-zu-Eins-Beziehung; wodurch eine Menge zusätzlicher Cruft eliminiert wird: Schauen wir uns also die Flutter-Demo an:
https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/gallery/home.dart#L39 -L63

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

Ich finde das leichter zu lesen und zu verstehen, wenn ich es richtig konvertiert habe. :grins:

@NathanaelA Was passiert, wenn Sie etwas Dynamischeres tun müssen, z. B. map anrufen? Hier ist ein Code aus derselben Datei:

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

Wie würde children: _kBackgroundLayers.map(...) in dieser Syntax aussehen?

JSX/DSX gibt nur die Tag-Transformation an als:

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

Im:

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

Aus:

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

und Sie können {} verwenden, um jeden gültigen Dart-Code wie Variablenauswertung und anonyme Funktionen usw. einzufügen. Das {} kann an 3 Stellen platziert werden. Das folgende Beispiel zeigt {}, das an zwei Stellen verwendet wird (Tag-Attribute und als untergeordnete Elemente), wobei die dritte mit dem Spread-Operator verwendet wird.

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

Fügen Sie den obigen Code in eine Javascript-Datei ein und zeigen Sie ihn mit VS Code/Intellij an. Beachten Sie das +/- (linke Seite der Linie), mit dem Sie XML-Knoten öffnen und reduzieren können, um den Baum kleiner/größer zu machen.

Warum können wir das Problem nicht einfach zugeben und den React Native-Weg übernehmen? Werden wir das tun oder nicht?

@JonathanSum Entschuldigung, wenn Sie hierher geleitet werden, aber für wen halten Sie sich? Es gibt kein allgemeines Problem, nur etwas, das Ihnen nicht gefällt.
Hast du überhaupt eine einzige App mit Flutter geschrieben?
Die obigen Beispiele für das Mischen von Dart mit XML sehen viel schlimmer aus als nur Dart. Hier gibt es nichts zu gewinnen.
Ich komme von Xamarin Forms, das xaml verwendet, und es hat mir sehr gut gefallen. Aber anstatt mich zu beschweren, warum Flutter Xaml nicht unterstützt, habe ich mich direkt damit beschäftigt und angefangen, mich anzupassen und zu lernen.
Sehen Sie es ein, wenn Sie wie in React arbeiten möchten, dann verwenden Sie Reactive, anstatt alle hier zu nerven.

Hier ist derselbe Codeblock wie oben, aber in reinem Dart und umgestaltet, um eine tiefe Verschachtelung zu vermeiden.
Neugierig, welche Teile des folgenden Snippets schwer zu lesen und/oder zu verstehen sind?

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

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

Tatsächlich würde ich persönlich es ungefähr so ​​aussehen lassen:

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

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

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

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

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

Auch hier scheinen wir zwei verschiedene Probleme zu vermischen:

1. Abneigung gegen die Dart-Syntax und Notwendigkeit einer XML/JSX-ähnlichen Syntax
2. Lesbarkeit des Flutter-Codes.

Gibt es hier Leute, die glauben, dass die Implementierung von JSX die Lesbarkeit lösen wird? Es wäre immer noch möglich, tief verschachtelte Bäume im Code zu erstellen, und Entwickler müssten immer noch dieselben Schritte durchlaufen, die ich gerade mit der Dart-Version durchgeführt habe, um die Dinge lesbar zu machen.

Aber was es definitiv hinzufügen würde, ist ein zusätzlicher Build/Transpile-Schritt mit Source Maps & Co und viel Arbeit, um diese Infrastruktur in IDEs und Dart SDK (Analysator, Debugger usw.) zu unterstützen.

@JonathanSum @escamoteur Wir sprechen nicht aggressiv über dieses Projekt. Bitte bleiben Sie kooperativ kollegial. Danke. Die jüngste Diskussion war freundlich und produktiv, also danke an alle, die an dieser Diskussion teilgenommen haben!

Insgesamt scheint mir, dass das Hinzufügen von DSX das Flutter-Ökosystem in seinen frühesten Stadien fragmentieren würde, wobei viel Arbeit darauf verwendet wird, beide Syntaxen vollständig zu halten, in den meisten Fällen nicht wirklich zur Lesbarkeit beiträgt und die Art von Entwicklern anzieht, die dies tun fühlen sich von Projekten nur deshalb angezogen, weil sie eine ähnliche Syntax und/oder ein ähnliches Paradigma wie eine heiße neue Sache haben.

@Hixie tut mir leid, dass ich die Fassung verloren habe, aber ich denke, Flutter ist so wie es ist auf einem guten Weg und die Flutter-Entwickler haben ohne solche Forderungen genug zu tun

@escmoteur - Ich denke, das ist der Grund, warum ich ausdrücklich "Community" -Anstrengung gesagt habe. Ich denke nicht, dass das Flatter-Kernteam über die Bereitschaft hinausgehen muss, Patches zu akzeptieren ... Was Seth anscheinend gesagt hat, wir können fortfahren. Wenn Sie an dieser Funktion nicht interessiert sind; dann nicht benutzen... :grins:

@escamoteur , es tut mir leid, wie ich das gesagt habe.
Ich habe einige Flatter-Apps aus Tutorials gebaut. Alles, was ich über Flattern denke, ist, dass alles eher ein Objekt als ein Widget ist. Es ist wie ein riesiges Stück komplizierter objektorientierter Programmiercodes, die ungeordnet zusammenkleben.

Ich denke, das Wichtigste ist, ein Framework zu erstellen, das einfach zu lesen und zu verwalten ist und nicht so kompliziert sein sollte. Am wichtigsten ist, dass ich denke, dass die Art und Weise, wie React-Native baut, dem folgt, was Menschen auf natürliche Weise bauen. Auf der anderen Seite muss das Flutter das zustandsbehaftete Widget mit dem zustandslosen und ... verbinden. Darüber hinaus konzentrieren sich die meisten UI-Frameworks, die wir in diesen Jahren verwenden, standardmäßig auf diesen React-Weg, und ich denke, Flutter sollte sich mehr darauf konzentrieren anstelle des Hot Reload (wenn ich versuche, neue Klassen hinzuzufügen, sagt mir die Konsole, dass ich alles neu starten soll, anstatt Hot Reload durchzuführen). Ich denke wirklich, dass dies ein Problem ist, kein Kommentar oder eine Forderung.
naiveaiguy sagt:

Bitte hören Sie auf zu versuchen, Flutter wie das "heiße neue Ding" zu machen. Es ist das heiße neue Ding für sich, lassen Sie es neue Paradigmen erkunden.

Du kannst sie dir ansehen.
https://facebook.github.io/react-native/
Denken in Reaktion:
https://reactjs.org/docs/design-principles.html
Flattern:
https://flutter.io/tutorials/animation/

Schauen Sie sich das React-Native an, es stellt sogar die Zustandsverwaltung oben und die UI-Teile unten. Es ist eine Kunst und ein natürliches Verhalten des Menschen. Deshalb sind die Lernkurve und die Managementzeit gering. Vergleichen Sie daher bitte nicht XML oder gar Xamarin mit React Native. Außerdem ist das Futter einfach nur ein Chaos und Durcheinander. Die Zustandslosen verbinden sich mit Zustandsbehafteten, und der Erzeugezustand verbindet alles in den Zustandslosen. Mit React-Native zeichnen Sie ein wunderschönes Bild mit einem Bleistift. Mit einem Flattern ist es so, als würde man Wasser auf ein Papier tropfen lassen und das Wasser in verschiedene Teile trennen. Aber ich denke, wir befinden uns noch in den Anfängen des Flatterns. React-Native hat seine eigene Philosophie und Ziele, und Flattern ist nur ein ernsthaftes Projekt, oder alle sind anderer Meinung.

@JonathanSum

Ich habe einige Flatter-Apps aus Tutorials gebaut. Alles, was ich über Flattern denke, ist, dass alles eher ein Objekt als ein Widget ist. Es ist wie ein riesiges Stück komplizierter objektorientierter Programmiercodes, die ungeordnet zusammenkleben.

Sie haben keinen Grund dafür angegeben, warum Ihr subjektives Gefühl in dieser Angelegenheit die enorme Menge an Fragmentierung rechtfertigen würde, die dies zwangsläufig verursachen würde. Wenn zwischen diesen beiden Ansätzen keiner objektiv eindeutig besser ist als der andere, denke ich, dass es sich nicht lohnt, und definitiv nicht in dem Stadium, in dem sich Flutter als Ökosystem gerade befindet.

Ich denke, das Wichtigste ist, ein Framework zu erstellen, das einfach zu lesen und zu verwalten ist und nicht so kompliziert sein sollte.

Das ist eine Tautologie. Natürlich will das jeder, aber die Menschen haben unterschiedliche Herangehensweisen an das Problem. Flutters Paradigma ist eines davon.

Am wichtigsten ist, dass ich denke, dass die Art und Weise, wie React-Native baut, dem folgt, was Menschen auf natürliche Weise bauen.

Ich glaube nicht, dass etwas so Kleines wie die Syntax zum Erstellen der Benutzeroberfläche die Benutzerfreundlichkeit eines Frameworks insgesamt beeinflusst.

Andererseits muss das Flattern das zustandsbehaftete Widget mit dem zustandslosen und ...

Es scheint, als wären Sie grundsätzlich nicht damit einverstanden, wie Flutter Apps angeht. Warum benutzt du es? Darüber hinaus ist dies nicht wirklich ein gültiger Punkt. Sie drücken nichts aus, was Sie für falsch halten, Sie sagen nur: "Ich denke, dass Verbindungen zwischen zustandslosen und zustandsbehafteten Widgets falsch und auf eine vage Weise kompliziert sind, die ich nicht weiter erklären werde."

Darüber hinaus konzentrieren sich die meisten UI-Frameworks, die wir in diesen Jahren verwenden, standardmäßig auf diesen React-Weg.

Argumentum ad populum.

und ich denke, Flattern sollte sich mehr darauf konzentrieren als auf das Hot Reload (wenn ich versuche, neue Klassen hinzuzufügen, sagt mir die Konsole, ich solle alles neu starten, anstatt Hot Reload durchzuführen).

Ja, weil Hot Reload keine sehr einfache Funktion ist, wie Flutter es getan hat. Ich würde argumentieren, dass der Entwicklungszyklus, den Flutter selbst bei 30-40 % der Codeänderungen erreicht hat, wirklich beeindruckend ist und nur durch Transpiling-Schichten verlangsamt würde.

Allerdings ist das Futter genauso wie nur Chaos und Unordnung.

Hier hast du deutlich gemacht, dass dir Flutters Ansatz einfach nicht gefällt. Benutze es dann nicht. Und wenn Sie glauben, dass eine Änderung der UI-Syntax irgendwie, magisch, Flutter nicht zu „Chaos und Unordnung“ machen wird, dann müssen Sie klare Beweise dafür liefern, dass Sie mit den gleichen Einstellungen und Einschränkungen arbeiten, mit denen Flutter arbeitet.

Deshalb ist die Lernkurve und die Zeit für die Bewältigung gering. Bitte vergleichen Sie XML oder gar Xamarin nicht mit React Native.

Fair genug - verwenden Sie dann React Native. Die Entwickler dort leisten mit ihrem Paradigma ganze Arbeit.

Die Zustandslosen verbinden sich mit den Zustandslosen und erzeugen einen Zustand in den Zustandslosen

Was? Nein. Das ist einfach falsch - was ist Ihr Punkt hier?

Mit React-Native zeichnen Sie ein Bild mit einem Bleistift. Beim Flattern ist es wie wenn Wasser auf ein Papier tropft und das Wasser in verschiedene Teile trennt.

Ehrlich gesagt macht diese Analogie für mich sehr wenig Sinn. Ich könnte einfach die gegenteilige Meinung vertreten und wir wären gleich wieder da, wo wir hier angefangen haben.

Sie verhalten sich so, als wäre dies selbstverständlich ("Seien wir ehrlich"), und wir sind hier nur anmaßend und/oder unerträglich, wenn wir sagen, dass das Flutter-Team sich nicht damit befassen sollte. Das ist keine gute Einstellung, wenn du möchtest, dass andere dich ernst nehmen.

Zusätzlicher Punkt: Bitte geben Sie nicht vor, dass dies etwas ist, was Entwickler von Drittanbietern ohne Beteiligung oder Arbeit des Flutter-Kernteams tun können. Das Flutter-Team muss viel zusätzliche Arbeit mit IDEs und Editor-Plugins und Evangelisation leisten und sich mit GitHub-Problemen befassen, wenn ein solches Feature zufriedenstellend als harmonischer Teil von Flutter implementiert werden soll.

@naiveaiguy
Alles klar, ich denke du hast recht. Ich bin nur eine zufällige Person, die alle hier vergleicht, und eine Person, die React mag. Flutter hat seinen eigenen Weg und React auch. Es tut mir leid für meine Einstellung, und ich war nicht nett.

@JonathanSum Ich denke, Sie brauchen einfach mehr Zeit, um wirklich zu verstehen, wie Flutter-Apps erstellt werden. Um fair zu sein, gibt es nicht viele Dokumente zur Architektur, zur korrekten Verwendung von geerbten Widgets und zur Verbindung Ihres Ansichtsmodells mit den Widgets.

Was ich gerne wissen würde ist, warum interessierst du dich überhaupt für Flutter? Für mich ist React wegen JS ein no go

So viel zu kommentieren, so wenig Zeit, vielleicht sollte ich mich konzentrieren...

@escamoteur was genau meinst du mit:

Für mich ist React wegen JS ein no go

ES6/7 oder Typescript sind so nah an Dart/Kotlin/Swift, dass ich glücklich mit jeder dieser Damen tanzen werde :)

Was mich an Flutter reizt, ist die Grafik- und Animationsunterstützung. Direkte Skia-Vektorgrafiken, die auf OpenGL für superschnelle UX bei 60 fps aufgebaut sind, um Dinge wie das, was Sie sehen, einfach zu implementieren:
https://uimovement.com/
Ich interessiere mich für benutzerdefinierte UX und Flutter ermöglicht das. Ich habe UX-Zeug seit Jahrzehnten implementiert und ich mag es wirklich, das mit deklarativen/reaktiven Techniken zu bauen, und Flutter unterstützt das.

@pulyaevskiy

Auch hier scheinen wir zwei verschiedene Probleme zu vermischen:

• Abneigung gegen die Dart-Syntax und Notwendigkeit einer XML/JSX-ähnlichen Syntax
• Lesbarkeit des Flutter-Codes.

Richtig, dieses Ticket hier (und das vorherige) wollen nur JSX-ähnliche Fähigkeiten. Es gibt andere Tickets für Verbesserungen der Dart-Sprache, um die Ausführlichkeit des aktuellen UI-Baucodes zu verringern.

Gibt es hier Leute, die glauben, dass die Implementierung von JSX die Lesbarkeit lösen wird?

Es könnte für sie, jedem das seine.

Ja, das von Ihnen bereitgestellte Beispiel macht den Baum kleiner, aber indem Sie ihn in Stücke zerlegen und an eine andere Stelle verschieben, wird es auch noch schwieriger, die gesamte Struktur im Code zu sehen. Ich würde lieber die komplette Struktur an einem Ort behalten und einige verwandte Eigenschaften (benannte Parameter) aus dem Baum nehmen und den Spread-Operator von DSX verwenden, um sie einzubringen. Nur meine Präferenz.

Aber was es definitiv hinzufügen würde, ist ein zusätzlicher Build/Transpile-Schritt mit Source Maps & Co und viel Arbeit, um diese Infrastruktur in IDEs und Dart SDK (Analysator, Debugger usw.) zu unterstützen.

Wir kümmern uns darum und @sethladd hat angegeben, dass I believe one of the goals of Dart 2 was to create an infrastructure for more experimentation with the language and let the community create experiments like DSX.

@naiveaiguy

Ich würde argumentieren, dass der Entwicklungszyklus, den Flutter selbst bei 30-40 % der Codeänderungen erreicht hat, wirklich beeindruckend ist und nur durch Transpiling-Schichten verlangsamt würde.

Ja, ich genieße wirklich heißes Laden, auch wenn es nicht immer funktioniert. Ich werde das auf jeden Fall nehmen, aber Ihr Kommentar mit dem Verlangsamen des Transpilierens ist unbegründet. Wenn Sie DSX nicht verwenden, wird es Ihrer Kompilierzeit nichts hinzufügen. Wenn Sie DSX verwenden, ist der Transpiler so schnell, dass Sie es nicht einmal bemerken werden.

Zusätzlicher Punkt: Bitte geben Sie nicht vor, dass dies etwas ist, was Entwickler von Drittanbietern ohne Beteiligung oder Arbeit des Flutter-Kernteams tun können. Das Flutter-Team muss viel zusätzliche Arbeit mit IDEs und Editor-Plugins und Evangelisation leisten und sich mit GitHub-Problemen befassen, wenn ein solches Feature zufriedenstellend als harmonischer Teil von Flutter implementiert werden soll.

Nicht wirklich. Wir tun dies und bitten nur darum, nicht blockiert zu werden. Wir bitten um Führung, um uns in die richtige Richtung zu weisen. Ich werde das alles nicht alleine machen, also sind wir jetzt zu zweit (danke @NathanaelA) und wir suchen nach mehr Leuten (mindestens 1 mehr), wenn sie helfen wollen.

Grüße an alle! Zunächst möchte ich darauf hinweisen, dass es nicht viel Sinn macht, das Hin und Her zu diesem Thema weiter zu diskutieren – es wird aufgrund der linearen Struktur umfangreich und schwer nachvollziehbar. Ihre Argumente gehen verloren und werden immer wieder neu aufgewärmt. Lassen Sie uns dies auf reine Zahlen reduzieren:

• Wenn Sie FÜR diese Funktion sind - Daumen hoch für den allerersten Kommentar zu diesem Thema.
• Wenn Sie GEGEN diese Funktion sind - Daumen nach unten für den allerersten Kommentar zu diesem Problem.

Als nächstes möchte ich die Aussage von @sethladd klarstellen, sie sollte lauten _„eines der Ziele von Dart 2 war es, eine Infrastruktur für mehr Experimente mit der Sprache für das Dart-Team zu schaffen“_.

Selbst in Dart 2 stellen wir keine APIs bereit, mit denen Sie die Syntax der Dart-Sprache einfach ändern können, ohne das Dart SDK (oder Flutter-Engine-Artefakte) neu erstellen zu müssen. Was Dart 2 bietet, ist eine _gemeinsame Front-End_ (CFE)-Infrastruktur (befindet sich in pkg/front_end in den Dart-SDK-Quellen) – die ein Parser für die in Dart geschriebene Dart-Sprache ist. Für rein syntaktische Sugar-Sprachänderungen wie DSX sollten Sie in der Lage sein, einfach CFE-Code zu bearbeiten, Dart SDK (oder Flutter-Engine) zu erstellen und alle Tools (mit Ausnahme des in die jeweiligen IDE-Plug-ins integrierten Syntaxhervorhebungscodes) Ihre neue Syntaxerweiterung zu übernehmen. Beachten Sie, dass derzeit nur VM und dart2js tatsächlich CFE verwenden, Analyzer soll als nächstes umgestellt werden. Wie Sie sehen können, gibt es hier eine gewisse Eintrittsbarriere.

Eine wichtige Sache, die hier hervorgehoben werden muss, ist, dass Sie mit dem Dart-Sprachteam zusammenarbeiten müssten, um die Sprache zu erweitern, da es keine API zum Erweitern der Dart-Syntax gibt. Derzeit gibt es dafür keinen formalisierten Prozess, aber für ein Feature wie DSX müssten viele Beweise und Motivationen vorliegen, damit es in Dart aufgenommen werden kann. (/ fyi @leafpetersen @lrhn - bitte korrigiert mich, wenn ich falsch liege)

Hier sind meine Empfehlungen für Befürworter einer DSX-ähnlichen Lösung:

• Zunächst müssen Sie Ihren Vorschlag tatsächlich schriftlich festhalten und die Diskussion an einen Ort verlegen, der eine nichtlineare Diskussion ermöglicht. Wenn Sie Sprachänderungen vorschlagen, benötigen Sie eine _ausführliche_ Beschreibung dessen, was Sie zu lösen versuchen und wie es mit Ihren vorgeschlagenen Syntaxerweiterungen gelöst wird. Andernfalls ist es unmöglich, Kosten und Nutzen der vorgeschlagenen Änderung zu bewerten. Dann brauchen Sie eine Möglichkeit, nichtlineare Diskussionen über verschiedene Teile des Vorschlags zu führen, z

  • Wenn Sie Ihren Vorschlag in Google Doc stellen, können die Leute integrierte Kommentare verwenden, um verschiedene Komponenten Ihres Vorschlags zu diskutieren.
  • Alternativ können Sie ein GitHub-Repository mit einer Markdown-Beschreibung Ihres Vorschlags erstellen und GitHub-Issues und -PRs verwenden, um Ihren Vorschlag zu verfeinern und zu diskutieren.

  Beachten Sie, dass ich nicht sage, dass Sie sich eine _formale Spezifikation_ für Ihre Änderung einfallen lassen müssen, die in Bezug auf die Verfeinerungsstufe mit der Spezifikation der Dart-Sprache vergleichbar wäre. Stattdessen benötigen Sie umfangreiche Beispiele dafür, wie die vorgeschlagene Änderung funktioniert und welche Vorteile sie bietet.



• Als nächstes sollten Sie versuchen, eine Implementierung zu haben, wenn Sie können. Die Hürde ist hier auch mit CFE-Infrastruktur hoch – aber deutlich niedriger als vorher.

@mraleph Ich denke, bei den Argumenten zur Integration in Dart ging es eher um Hooks zum Aufrufen der Codegenerierung oder ähnlichem, nicht um die Sprache zu ändern.
Ich habe keine Ahnung, dass so etwas notwendig ist.
Ich denke, dies könnte größtenteils wie Angular mit seinem Analyzer-Plugin implementiert werden, nur DSX anstelle von HTML

@mralef

Vielen Dank für die Klarstellung.
Wir wollen die Dart-Sprache nicht wirklich ändern, was wir brauchen, ist eine Vorverarbeitungsfähigkeit, um unser experimentelles DSX in Dart umzuwandeln.
Übrigens können Sie es online ausprobieren unter:
https://spark-heroku-dsx.herokuapp.com/index.html

Die Sache ist, als Dart zum ersten Mal herauskam, konnte es in Javascript transpilieren und durch die Verwendung von Quellkarten einfach in das Javascript-Ökosystem einstecken (mehrere andere Sprachen taten dasselbe: Coffeescript, Typescript usw.). Was wir suchen, ist etwas Ähnliches für Dart/Flutter. Wir suchen nach generischen Vorverarbeitungsfunktionen, die es ermöglichen würden, jede andere Transpiling-Sprache auf Dart/Flutter aufzubauen.

In Bezug auf die Abstimmung hat das vorherige Ticket einige Zahlen:
https://github.com/flutter/flutter/issues/11609

@cbazza

Wir wollen die Dart-Sprache nicht wirklich ändern, was wir brauchen, ist eine Vorverarbeitungsfähigkeit, um unser experimentelles DSX in Dart umzuwandeln.

Ich sprach aus der Perspektive, dass *.dsx -Dateien eigentlich Dart-Dateien sind, in denen Sie zusätzliche Syntax verwenden können. Und wie ich bereits sagte, gibt es derzeit keine APIs oder Erweiterungspunkte, die die Erstellung solcher Syntaxerweiterungen so erleichtern, dass diese Syntaxerweiterungen transparent mit allen Tools im Dart-Ökosystem interagieren können. Darüber hinaus glaube ich nicht, dass es unmittelbare Pläne gibt, solche APIs oder Erweiterungspunkte zu entwerfen und bereitzustellen. Daher ist es ab heute am besten, das Dart SDK zu forken und die DSX-Unterstützung in CFE zu integrieren.

Ich empfehle auch, über Eckfälle nachzudenken - anstatt über einfache Fälle nachzudenken. Stellen Sie sich zum Beispiel vor, Sie bearbeiten Ihre DSX-Datei. In diesem Fall möchten Sie höchstwahrscheinlich die Echtzeit-Vervollständigung von halb fertigem Code sehen, z. B. Konstruktornamen und Attributnamen. Wie würde das mit Source-Mapping funktionieren? Solche Dinge machen Entwicklererfahrung aus.

@mraleph Nochmals vielen Dank.

Wir sind sicherlich bestrebt, DSX-Benutzern eine großartige Benutzererfahrung zu bieten, das ist sicher.

Einige Leute mögen XML-ähnliche Syntax, andere hassen sie. Vielleicht ist das Hinzufügen einer jsx-ähnlichen Syntax zu übertrieben. Mein Hauptanliegen bei Flutter ist die Lesbarkeit. IMHO gibt es noch Raum, um die aktuelle Syntax von Dart und Flutter zu verbessern (für mich ist es hauptsächlich über tief verschachtelte Klammern, child , children , Semikolongeräusche usw.)
Wenn Sie hier einen Beispielcode[1]reposten,

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

Dart 2-Version mit new und Semikolon optional (Code von @sethladd)[2],

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

IMO, die Kotlin-Version ist sauber und sieht besser aus. Die Dart 2-Version ist sehr nah dran und hat noch Raum für Verbesserungen (ob Dart Erweiterungsmethoden unterstützt?). Daher denke ich, dass die Verbesserung der Dart-Syntax zur Reduzierung der Ausführlichkeit die richtige Richtung ist.

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

Ein anderer Blickwinkel, ich mag die Compose-Fähigkeit von JSX.

Die Arbeit mit den Komponenten (Widgets) ist sehr einfach und zugänglich, das Verschieben im Baum in einem Editor nach oben und unten ist nur eine Frage der Tastenkombination (Alt+UP / Alt+DOWN). Dies gilt insbesondere für das Ein- und Auslagern von Gegenständen in Containern, Reihen, Spalten usw.

Aber das ist nichts, was DSX alleine lösen würde. Die Widgets selbst müssten sein
eingeschränkter mit der Benennung von Eigenschaften, damit dies funktioniert. In React ist dies eine Eigenschaft namens children und ein Hauptprinzipal in JSX. Flutter ermöglicht Flexibilität bei der Benennung von Kindern (childs, children, body, etc.).

Hier ist eine großartige Diskussion über Vor- und Nachteile: https://github.com/jsforum/jsforum/issues/1

Pfeil	DSX

Quelle: https://github.com/flutter/flutter/blob/master/examples/platform_view/lib/main.dart

Ich muss zugeben, dass das DSX-Beispiel ansprechend aussieht. Aber ich befürchte, sobald Sie es mit Dart Code mischen, zB wenn Sie ein Builder-Widget verwenden, wird es wirklich hässlich aussehen.

@birkir DSX sollte in der Lage sein, so etwas wie das Render-Requisiten -Muster für mehrere/nicht children untergeordnete Slots zu unterstützen. Wenn es Funktionen oder Klassenreferenzen als Requisiten nehmen kann (was es wahrscheinlich automatisch tun würde), würde es sofort funktionieren.

Was die Tool-Implementierung angeht, unterstützen Javascript-Tools seit langem nicht standardmäßige Syntax- und Spracherweiterungen (Flowtype/Typescript/Babel), sodass viele der Tools für JSX vorhandene Transpiler nutzten. Afaik Dart hat dieses Maß an Fragmentierung noch nicht erlebt, daher gibt es die Werkzeuge noch nicht. Aber jetzt ist ein guter Zeitpunkt, um mit dem Bauen zu beginnen 😄

IMHO, json-ähnliche Syntax ist viel besser als ~xml-ähnliche~ Syntax!

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

@jaychang0917
Ich glaube nicht, dass JSX mit XML verglichen werden kann. Ich denke, JSX und XML sind zwei verschiedene Dinge als Überschallflugzeug gegen Propellerflugzeug.

Mit JSX können Sie Folgendes tun:

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

oder

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

Mit JSX können wir sogar wie oben alles Stück für Stück zerlegen, oder Sie können einen großen Teil der Benutzeroberfläche in einem <>-Tag gruppieren, um diesen großen Teil der Benutzeroberfläche an einer beliebigen Stelle zu platzieren.

Aus diesem Grund ersetzt React HTML und XML und übernimmt JSX, um entweder eine iPhone-App oder eine Web-App zu erstellen, oder die Leute sagen, JSX sei nur eine coolere Version von HTML.

• Ich mag weder XML noch HTML und liebe JSX.

• Ich denke, das Wichtigste ist nicht die Leistung zwischen iPhone und Desktop.

• Das Wichtigste ist die einfache Verwendung als iPhone vs. Desktop.

Zum Beispiel:

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

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

oder schreiben

< AwkwardScrollingImage/>

zu schreiben-einmal-läuft-überall

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

~ Flutter verwendet eine Programmiersprache, um eine Benutzeroberfläche zu erstellen. ~

Referenz:

Flattern:
https://flutter.io/tutorials/layout/
React Native, die Android, Iphone und sogar Desktop erstellen:
https://facebook.github.io/react-native/

@birkir
Ohhhh das sieht soooooooo aus!!! Nur Fleisch und keine Knochen :)
Stellen Sie sich vor, Sie verwenden https://builderx.io/ damit (sehen Sie sich das zweite animierte Bild an - 2-Wege-UI-Erstellung wie bei Flex :)

@escamoteur
mit Inline-Buildern würde es genauso chaotisch aussehen wie mit dem aktuellen Weg; Beispiele wurden oben bereitgestellt:
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

Jedenfalls denke ich, dass der aktuelle Weg klar und konsequent ist. Das Mischen von Dart-Code und < -Tag in einer Dart-Datei gibt mir das Gefühl, dass der Code umständlich und unklar ist. Aus der Sicht eines Android-Entwicklers sieht es so aus, als würde man Java/Kotlin-Code in eine Layout-XML-Datei schreiben :)

NUR MEINE ZWEI CENT

@JonathanSum ähm...

Welche Vorteile der Verwendung von JSX kann diese aktuelle Flattermethode also nicht bieten? Ich sehe keine Argumente, von denen Sie sagten, dass sie stark sind.

JSX ist nicht wie XML. JSX ist einfacher und leistungsfähiger als XML.

Übrigens, JSX ist XML-ähnlich , wenn das Facebook-Team mich nicht anlügt :)

@jaychang0917
JSX ist nicht XML, weil JSX einfacher und leistungsfähiger ist als dieses XML. (Ich sage, JSX ist nicht XML-ähnlich)

Wenn Sie sagen, dass es keine starken Argumente gibt, lassen Sie mich Ihnen eine Frage stellen.
Lassen Sie mich hier einfach meine Rede beenden. Wenn die Leute JSX oder DSX wollen, wird es in Zukunft ein ähnliches geben.

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

Ich vermisse jedoch die echten schließenden Tags von XML :)
Idee: Automatisch generierte schließende Tags

Kotlin hätte das auch gelöst. Sieh nur, wie großartig Kotlin-react und Anko sind

Kotlin-React ist nicht so toll, KSX wäre besser gewesen :)

import React from 'react';

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

package hello

import react.*
import react.dom.*

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

package hello

import react.*
import react.dom.*

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

Tags gehören da einfach nicht hin :)

Da ich im JSX/DSX/KSX-Lager bin, glaube ich sicherlich, dass Tags in den Code gehören :)

@saied89
Möchten Sie ein Tag verwenden, um ein Element in einem anderen Element zu verschachteln, genau wie in HTML? Oder möchten Sie ein Wort "Kinder", "Kind" oder [ ] eingeben? Darüber hinaus bietet JSX Dinge wie die Wiederverwendung von Hunderten von UI-Codes, indem nur ein Tag eingegeben wird.

Ein weiterer Aspekt ist vielleicht die Standardformatierung von dart format . IMHO ist es schwer zu lesen, besonders mit dem führenden Kind: / children.

Ich würde wirklich eine Formatierung bevorzugen, die die Baumstruktur so hervorhebt:

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

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

Das ist vielleicht nicht die ideale Lösung, aber es sollte die Richtung aufzeigen.
@sethladd irgendeine Chance, etwas in diese Richtung zu tun?

Zunächst einmal bin ich froh, dass dies nicht so hitzig wird, wie es seine Schwesterausgabe war : smile:.

Wenn ich gebeten würde, eine der beiden Syntaxen auszuwählen, würde ich mich zur Dart-Seite neigen. Dies basiert auf mehreren Tatsachen:

• Ich ziehe es vor, zwischen so wenigen Kontexten wie möglich zu wechseln. Ob Sie es mögen oder nicht, das Springen zwischen Syntaxen ist eine Möglichkeit, dies zu tun. Dies kann durch Werkzeugunterstützung unterstützt werden, aber dies führt zu dem folgenden Punkt.
• Ich ziehe es vor, dass das Entwicklungsteam Zeit anderen Problemen widmet, die uns daran hindern, bestimmte Funktionen zu programmieren und/oder Leute davon abhalten, Flutter zu nutzen. Ich denke, dass das Fehlen einer JSX-ähnlichen Syntax nicht der Grund sein sollte, warum ein Unternehmen / Entwickler / was auch immer Flutter ablehnt.
• Wir würden von jedem Dart-Update profitieren. Dies gilt insbesondere für Dart, da Flutter einer seiner Hauptkunden und ein UI-Framework ist. Sehen Sie sich zum Beispiel die new/const Änderungen an.
• Ich lege großen Wert auf Typsicherheit. Ich sage nicht, dass eine JSX-ähnliche Syntax nicht typsicher sein kann, aber ich glaube nicht, dass der Aufwand, sie zu erreichen, seinen Umsatz wert ist.

Abgesehen davon bevorzuge ich eigentlich eine Kotlin-ähnliche Syntax. Vor allem, wenn diese Syntax einige Kotlin-Features zu Dart mitbringt: unschuldig:.

@emalamela ,

Hier ist die Sache, es gibt keinen Kontextwechsel, wie Sie es nennen, fragen Sie einfach einen erfahrenen React-Entwickler. Auch diese Syntaxtrennung ist eigentlich ein großartiges Feature, denn wenn Sie sich den Code ansehen, können Sie leicht erkennen, was deklarativ und was zwingend ist.

Ich denke, dass das Fehlen einer JSX-ähnlichen Syntax nicht der Grund sein sollte, warum ein Unternehmen / Entwickler / was auch immer Flutter ablehnt.

Aber leider wird es für viele React-Entwickler so sein.

Wir würden von jedem Dart-Update profitieren.

Ich verstehe nicht, wie DSX nicht auch von Dart-Updates profitieren kann, da es eine Obermenge von Dart ist.

Ich lege großen Wert auf Typsicherheit. Ich sage nicht, dass eine JSX-ähnliche Syntax nicht typsicher sein kann, aber ich glaube nicht, dass der Aufwand, sie zu erreichen, seinen Umsatz wert ist.

Der Aufwand, Typsicherheit in DSX zu erreichen, ist null, da DSX nur eine winzige syntaktische Zuckerschicht auf Dart ist, also verwendet es das Dart-Typsystem genauso wie es Dart-Steueranweisungen usw. verwendet.
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

Danke für deinen Beitrag @cbazza !

Hier ist die Sache, es gibt keinen Kontextwechsel, wie Sie es nennen, fragen Sie einfach einen erfahrenen React-Entwickler.

Ich bin kein erfahrener React-Entwickler, also ist es für mich ein Kontextwechsel. Genau wie bei Android muss man von Java/Kotlin zu XML springen, auch wenn der Sprung dort größer ist. Eine Sprache, gleiche Tools, weniger Overhead.

Auch diese Syntaxtrennung ist eigentlich ein großartiges Feature, denn wenn Sie sich den Code ansehen, können Sie leicht erkennen, was deklarativ und was zwingend ist.

Wie es jetzt ist, ist meiner Meinung nach ziemlich deklarativ.

Ich verstehe nicht, wie DSX nicht auch von Dart-Updates profitieren kann, da es eine Obermenge von Dart ist.
Der Aufwand, Typsicherheit in DSX zu erreichen, ist null, da DSX nur eine winzige syntaktische Zuckerschicht auf Dart ist, also verwendet es das Dart-Typsystem genauso wie es Dart-Steueranweisungen usw. verwendet.

Faire Punkte. Aber DSX ist immer noch etwas, das gewartet und verbessert werden muss, was immer noch Anstrengungen impliziert, die ich gerne auf andere kritischere / fehlende Aspekte des Ökosystems konzentrieren würde.

Ein weiterer Aspekt der Diskussion, dem ich nicht zustimme, ist der ständige Vergleich mit React. Ich verstehe seine Relevanz, aber ich möchte nicht, dass Flutter eine Kopie von React ohne die JS-Bridge ist und den Namen von Components in Widgets ändert. Wenn es das gleiche ist, warum dann ändern? Das bedeutet nicht, dass Flutter versuchen sollte, so weit wie möglich von React entfernt zu sein. Flutter sollte eine eigene Identität haben. Ich ziehe es vor, dass die Flutter-Kultur des Bereitstellens von Lösungen proaktiv und nicht reaktiv ist. Wir sollten React nur als Kontrastpunkt verwenden, nicht als Richtlinie.

Soweit es mich betrifft, wenn ein Entwickler sich entschied, nicht in Flutter zu entwickeln, weil DSX/JSX nicht unterstützt wird, nun, diese Person wollte Flutter überhaupt nicht beitreten.

Ein weiterer Aspekt der Diskussion, dem ich nicht zustimme, ist der ständige Vergleich mit React. Ich verstehe seine Relevanz, aber ich möchte nicht, dass Flutter eine Kopie von React ohne die JS-Bridge ist und den Namen von Components in Widgets ändert. Wenn es das gleiche ist, warum dann ändern?

Weil React Lücken hat, die Flutter füllen könnte, und dann erstellen Sie etwas, das besser ist als React, weil es die Nachteile von React mit Dart-Leistung und GPU-beschleunigter Grafik behebt, während die besten Teile von React sowie seine Vertrautheit beibehalten werden.

Soweit es mich betrifft, wenn ein Entwickler sich entschied, nicht in Flutter zu entwickeln, weil DSX/JSX nicht unterstützt wird, nun, diese Person wollte Flutter überhaupt nicht beitreten.

Es spielt keine Rolle, das Endergebnis ist, dass Flutter auf dem Markt scheitern wird, wenn mobile Entwickler, die plattformübergreifende Tools verwenden, Flutter nicht beitreten. Flutter muss also React Native-Entwickler anziehen, um zu überleben.

Apropos Evolution, es ist nicht „Überleben des Stärksten“, sondern „Überleben des Anpassungsfähigsten“. Passen Sie sich an oder Sie gehen zugrunde.

@cbazza

Es spielt keine Rolle, das Endergebnis ist, dass Flutter auf dem Markt scheitern wird, wenn mobile Entwickler, die plattformübergreifende Tools verwenden, Flutter nicht beitreten.

Was? Warum sollte es nötig sein? Flutter kann seine eigene Nische bilden, während es in der Beta-Phase ist (wie es sehr erfolgreich getan hat), und dann organisch wachsen, ohne Motten mit oberflächlich ähnlichen Merkmalen anlocken zu müssen. Und was meinst du mit "nicht bestanden"? Flutter muss nicht beliebt sein, um erfolgreich zu sein.

@naiveaiguy
Schau, ich weiß, dass du die Antworten von cbazza abgelehnt hast.
Aber könnten Sie sich 15 Sekunden Zeit nehmen, um sich das anzusehen, bevor Sie meine Antwort ablehnen?

Bevor Sie an DSX denken.
Schauen Sie einfach unten nach, es ist nur ein JSX.

Nachdem Sie eine Navigationsleiste und einen Körper erstellt haben, können Sie einfach den Navigationsbarcode aus Ihrem Navigationsbarcode importieren.

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

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

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

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

Vielleicht hasst jemand JSX, weil es von Facebook stammt, aber tatsächlich stammt es von einer kleinen japanischen Spielefirma.

Nachdem ich Apps mit React Native und Flutter erstellt habe, habe ich das Gefühl, dass JSX im aktuellen Zustand einfacher zu lesen und anzupassen ist als rein verschachtelte Dart-Klassen.
Wie bereits erwähnt, hatte Facebook jedoch einen Grund, JSX zu verwenden, da JavaScript geschrieben ist (z. B. keine benannten Konstruktorparameter), was bei Dart nicht der Fall ist. Auch die zusätzliche Dart-Typensicherheit ist wirklich schön!
Falls Flutter also am Ende bei der reinen Dart-Syntax bleibt, würde ich auf Verbesserungen beim Syntax-Highlighter und Auto-Formatter hoffen. Die neuen schließenden Tag-Kommentare sind bereits eine große Verbesserung, aber nicht genug, um die JSX-Produktivität zu erreichen.

@JonathanSum Sie erklären die Idee wiederverwendbarer Komponenten. Sie brauchen JSX nicht, um wiederverwendbare Komponenten zu erstellen. Ich denke, es könnte etwas Besseres geben, wenn man die Syntax von Dart referenziert, aber DSX ist überhaupt kein guter Weg, dies zu tun.

@hartmannj Wir sind immer auf der Suche nach Verbesserungen der Dart-Syntax, des Highlighters und des Formatters, die die Produktivität steigern. Bei konkreten Ideen oder Vorschlägen für solche Verbesserungen, an die Sie oder andere vielleicht gedacht haben, wäre ich sehr neugierig, mehr zu erfahren.

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

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

React erfordert nicht die Verwendung von JSX, aber die meisten Leute finden es als visuelle Hilfe hilfreich, wenn sie mit der Benutzeroberfläche im JavaScript-Code arbeiten. Außerdem kann React nützlichere Fehler- und Warnmeldungen anzeigen.

Wenn so viele Entwickler begierig darauf sind, JSX-ähnliche Benutzeroberflächen zu erstellen, bedeutet dies, dass der Weg benötigt wird und sie nicht ignoriert werden sollten.

@woodstream Die Art von Leuten, die gerne JSX verwenden, sind bereits Fans von React -Fanboys . Sie verwenden bereits React Native. Flutter richtet sich an einen ganz anderen Entwicklertyp.

EDIT : Ich gebe zu, dass meine Verwendung von Fanboy hier falsch war.

@naiveaiguy , @Hixie

Die Art von Leuten, die eifrig JSX verwenden möchten, sind bereits React-Fanboys. Sie verwenden bereits React Native. Flutter richtet sich an einen ganz anderen Entwicklertyp.

Sie liegen falsch und Ihren Namen nennende spaltende Kommentare ('Fanboys reagieren' & 'andere Art von Entwickler') sind unerwünscht. JSX/DSX hat technische Vorzüge und wird von anderen bevorzugt. Dieser Thread soll darüber diskutieren, wenn es Ihnen nicht gefällt, kündigen Sie es. Hören Sie auch auf, jeden einzelnen meiner Kommentare abzulehnen, es verheißt einfach nichts Gutes für Sie.

Ich schlage nur vor, Entwicklern zwei Möglichkeiten anzubieten, um zu wählen, was ihnen gefällt, und jemand mag es, vor verschiedenen Meinungen Daumen nach unten zu geben? Technologie sollte offen und inklusiv sein, anstatt in einer geschlossenen Gemeinschaft zu spielen.

@anders-sandholm Ich stimme mit @escamoteur über die Notwendigkeit, die Sichtbarkeit des Widget-Baums zu verbessern. Ich hätte sein Beispiel wie folgt gemacht:

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

Außerdem könnte ich mir vorstellen, die Namen der Widget-Klassen mit einer anderen Farbe, Schriftart oder Gewichtung hervorzuheben, damit sie sofort noch besser erkennbar sind.

@cbazza

Namen nennen? Ich habe nicht angedeutet, dass diese Leute negativ sind, nur dass sie anders sind. Ich mag diesen Thread, aber mir vorzuwerfen, dass ich in böser Absicht argumentiere, ist ein bisschen ironisch.

Das Wort "Fanboy" gilt allgemein als abwertend und wurde in diesem Zusammenhang auch so verstanden. Ich empfehle, solche Wörter in Diskussionen hier zu vermeiden.

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.

@hartmannj

Nur ein paar kleine Klarstellungen...

Wie bereits erwähnt, hatte Facebook jedoch einen Grund, JSX zu verwenden, da JavaScript geschrieben ist (z. B. keine benannten Konstruktorparameter), was bei Dart nicht der Fall ist.

Eigentlich hat JS seit ES2015/ES6 benannte Parameter; Sie können dafür einfach 'Destrukturierung' verwenden :)
Hier ist ein Beispiel:

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


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

https://medium.freecodecamp.org/elegant-patterns-in-modern-javascript-roro-be01e7669cbd

Auch die zusätzliche Dart-Typensicherheit ist wirklich schön!

Die gleiche Typsicherheit bekommt man mit DSX, was ja schön ist.

Da dies ein Duplikat des zuvor gemeldeten https://github.com/flutter/flutter/issues/11609 ist, werde ich dieses hier zugunsten dieses schließen.

Ich verstehe wirklich nicht, wie Leute dagegen stimmen können - etwas, das der Art und Weise, wie deklarativer Code im Internetzeitalter geschrieben wird, so selbstverständlich ist.

<like><this /></like>

Bitte seien Sie flexibel genug, um Flattern die Möglichkeit zu geben, zu fliegen!

Leider sieht dies hoffnungslos aus, jede Technologie, die in der Vergangenheit und sogar jetzt Markup zum Erstellen von Benutzeroberflächen verwendet hat, und all diese Entwicklererfahrung wird jetzt durch Flattern verschwendet.

Wir müssen es nicht tun, wie natives oder HTML zu reagieren, verwenden Sie einfach einfaches XML

und vielleichteee... XML in Dart eingebettet! ;P

Am Dienstag, den 28. August 2018 um 21:29 Uhr schrieb Touseef [email protected] :

Wir müssen es nicht tun, wie natives oder HTML zu reagieren, verwenden Sie einfach einfaches XML

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/flutter/flutter/issues/15922#issuecomment-416550338 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AC8aNdVb_NV8c8JH4t36OS1OOvX6kY58ks5uVSmjgaJpZM4S6HPa
.

--
Toni Polinelli

Für mich ist JSX-ähnliche Funktionalität die Zukunft und wird zu einem Standardkonstrukt für deklarative Frameworks wie React, Vue & Flutter.

Wir müssen XML nicht in Dart einbetten, wenn wir nur 2 separate Dateien für UI und Logik haben können, dann können wir einfach mvvm, mvc oder jedem anderen gewünschten Muster folgen.

Ich habe es in dem anderen Thread gesagt, aber:

Wenn Sie JSX wirklich wollen, ist ein guter Starter die Codegenerierung. Gehen Sie mit einer .html - oder .xml -Datei und generieren Sie daraus Widgets.

Offensichtlich ist dies kein vollwertiger JSX, aber es ist ein Anfang. Genug, um zu sehen, wie die Community darauf reagieren wird.
Wenn diese Syntax an Bedeutung gewinnt, wird das Flutter-Team das Thema vielleicht noch einmal überdenken.

Ansonsten halte ich es für Zeitverlust. Wir können hier deutlich sehen, dass es sich um ein stark diskutiertes Thema handelt.

Wenn Flutter einführt und xml / jsx / nennt, wie Sie die Benutzeroberfläche erstellen möchten, würde ich sofort damit beginnen, es für Apps auf Produktionsebene zu verwenden!

Ich stimme @leossmith zu, dass dies die einzige Hürde für Apps auf Produktionsebene ist.

Ich persönlich würde es vorziehen, JSX oder eine externe Auszeichnungssprache _nicht_ hinzuzufügen. Ich ziehe es vor, alles in einer einzigen typgeprüften Sprache zu halten. Meiner Meinung nach ist es ein besserer Ansatz, die Dart-Sprache weiter zu verbessern, um tief verschachtelte deklarative UI-Bäume zu codieren. Sie haben in diesem Bereich bereits einige nette Features hinzugefügt:

• Es hilft, die Schlüsselwörter new und const optional zu machen.
• Virtuelle schließende Tags in der IDE
• dartfmt hilft auch

Ich ziehe es vor, alles in einer einzigen typgeprüften Sprache zu halten

Genau das macht DSX/JSX, die Sprache ist Dart für DSX, Javascript für JSX !!!

Meiner Meinung nach ist es ein besserer Ansatz, die Dart-Sprache weiter zu verbessern, um tief verschachtelte deklarative UI-Bäume zu codieren.

DSX ist eine Verbesserung der Dart-Sprache, um tief verschachtelte deklarative Bäume besser zu unterstützen. Genau wie JSX für Javascript ist.

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

Der Zweck dieser Spezifikation besteht darin, eine prägnante und vertraute Syntax zum Definieren von Baumstrukturen mit Attributen zu definieren.

@cbazza Du sprichst einen guten Punkt an. JSX ist nur eine Verbesserung von JavaScript.

Lassen Sie uns also zunächst zwei Dinge klar trennen:

1. Externe DSL zum Definieren der Benutzeroberfläche. Ich bin zu 100% dagegen. Ich habe immer geglaubt, dass dies mehr Probleme schafft, als es löst. Ich habe einen Blogbeitrag geschrieben, in dem ich diesen Punkt argumentiere. Es hat 58.000 Aufrufe und überraschenderweise fast keine abweichenden Meinungen: 80 % meiner Codierung tut dies (oder warum Vorlagen tot sind)
2. Sprachliche Verbesserungen. Um das Erstellen und Visualisieren tief verschachtelter UI-Baumstrukturen zu vereinfachen. Darin sind wir uns einig, dass es Raum für Verbesserungen gibt.

Aber wir unterscheiden uns leicht in der Herangehensweise. Es gibt zwei Gründe, warum JSX für React sinnvoller ist:

1. Datenstruktur: Im Web entspricht JSX genau dem, was generiert wird (HTML-DOM-Knoten). In Flutter generieren wir Widget-Instanzen.
2. Vertrautheit: Menschen sind es gewohnt, sich HTML-Code anzusehen. Aber der DSX-Vorschlag weicht gerade genug von JSX/XML ab, um diesen Punkt zu entkräften.

Unten sind die zwei Dinge (glaube ich), die XML gut (und lesbar) zum Erstellen von UI-Bäumen machen. Die Frage ist, ob dies erreicht werden kann, ohne XML in die Sprache einzuführen:

1. XML hat End-Tags. Dies ist mit oder ohne XML-artige Syntax möglich. Visual Basic hatte es in den 90er Jahren (denken Sie an End If). Und andere Sprachen haben es. Die IDE bietet "virtuelle End-Tags", aber das ist etwas skizzenhaft. Ich würde Sprachunterstützung bevorzugen.
2. XML hat eine spezielle Behandlung von Kindern. Attribute unterscheiden sich von Kindern. Aber ich würde behaupten, dass dies ein zweischneidiges Schwert ist. Es gibt einige Fälle, in denen Dart in dieser Hinsicht tatsächlich klarer und aussagekräftiger ist als XML. Beispiel: Container-Widgets mit unterschiedlichen untergeordneten Inhaltsmodellen:

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

Dave Vorschlag für End-Tag-Problem

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

Dies wäre für Menschen leicht lesbar. Und ein Parser würde einfach )ButtonsView durch ) ersetzen. Außerdem könnte die IDE eine bessere Überprüfung und Unterstützung bei diesem Schema bieten. Ich würde es immer dann erforderlich machen, wenn sich die öffnenden und schließenden Klammern nicht in derselben Zeile befinden.

Dave Vorschlag für das Problem der verschachtelten Kinder

Einige Sprachen (wie Kotlin) erlauben eine Sonderbehandlung für Argumente vom Typ Lambda. Sie ermöglichen es Ihnen, das Lambda-Argument außerhalb der Klammern zu platzieren. Siehe Übergeben eines Lambda an den letzten Parameter .

Ich schlage etwas Ähnliches für Dart vor, aber als arg vom Typ List, nicht für Lambdas. Ich schlage eine spezielle Syntax vor, um ein Argument vom Typ Liste mit dem Namen "Kinder" zu übergeben:

```
//an Stelle von:
Foo(a: 1, b:10,c:44, Kinder:[...])

//wir machen das:
Foo(a: 1, b:10,c:44)[

]

Für Konstruktoren/Funktionen, die ein einzelnes Kind oder 2 Kinder (wie oben und unten) annehmen, belassen Sie es so, keine Änderung.

Ich ziehe es vor, alles in einer einzigen typgeprüften Sprache zu halten

Genau das macht DSX/JSX, die Sprache ist Dart für DSX, Javascript für JSX !!!

Meiner Meinung nach ist es ein besserer Ansatz, die Dart-Sprache weiter zu verbessern, um tief verschachtelte deklarative UI-Bäume zu codieren.

DSX ist eine Verbesserung der Dart-Sprache, um tief verschachtelte deklarative Bäume besser zu unterstützen. Genau wie JSX für Javascript ist.

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

Der Zweck dieser Spezifikation besteht darin, eine prägnante und vertraute Syntax zum Definieren von Baumstrukturen mit Attributen zu definieren.

@StokeMasterJack - Ihr Vorschlag für das End-Tag-Problem klingt genauso wie mein Vorschlag vor einiger Zeit.
Idee: Automatisch generierte schließende Tags

Ich denke, Flattern braucht so etwas. An den meisten Tagen kämpfe ich damit, neue Widgets in ein tiefes Nest einzufügen. Ich würde eine JSX-ähnliche Syntax verwenden, nur um die End-Tag-Notation zu erhalten.

Ich möchte keine schließenden Tags schreiben müssen. Es ist ein Schmerz in JSX/html/xml. Vor allem, wenn ich refaktorisieren möchte.
Ich finde die virtuellen schließenden Tags ziemlich ordentlich. Es scheint ein guter Kompromiss zwischen beiden Welten zu sein.

Wenn wir hier wirklich einige Verbesserungen brauchen, können wir meiner Meinung nach auf der IDE-Seite weiterforschen. Beispielsweise bietet vscode das folgende Panel:

(Ziemlich sicher, dass Android Studio dasselbe hat)

Anstatt bei der fokussierten Methode anzuhalten, könnten wir auch Konstruktorverschachtelungen hinzufügen.
Wenn wir also den Mauszeiger über eine bestimmte Klasse bewegen, erhalten wir die folgende Benutzeroberfläche:

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

Wenn es darum geht, Widgets visuell von anderen Inhalten zu trennen, kann die IDE dies ebenfalls tun.

Wir können eine andere Syntaxhervorhebung für Widgets haben. Anstelle der üblichen Farbe, die für Klassen verwendet wird, können wir eine bestimmte Farbe für die Widget-Unterklasse verwenden

Wenn es um Bearbeitbarkeit geht, bietet Flutter bereits alle Werkzeuge, die Sie benötigen.

Es gibt einige Refactoring-Optionen, darunter:

• In neues Widget einbinden
• Widget entfernen
• Widget mit Kind tauschen
• Tauschen Sie das Widget mit dem übergeordneten Element aus

In Anbetracht dessen müssen Sie sich nicht mehr mit Klammern befassen.

Ehrlich gesagt habe ich monatelang täglich Stunden damit verbracht, Flutter herumzuspielen. Und ich habe keinen Mangel an Lesbarkeit oder Unbehagen beim Schreiben verschachtelter Widgets verspürt.
Im Vergleich dazu habe ich React genauso oft verwendet und es _gibt_ einige Dinge, die mich frustrieren.

@rrousselGit - diese Refactoring-Optionen, die Sie haben, klingen nützlich. Ich sehe sie nicht auf Android Studio 3.2.
Ich dachte, Android Studio würde die besten Funktionen für die Flutter-Entwicklung bieten.

@Rockvole

Hier ist ein Screenshot von Android Studio:

Als Quick-Fix aktiviert Option+Enter (macOS).
Ich benutze diese die ganze Zeit, super hilfreich.

Zum Thema: Es scheint, dass das Flutter-Team Optionen für "UI als Code" untersucht, und wir könnten früher oder später weitere Verbesserungen an dieser Front erhalten. Obwohl Ideen von @StokeMasterJack interessant klingen.

@Rockvole Große Köpfe denken gleich!

@StokeMasterJack

Schöne Antwort !!!

Es gibt zwei Gründe, warum JSX für React sinnvoller ist:

1. Datenstruktur: Im Web entspricht JSX genau dem, was generiert wird (HTML-DOM-Knoten). In Flutter generieren wir Widget-Instanzen.

Die Stärke von JSX liegt nicht in der Generierung von HTML/DOM-Knoten, sondern in der Verwaltung von Komponentenhierarchien; React Native hat keine HTML/DOM-Knoten, richtig?

1. Vertrautheit: Menschen sind es gewohnt, sich HTML-Code anzusehen. Aber der DSX-Vorschlag weicht gerade genug von JSX/XML ab, um diesen Punkt zu entkräften.

Genau wie oben geht es nicht um HTML-Code, sondern um eine Syntax, die sich klar von den imperativen Konstrukten der Wirtssprache löst und nach deklarativem Markup für den Aufbau von Baumhierarchien schreit .

Ich bin kein Fan Ihres Vorschlags oder des von Kotlin, weil es wie ein Hack aussieht, der gemacht wurde, um ein richtiges Design zu vermeiden. Anstatt eine DSL zu entwerfen, die anders aussieht, muss ich mir jetzt den Code ansehen und versuchen herauszufinden, was er tut. Die Syntax sieht mehrdeutig aus. Es gibt Vorteile für die Trennung von imperativen und deklarativen Konstrukten; Tools von Drittanbietern können beispielsweise problemlos XML-Markup im Code finden.

@Rockvole

Ich würde eine JSX-ähnliche Syntax verwenden, nur um die End-Tag-Notation zu erhalten

Gut zu wissen ;)

@rrousselGit

Ich möchte keine schließenden Tags schreiben müssen.

Das müssen Sie nicht; WebStorm zum Beispiel generiert automatisch das schließende Tag und benennt sogar das öffnende oder schließende Tag um, wenn Sie das andere bearbeiten. Wirklich großartige Editor-Funktionalität, der andere folgen sollten (wenn man sich Ihren 'VS-Code' ansieht).

Ehrlich gesagt habe ich monatelang täglich Stunden damit verbracht, Flutter herumzuspielen. Und ich habe keinen Mangel an Lesbarkeit oder Unbehagen beim Schreiben verschachtelter Widgets verspürt

Ich hoffe, Sie können verstehen, dass Ihre Erfahrung nicht die Erfahrung aller anderen widerspiegelt. Mit den Werkzeugen ist das Schreiben nicht so schmerzhaft wie das Lesen des Codes. Gehen Sie zu github, um den Code anderer Leute zu lesen, und Sie werden feststellen, dass das Lesen mühsam ist, der Code zu ausführlich und lang mit verschachtelten Strukturen ist. Es sieht so aus, als ob Promise-Chains verwendet wurden, bevor async/await einen besseren Weg zeigte. Es fühlt sich auch so an, als wären deklarative Techniken weniger wichtig als imperative; Ich meine, warum gibt es keine deklarativen Vektorgrafik-Konstrukte? Stattdessen muss ich zum Beispiel imperative Aufrufe an Skia zum Zeichnen von Vektorgrafiken verwenden.

Das müssen Sie nicht; WebStorm zum Beispiel generiert automatisch

Vscode macht das auch. Aber dass es immer noch nicht perfekt ist. Besonders im Refactoring-Schritt, wenn Dinge verschoben werden.
Ich denke, dass virtuelle Tags hier eine viel reibungslosere Erfahrung bieten.

Ich hoffe, Sie können verstehen, dass Ihre Erfahrung nicht die Erfahrung aller anderen widerspiegelt

Sicher ! Ich wollte nur darauf hinweisen, dass es vielleicht eher eine Unerfahrenheit mit den Werkzeugen als ein tatsächlicher Mangel ist 😄

Gehen Sie zu github, um den Code anderer Leute zu lesen, und Sie werden feststellen, dass das Lesen mühsam ist, [...]

Ich verstehe nicht ganz, wie Ihre Argumente hier mit dem Thema zusammenhängen.
Das von Ihnen aufgelistete Problem beruht auf schlechten Praktiken, nicht auf schlechter Syntax. Es ist nicht Flutters Schuld, wenn Leute einen 500 langen Widget-Baum erstellen wollen.

@pulyaevskiy - danke für den nützlichen Tipp, unter Linux ist die schnelle Lösung Alt-Enter. Keine sehr leicht zu entdeckende Funktion, ich habe die oberen Menüoptionen durchsucht, aber es scheint nirgendwo zu sein, außer durch magischen Tastendruck :)

Ich denke, dass virtuelle Tags hier eine viel reibungslosere Erfahrung bieten.

Werden diese virtuellen Tags beispielsweise in der Quelldatei in Github angezeigt?

Ich verstehe nicht ganz, wie Ihre Argumente hier mit dem Thema zusammenhängen.

Grundsätzlich könnte die Sprache Konstrukte bereitstellen, um die Dinge weniger ausführlich zu machen, wie ich im Beispiel Promises vs. Async/await erwähnt habe. In Flutter Widget sind die Konstrukteure enorm und benötigen oft viele Parameter; Mit DSX können Sie beispielsweise den Spread -Operator verwenden, um einen 10-zeiligen Konstruktor in einen 1-zeiligen Konstruktor zu komprimieren, und daher können Sie immer noch die vollständige Baumhierarchie mit weniger Rauschen um ihn herum sichtbar haben. Dies erleichtert das Lesen des Codes und ermöglicht beispielsweise eine saubere Trennung von Stil und Baumstruktur. Ich sage nicht, dass dies nicht durch Umstrukturieren Ihres Dart-Codes erreicht werden kann, aber es kann ohne großen Aufwand oder Umstrukturierung von Dingen durchgeführt werden. Sie müssen sich nicht an die Grenzen der Sprache anpassen, die Sprache passt zu Ihnen.

Das von Ihnen aufgelistete Problem beruht auf schlechten Praktiken, nicht auf schlechter Syntax.

Vor async/await bestand die Best Practice darin, überall Promises statt verrückter Event-Callbacks zu verwenden. Die Verwendung von Promises verursacht Lesbarkeitsprobleme, die von async/await behoben wurden. Es ist im Grunde dasselbe, nur syntaktischer Zucker, aber async/await ist klarer, wenn der Code eines anderen gelesen wird.

Dies ist ein schreckliches Beispiel @woodstream

Update : Nur um meinen Standpunkt zu verdeutlichen und nicht nur Worte ohne Argumente zu schlagen. Das DSX-Äquivalent ist genauso lang ... Das hat nichts mit Zeilenanzahl oder HTML zu tun.

class MusicImage extends StatelessWidget {

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

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

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

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

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

Als React-Entwickler denke ich, dass diese Community diese Funktion selbst bereitstellen muss und wann die Entwickler beginnen, sie anzupassen und tatsächlich zu verwenden; die Hauptmitwirkenden werden dann gezwungen sein, es auch nativ anzupassen. Ich bin ein React-Entwickler und habe viele Probleme damit, wie die Benutzeroberfläche in Flutter geschrieben wird. Ich würde gerne zu Flutter wechseln, aber die Syntax hilft nicht. Ich würde sogar nachforschen, wie die JSX-ähnliche Syntax implementiert werden kann Ich selbst, wie gesagt: "Es ist schön, die Option zu haben".

Ich denke, einer der Hauptgründe, warum die Leute dagegen sind, ist, dass sie sich nicht vorstellen können, dass sie es benutzen. Die Wahrheit ist, dass Sie das wirklich nicht müssen, genau wie die Leute React.createElement(Component, {}, null) verwenden (im Vergleich zu reagieren) im Gegensatz zu <Component /> Wenn dies implementiert ist, wird dies die Leute dazu bringen, Flutter im ersten Fall zu verwenden Ort, und das ist es, was wir wirklich wollen. Eine große Flutter-Community mit gegenseitiger Unterstützung. Wenn es nicht die Art von Syntax ist, die Sie verwenden würden, na ja. Aber Tonnen würden eine JSX-ähnliche Notation im Gegensatz zur aktuellen Methode bevorzugen.

Ich persönlich finde SGML und seine Derivate einfach nur hässlich. Wenn wir eine DSL machen, warum nicht eine mit QML-ähnlicher Syntax?

Ich denke auch, dass einige der Pro-DSX-Punkte Funktionen von Javascript als Sprache (die Dart als Sprache nicht hat) und Funktionen von JSX als DSL zusammenführen. Zum Beispiel,

Grundsätzlich könnte die Sprache Konstrukte bereitstellen, um die Dinge weniger ausführlich zu machen, wie ich im Beispiel Promises vs. Async/await erwähnt habe. In Flutter Widget sind die Konstrukteure enorm und benötigen oft viele Parameter; Mit DSX können Sie beispielsweise den Spread -Operator verwenden, um einen 10-zeiligen Konstruktor in einen 1-zeiligen Konstruktor zu komprimieren, und daher können Sie immer noch die vollständige Baumhierarchie mit weniger Rauschen um ihn herum sichtbar haben.

Das ist kein Feature, das DSX auf magische Weise gewähren würde, das ist ein Feature, das JSX hat, weil Javascript es hat. Dart als Sprache könnte den Spread-Operator erhalten (eher unwahrscheinlich IMO), in diesem Fall könnten Sie es mit Konstruktoren und anderen Funktionsaufrufen verwenden, ohne zusätzlich eine spezielle DSL zu benötigen. Es ist auch eine Funktion, die weitgehend funktioniert, weil die Objekte, Hashmaps und Arrays von Javascript im Wesentlichen alle dasselbe sind, was bei Dart definitiv nicht der Fall ist und sich mit ziemlicher Sicherheit nie ändern wird.

Und das ist meiner Meinung nach das Problem, das viele Leute haben, die gegen den Vorschlag sind, auch wenn er nicht ausgesprochen wird – es ist im Wesentlichen eine Bitte, Dart sich wie Javascript verhalten (oder vorgeben, sich zu verhalten) und obwohl es einige Vorteile gibt, ist dies eine Tatsache es sind einfach verschiedene Sprachen, die sich seit den Anfängen von Dart 1 immer mehr voneinander entfernen.

Bearbeiten: Was nicht heißen soll, dass eine Markup-/Modellierungs-DSL für die Benutzeroberfläche eine ganz schlechte Idee ist. Ehrlich gesagt nicht, aber ich denke, dass die Inspiration dafür von Sprachen/Frameworks kommen sollte, die Dart/Flutter etwas ähnlicher sind (in Bezug auf das Typisierungsparadigma sowie andere semantische Details - ich spreche nicht von einfacher Syntax) als Javascript ist.

Dart als Sprache könnte den Spread-Operator gewinnen (eher unwahrscheinlich IMO)

Tatsächlich ist Spread für Sammlungen bereits spezifiziert und bereit für die Implementierung, siehe Spread-Sammlungen und der gesamte "Sprachtrichter" für weitere Informationen über kommende Dart-Sprachfunktionen.

@mraleph Ich habe über den Spread-Operator gesprochen, der speziell in Funktions-/Konstruktoraufrufen und mit Objekten verwendet wird, nicht nur mit Listen oder Karten - das halte ich für unwahrscheinlich. Entschuldigung, wenn das nicht klar war!

(Mir ist dieser Vorschlag vage bekannt, aber das letzte Mal, als ich ihn überprüft habe, können Sie nicht einfach einen Dart Size(10, 10) verbreiten, wie Sie ein Javascript Size { width: 10, height: 10 } verbreiten/zerstören können, oder eine Liste verbreiten /map von Argumenten in einen normalen Funktionsaufruf (ohne Verwendung Function.apply , was die Typsicherheit opfern würde))

@filluchaos

Ich persönlich finde SGML und seine Derivate einfach nur hässlich. Wenn wir eine DSL machen, warum nicht eine mit QML-ähnlicher Syntax?

Denn viele Leute finden es im Gegensatz zu dir nicht hässlich und bevorzugen es eher. Sie müssen nicht viel Vision haben, um all die begeisterten React-Entwickler da draußen zu sehen.

JSX/DSX bringt Markup in die Hostsprache Javascript/Dart auf eine Weise, die die Hostsprache verbessert und alle programmgesteuerten Sprachkonstrukte für das Markup aktiviert. Sehr einfaches und mächtiges Zeug.

Das ist kein Feature, das DSX auf magische Weise gewähren würde, das ist ein Feature, das JSX hat, weil Javascript es hat.

Überhaupt nicht wahr; DSX kann Spread selbst implementieren, es braucht Dart nicht, um es zu unterstützen. Es wäre schön, wenn dies der Fall wäre, aber keine Bedingung. Das ist das Schöne am Transpilieren von einer höheren Sprache in Dart, die höhere Sprache muss nicht durch Dart eingeschränkt werden.

Mein Prototyp des Online-DSX-Transpilers verarbeitet den Spread -Operator einwandfrei, sehen Sie es sich an:
https://spark-heroku-dsx.herokuapp.com/index.html

Und das ist meiner Meinung nach das Problem, das viele Leute haben, die gegen den Vorschlag sind, auch wenn er nicht ausgesprochen wird – es ist im Wesentlichen eine Bitte, Dart sich wie Javascript verhalten (oder vorgeben, sich zu verhalten) und obwohl es einige Vorteile gibt, ist dies eine Tatsache es sind einfach verschiedene Sprachen, die sich seit den Anfängen von Dart 1 immer mehr voneinander entfernen.

Hören Sie auf, darüber nachzudenken, was das aktuelle Dart ist, und konzentrieren Sie sich darauf, was es sein könnte, indem Sie die besten Ideen aus all den anderen Sprachen da draußen nehmen.

Ich denke, dass die Inspiration dafür von Sprachen/Frameworks kommen sollte, die Dart/Flutter etwas ähnlicher sind (in Bezug auf das Eingabeparadigma sowie andere semantische Details - ich spreche nicht von einfacher Syntax) als Javascript.

Typoskript ist typisiert und unterstützt JSX. Das UI-Framework, das Flutter am nächsten kommt, ist React, und raten Sie mal, was React wegen JSX gestartet hat. Bitte denken Sie sich etwas Besseres als JSX/DSX aus, und wenn Sie das tun, werden die Leute aufhören, nach JSX/DSX zu fragen, aber ich habe da draußen nichts gesehen, was ich für besser halte, also ist JSX im Moment der Stand der Technik .

Es ist jedoch schön zu sehen, dass die Dart-Sprachleute die besten Ideen aus anderen Sprachen wie Python (Listen- und Wörterbuchverständnis) übernehmen.

@cbazza

Denn viele Leute finden es im Gegensatz zu dir nicht hässlich und bevorzugen es eher.

Und umgekehrt. Warum diese eine Syntax und keine andere, besonders wenn sie nicht wirklich eine starke Beziehung zur Sprache hat? (Mit dem Android SDK hatten Java und XML seit Jahren eine Beziehung. Dasselbe gilt für Javascript und HTML, denen JSX stark ähnelt. DSX würde, wie vorgeschlagen, eine darauf basierende SGML-Syntax bringen, die für andere Sprachen sinnvoll wäre, aber nicht unbedingt für _Dart_).

JSX/DSX bringt Markup in die Hostsprache Javascript/Dart auf eine Weise, die die Hostsprache verbessert und alle programmgesteuerten Sprachkonstrukte für das Markup aktiviert. Sehr einfaches und mächtiges Zeug.

Überhaupt nicht wahr; DSX kann Spread selbst implementieren, es braucht Dart nicht, um es zu unterstützen. Es wäre schön, wenn dies der Fall wäre, aber keine Bedingung. Das ist das Schöne am Transpilieren von einer höheren Sprache in Dart, die höhere Sprache muss nicht durch Dart eingeschränkt werden.

Es ist ziemlich interessant, diese beiden Aussagen nebeneinander zu betrachten, weil sie nur meinen Standpunkt beweisen. JSX ist besonders wegen seiner Einfachheit großartig (für Javascript) - es ist einfach Zucker über das, was bereits JS-Sprachkonstrukte sind, es implementiert selbst keine spezielle Semantik. Sie loben zu Recht diese Einfachheit und sagen dann, dass DSX Semantik unabhängig von der Zielsprache selbst implementieren sollte, anscheinend ohne zu erkennen, 1) wie viel mehr Arbeit das erfordert, und 2) wie es den Sinn, a zu sein, völlig zunichte macht einfaches, aber leistungsstarkes DSL.

Mein Prototyp des Online-DSX-Transpilers verarbeitet den Spread -Operator einwandfrei, sehen Sie es sich an:
https://spark-heroku-dsx.herokuapp.com/index.html

Ich habe Ihren Transpiler schon einmal gesehen, und obwohl er eine beeindruckende Arbeit leistet, kommt er in keiner Weise der Verarbeitung des Spread-Operators in der Art und Weise nahe, wie es Javascript als Sprache (und damit JSX) standardmäßig tut. Wie bereits erwähnt, steht das Verteilen (und schließlich das Zerstören) von Sammlungen nicht sehr im Widerspruch zu Dart und ist in der Tat in der Pipeline, implementiert zu werden. Das Verteilen und Destrukturieren von Objekten (die im Gegensatz zu JS nicht dasselbe sind wie Maps) ist, und Ihr Transpiler scheint das auch nicht zu handhaben (und erfordert tatsächlich das Einfügen von Argumenten in Maps, was ziemlich unidiomatisch ist und unbrauchbarer Dart (mit dem zum Beispiel nicht auf anständige typsichere Weise interagiert werden kann)).

Hören Sie auf, darüber nachzudenken, was das aktuelle Dart ist, und konzentrieren Sie sich darauf, was es sein könnte, indem Sie die besten Ideen aus all den anderen Sprachen da draußen nehmen.

Sicher. Aber von den Sprachen, aus denen Dart sich abheben kann, steht JS persönlich nicht sehr weit oben auf der Liste - ich denke ehrlich gesagt, dass der Versuch, zu sehr wie JS zu sein (aus Gründen der Interoperabilität), Dart in seinen frühen Tagen lahmgelegt hat.

Ich würde gerne ein UI-DSL haben, klar. Aber dieses DSL sollte idiomatisch für _Dart_ sein und nicht allein wegen der Popularität pauschal aus einer semantisch anderen Sprache gehoben werden.

Und ich möchte auch, dass die Leute aufhören, Javascript mit dem zu verwechseln, was JSX, die DSL, tut, da einige der genannten Vorteile tatsächlich verkleidete Funktionsanforderungen auf Sprachebene sind. Um mit dem Spread-Operator fortzufahren: Wenn Dart als Sprache tatsächlich den gesamten Umfang des Operators unterstützt hat, wie er in JS ist, dann sehe ich nicht, wie return <SomeWidget {...someArgs, arg: newValue } />; besser zu lesen ist als return SomeWidget(...someArgs, arg: newValue); oder QML-ähnliches return SomeWidget { ...someArgs, arg: newValue }; , es sei denn, man hat irgendeine Verbindung zu SGML.

@filluchaos

Warum diese eine Syntax und keine andere, besonders wenn sie nicht wirklich eine starke Beziehung zur Sprache hat? (Mit dem Android SDK hatten Java und XML seit Jahren eine Beziehung. Dasselbe gilt für Javascript und HTML, denen JSX stark ähnelt. DSX würde wie vorgeschlagen eine darauf basierende SGML-Syntax bringen, die für andere Sprachen sinnvoll ist, aber nicht unbedingt für Dart).

Hören Sie auf, Dinge zu paaren, von denen Sie glauben, dass sie zusammenpassen (und eine Beziehung haben), und konzentrieren Sie sich darauf, die besten Ideen auszuwählen, unabhängig davon, woher sie kommen. Sie trennen Dinge irgendwie künstlich, wenn es nicht nötig ist.

Ich wähle die JSX-Syntax, weil sie in React gut angesehen ist und das ist es, was die React-Leute erwarten und wollen. Dieses Ticket handelt davon, wenn das nichts für Sie ist, verwenden Sie es nicht.

Es ist ziemlich interessant, diese beiden Aussagen nebeneinander zu betrachten, weil sie nur meinen Standpunkt beweisen. JSX ist besonders wegen seiner Einfachheit großartig (für Javascript) - es ist einfach Zucker über das, was bereits JS-Sprachkonstrukte sind, es implementiert selbst keine spezielle Semantik. Sie loben zu Recht diese Einfachheit und sagen dann, dass DSX Semantik unabhängig von der Zielsprache selbst implementieren sollte, anscheinend ohne zu erkennen, 1) wie viel mehr Arbeit das erfordert, und 2) wie es den Sinn, a zu sein, völlig zunichte macht einfaches, aber leistungsstarkes DSL.

Ob es eine neue Semantik implementiert oder nicht, ist irrelevant. Einfachheit kommt von seiner Verwendung. Wenn es für Benutzer/Entwickler einfach zu verwenden ist, werden sie es verwenden. Benutzer/Entwickler kümmern sich nicht darum, wie intern etwas komplex ist (oder wie viel Arbeit es war), sie kümmern sich nur darum, wie einfach es ihr Leben macht und ihren Code verbessert.

Ich habe Ihren Transpiler schon einmal gesehen, und obwohl er eine beeindruckende Arbeit leistet, kommt er in keiner Weise der Verarbeitung des Spread-Operators in der Art und Weise nahe, wie es Javascript als Sprache (und damit JSX) standardmäßig tut.

Meine Absicht mit Spread auf DSX war nur, Attribute zu verbreiten und keine vollständige JS-Implementierung von Spread. Es funktioniert gut für das, was es ist, und es gibt überhaupt keine typsicheren Probleme. Typprüfung/Korrektheit findet statt, wenn Dart kompiliert, was DSX generiert.

verkrüppelte Dart in seinen frühen Tagen.

Was Dart in den frühen Tagen beeinträchtigte, war die fehlende einfache JS-Interoperabilität, sodass aktuelle JS-Bibliotheken problemlos mit Dart-Code verwendet werden konnten (und umgekehrt). Dies ist auch der exakt gleiche Grund, warum Typescript dort erfolgreich war, wo Dart scheiterte.

Ich würde gerne ein UI-DSL haben, klar. Aber dieses DSL sollte für Dart idiomatisch sein und nicht allein wegen der Popularität pauschal aus einer semantisch anderen Sprache gehoben werden.

Popularität diktiert alles. Die besten Ideen sind die besten Ideen, weil sie populär werden, weil viele Menschen ihre Vorteile zu schätzen wissen.

Und ich möchte auch, dass die Leute aufhören, Javascript mit dem zu verwechseln, was JSX, die DSL, tut, da einige der genannten Vorteile tatsächlich verkleidete Funktionsanforderungen auf Sprachebene sind.

Auch dies ist nicht relevant.

Was wir wirklich von Google (Dart/Flutter)-Leuten brauchen, ist eine generische Transpiling-Unterstützung über Quellkarten, damit jede höhere Sprache entwickelt werden kann, die auf Dart/Flutter abzielt und mit den aktuellen Tools (IDE, Debugger usw.) gut funktioniert. . Gleichen Sie das Spielfeld aus und Sie garantieren, dass die besten Ideen von anderen auf die Plattform kommen.

@cbazza

Ich wähle die JSX-Syntax, weil sie in React gut angesehen ist und das ist es, was die React-Leute erwarten und wollen. Dieses Ticket handelt davon, wenn das nichts für Sie ist, verwenden Sie es nicht.

Das erscheint mir ziemlich spaltend und recht berechtigt. Warum sollte Flutter erstklassige Unterstützung für die spezifische React-Syntax haben? Warum nicht Vue-Komponentendateien oder Xamarin.Forms-Syntax? Warum muss die (vermutlich offizielle) UI-DSL für Flutter darauf basieren, was eine bestimmte Gruppe von Personen, die ein anderes Framework in einer anderen Sprache verwenden, erwartet und will? Wenn Sie ein Community-Tool speziell für React/JS-Entwickler wollen, wäre das eine Sache. Aber zu verlangen, dass das Framework selbst es nur enthält, um Ihnen allen gerecht zu werden, ist meiner Meinung nach ein bisschen viel.

Ob es eine neue Semantik implementiert oder nicht, ist irrelevant. Einfachheit kommt von seiner Verwendung. Wenn es für Benutzer/Entwickler einfach zu verwenden ist, werden sie es verwenden. Benutzer/Entwickler kümmern sich nicht darum, wie intern etwas komplex ist (oder wie viel Arbeit es war), sie kümmern sich nur darum, wie einfach es ihr Leben macht und ihren Code verbessert.

Das ist meiner Meinung nach eine so seltsame Form der Berechtigung. Und nein, Entwickler werden sich darum kümmern, wie komplex eine Implementierung ist, wenn sie anfängt, Probleme und Feature-Drift zu verursachen, wie dies bei Komplexität in Abstraktionen der Fall ist. Entwickler, die die DSL nicht nur nutzen, sondern zum Beispiel erweitern wollen, werden sich sicherlich Gedanken darüber machen, wie komplex die Implementierung ist. Die Entwickler, die es bauen und warten müssten, sind auch Leute, die dabei berücksichtigt werden müssen.

Meine Absicht mit Spread auf DSX war nur, Attribute zu verbreiten und keine vollständige JS-Implementierung von Spread. Es funktioniert gut für das, was es ist, und es gibt überhaupt keine typsicheren Probleme. Typprüfung/Korrektheit findet statt, wenn Dart kompiliert, was DSX generiert.

Es hat nur "keine typsicheren Probleme", wenn Sie überhaupt nicht darüber nachdenken. Was ich gesagt habe, war, dass Maps von Argumenten nicht auf völlig sichere Weise mit dem Rest einer Dart-Codebasis _verwendbar_ sind, wo Sie vermutlich mit diesen Argumenten so interagieren möchten, wie Sie es mit Requisiten und dergleichen in JavaScript können - sie von einem anderen weitergeben Widget, importieren Sie sie aus einem anderen Modul usw. - und deklarieren Sie sie nicht nur an einer Stelle. Was ist in diesem Fall der Sinn eines normalen Konstruktoraufrufs?

Um zu veranschaulichen, was ich meine, können Sie dies in JS tun:

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

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

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

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

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

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

Aber mit Dart und Ihrem Transpiler erfordert das Hashmaps von Argumenten:

class MyCustomSize {
  int length, width, height;

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

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

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

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

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

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

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

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

Was Dart in den frühen Tagen beeinträchtigte, war die fehlende einfache JS-Interoperabilität, sodass aktuelle JS-Bibliotheken problemlos mit Dart-Code verwendet werden konnten (und umgekehrt). Dies ist auch der exakt gleiche Grund, warum Typescript dort erfolgreich war, wo Dart scheiterte.

Die Interoperabilität von Dart mit JS war noch nie komplex, es sei denn (und das ist ein Punkt, den ich immer wieder betone), Sie wollen einfach immer noch Javascript schreiben und sind abgeneigt, etwas anderes zu lernen. Da Typoskript eine Obermenge ist , ist es nicht so sehr mit JS bedienbar, sondern einfach JS, bis zu dem Punkt, dass absichtlich ein unsolides Typsystem vorhanden ist, nur um JS zu bedienen (sowie keine Laufzeit, um sein ausdrucksstarkes Typsystem tatsächlich durchzusetzen, das a verdammt schade, so viele Jahre später). Aber zurück zu meinem Punkt, ich persönlich habe das Gefühl, dass Dart einige schlechte Designentscheidungen für JS getroffen hat und Dart 2 wirklich die erste Iteration der Sprache hätte sein sollen.

Popularität diktiert alles. Die besten Ideen sind die besten Ideen, weil sie populär werden, weil viele Menschen ihre Vorteile zu schätzen wissen.

„Beste“, oder besser gesagt gute Ideen sind gute Ideen, weil sie einen Wert haben . Manchmal werden sie populär, manchmal nicht. Manchmal werden schlechte Ideen populär, manchmal nicht. Zu behaupten, dass Popularität ein direkter Indikator für Verdienste ist, ist ehrlich gesagt absurd und eine Einstellung, die ich persönlich lieber nicht auf die Dart-Community übertragen würde, so klein sie auch ist.

Was wir wirklich von Google (Dart/Flutter)-Leuten brauchen, ist eine generische Transpiling-Unterstützung über Quellkarten, damit jede höhere Sprache entwickelt werden kann, die auf Dart/Flutter abzielt und mit den aktuellen Tools (IDE, Debugger usw.) gut funktioniert. . Gleichen Sie das Spielfeld aus und Sie garantieren, dass die besten Ideen von anderen auf die Plattform kommen.

... Ich hätte nicht gedacht, dass es möglich ist, noch berechtigter zu wirken, als Sie es vorher waren, und doch sind wir hier. Warum ist es dieses eine UI-SDK, das von jeder Hochsprache auf der ganzen Welt angesteuert werden kann? Wieder einmal kommt der Vorschlag stark, stark als "Make Dart/Flutter into my language/framework" heraus - Sie können genauso gut direkt sagen, dass Sie Flutter-Apps mit Javascript erstellen möchten. Und ja, mehr Fett für Ihren Ellbogen und ich wäre alles dafür, zu einem Gemeinschaftsprojekt wie diesem beizutragen, aber es ist ehrlich gesagt lächerlich, eine positive Antwort zu erwarten, wenn Sie dafür offizielle Unterstützung anfordern.

Nochmals zur Wiederholung - ich habe nichts gegen ein UI-DSL und würde eigentlich eins lieben. Aber wenn wir das Team bitten, es einzubacken, dann sollte es eine DSL sein, die für Dart idiomatisch ist. Denn ja, es gibt Dutzende von uns hier draußen, die Dart als Sprache wirklich mögen.

Noch eine weitere Bearbeitung: Es wäre eine Sache, eine DSL anzufordern, JSX als mögliche Syntax/Syntax-Inspiration vorzuschlagen und offen für andere Vorschläge zu sein. Es ist das Beharren auf DSX , das mich (und ich vermute, viele, die kommentiert haben) falsch reibt.

@filluchaos

Du bist urkomisch verwirrt und ich habe noch nicht viel Zeit zu verlieren.

Das einzige, was ich vom Dart/Flutter-Team verlange, ist das, was ich zuvor gesagt habe:

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

Das bietet alles, was zum Implementieren von DSX, Vue-Komponentendateien, Xamarin.Forms, NativeScript, QML usw. erforderlich ist, und würde es der Community daher ermöglichen, alles zu entwickeln, was sie will, und niemand muss mein DSX „nehmen“. Wenn Sie DSX nicht mögen, können Sie einfach Dart verwenden oder mit Leichtigkeit Ihr eigenes Ding erstellen.

Ich würde sagen, Sie suchen nach Dingen wie https://github.com/dart-lang/build und dartanalyzer.
Sie werden wahrscheinlich ein oder zwei Teile vermissen (wie die Möglichkeit, Analysator-Plugins als Pub-Abhängigkeit zu erstellen), aber ich bin mir ziemlich sicher, dass das Dart-Team damit einverstanden ist.

Auf jeden Fall glaube ich nicht, dass es dem Framework in irgendeiner Weise helfen wird, ständig hart miteinander umzugehen.
Das Beste, was wir daraus machen, ist ein weiteres dauerhaft geschlossenes Problem, weil es "zu heiß" wurde.

@filluchaos

In Bezug auf Ihr 'foo'-Beispiel ist DSX- Spread eine Sache zur Kompilierzeit, also müsste die Karte als const definiert werden, oder ich könnte mir alles andere einfallen lassen, was ich zur Kompilierzeit machen wollte (zum Beispiel eine neues DSX-Schlüsselwort oder eine Anmerkung dafür, gefolgt von der konstanten Karte). Es muss zur Kompilierzeit und nicht zur Laufzeit erfolgen, da Dart das dynamische Einfügen von Konstruktorparametern zur Laufzeit nicht unterstützt. Kein Problem, weil es das Problem löst, das ich lösen wollte, dh das Verteilen von Attributen auf Konstruktoren.

@cbazza Der Punkt ist, dass ein Teil dessen, was den Spread-Operator in JS/JSX so praktisch macht, darin besteht, dass Sie keine Einschränkungen auferlegen müssen, wie "Sie können nur eine Hashmap verwenden" oder "Alle Ihre Argumente müssen zur Kompilierzeit bekannt sein". oder "Sie können mit den Argumenten/Requisiten, die Sie an ein Widget übergeben möchten, nicht auf die gleiche Weise interagieren, wie Sie mit allem anderen interagieren können" (beachten Sie, dass Sie nichts vorgeschlagen haben, um den Fall zu behandeln, in dem das Ding mit den Eigenschaften Sie need ist eigentlich ein Objekt, kein Map-Literal) -0 es ist alles schön und gut, wenn es ein einfaches Beispiel ist, aber so etwas würde in jedem mittelgroßen Projekt _schnell_ extrem frustrierend werden. Ich meine, an welchem ​​Punkt hört man auf, Workarounds, Kompromisse und Anmerkungen anzuhäufen, tritt einen Schritt zurück und fragt sich, ob die Erweiterung tatsächlich gut zu der bestehenden Sprache passt?

JSX war (im Vergleich zu den meisten Templates) so ein Erfolg, weil es Sie nicht dazu zwingt, auf eine bestimmte Weise zu programmieren (oder besser gesagt, Sie nicht dazu zwingt, Code anders zu schreiben, als Sie es ohnehin in Javascript tun würden). Die Verwendung mit _beliebigem_ JavaScript ist so ziemlich schmerzlos; das meine ich damit, eine DSL zu erstellen, die tatsächlich zur Sprache passt. Bei Redux ist es ähnlich. Redux in einer JS-Codebasis ist etwas Schönes (wenn es richtig verwendet wird); Auf der anderen Seite sehen alle Flutter-Beispiele, die ich bei der ausgiebigen Verwendung von Redux gesehen habe, ehrlich gesagt nur schmerzhaft aus, verglichen mit der Verwendung von Streams/dem BLoC-Muster. Das soll nicht heißen, dass sich Dinge nicht mit großem Erfolg überschneiden: Context React und $#$1 InheritedWidget #$ von Flutter implementieren ein gemeinsames Konzept, das die Stärken beider unglaublich gut berücksichtigt. Ich bin nur nicht davon überzeugt, dass JSX derzeit eines dieser Dinge ist - abgesehen von mehreren Änderungen der Sprachebene, sieht es ehrlich so aus, als wäre DSX mühsam zu entwickeln _und_ mühsam für mehr als triviale Beispiele zu verwenden, während man wahrscheinlich schreiben könnte ein JSX-Transformator mit vollem Funktionsumfang an einem faulen Wochenende von Grund auf neu, da es so einfach ist, JS zuzuordnen.

Außerdem war ich vorhin ein bisschen aggressiv und ich entschuldige mich dafür.

@filluchaos

Ich versuche nicht, einen vollständig generischen Spread -Operator zu erstellen, der überall und für alles funktioniert, nicht einmal der für die Zukunft geplante Dart ist so generisch wie der von JS. Was ich mit Spread im Kontext von DSX handhaben möchte, tut es gut. DSX braucht zum Beispiel keine Objekte zu verteilen.

Sammlungen verteilen
https://github.com/dart-lang/language/issues/47

Ich habe super große Projekte mit JSX entwickelt und musste wirklich nie Spread für die Tag-Attribute verwenden. JSX funktioniert großartig ohne es. Der Grund, warum ich DSX hinzugefügt habe, ist, dass es ein Problem für Flutter-Widgets löst, für das es keine einfache Lösung gibt, insbesondere wenn ein Widget 20 Parameter für den Konstruktor benötigt, wie können Sie das in weniger als 20 fortlaufenden Zeilen schreiben, die das Widget erstellen Baum eine Pyramide des Schicksals. Die einzige Funktion von DSX Spread besteht darin, einige dieser Zeilen aus dem Baum zu nehmen und an einer anderen Stelle zu platzieren.

@cbazaa Ich überlege, ob ich React Native oder Flutter verwenden soll. Ich tendiere zu Flutter, weil alles nur Dart ist, damit der Compiler meine UI-Tippfehler überprüfen kann. Siehe auch: https://medium.com/flutter-io/out-of-depth-with-flutter-f683c29305a8

Erkennt JSX auch meine Tippfehler? Ich verwende TypeScript.

Ich hasse HTML / separate Markups. Wenn ich mich zum Beispiel in Angular in HTML etwas/Variablen vertippt habe, finde ich meine Fehler erst nach dem Rendern der Seite.

@sivabudh

Erkennt JSX auch meine Tippfehler? Ich verwende TypeScript.

Ja, einige JSX-Tippfehler werden zur Kompilierzeit abgefangen (z. B. Komponentenname), aber keine Prop-Namen (die zur Laufzeit abgefangen werden), wenn JS/ES6 verwendet wird; aber da Sie TypeScript verwenden, fängt das Typsystem alle JSX-Tippfehler zur Kompilierzeit ab:
https://www.typescriptlang.org/docs/handbook/jsx.html

@cbazza ist dsx Open Source?

@pushqrdx
Noch nicht, ich habe den Quellcode nicht veröffentlicht.

Als Konsument von React + TypeScript und Flutter kann ich mich als Tester anbieten. Prost

Werden wir eine DSX-Quelle haben? Es wird ganz toll!

Ich begrüße die Bemühungen von cbazza, aber ich werde DSX nicht in Flutter verwenden. Teste es aber gerne.

Die Ausgabe Nr. 27141 verfolgt das Hinzufügen von Unterstützung für die Codegenerierung zum Build-System. Dies erfolgt über https://github.com/dart-lang/build mit Builder . Theoretisch sollte es ziemlich einfach sein, einen DSX-Compiler/Transpiler zu verdrahten, wenn diese Funktion fertig ist.

Nach zwei Ausgaben traf ich zum ersten Mal auf ein so hartnäckiges Team.

Dies ist keine Diskussion über JSX, sondern eine Diskussion über die verschachtelte Hölle

Auch wenn Sie keine JSX-Lösung angeben können, sollten Sie die Verschachtelung weniger und den Code besser lesbar machen

Ich denke, der Vorteil von JSX ist offensichtlich, aber das Flutter-Team versucht, ihn zu ignorieren.

JSX löst das Verschachtelungsproblem nicht. Reagieren steht vor dem gleichen Problem

Wenn Sie diese Verschachtelung nicht mögen, sollten Sie sich hooks ansehen, eine Portierung von React-Hooks, die selbst ein Versuch sind, die Verschachtelungshölle zu lösen.

Ich denke, wir sollten herausfinden, warum JSX entsteht. Das liegt daran, dass die Funktion h/createElement schlecht geschrieben und der Code schlecht lesbar ist. Unerwarteterweise ist Flattern jetzt 10.000 Mal schlechter geschrieben als die Funktion h/createElement , was man an den Augen sehen kann

JSX entsteht, weil React im Kern eine Mischung aus Javascript und HTML ist. Die XML-Syntax mit Javascript-Interpolation/Injection erzeugt natürlich JSX.

Flutter ist völlig unabhängig von Javascript und HTML, daher lässt es sich nicht gut in JSX übersetzen. Ich stimme zu, dass Flutter-Projekte oft sehr verschachtelt sind und es kann ein echter Schmerz sein, besonders wenn dartfmt diese stark verschachtelten Zeilen zerschmettert. Entsetzlich.

Ich möchte auch anmerken, dass ich Flutter als schrecklich strukturiert empfand, als ich neu darin war und von React kam, aber es ist objektiv viel einfacher, mit Flutter zu arbeiten, wenn Sie die anfängliche Lernkurve hinter sich haben. Die Lernkurve ist nicht einzigartig bei Flutter, sondern beim Erlernen neuer Frameworks üblich. Flutter ist besonders schwierig, weil es keinen Grund hat, sich wie die HTML-Syntax zu verhalten, mit der viele Leute vertraut sind.

Ich denke, es gibt Möglichkeiten, das Verschachtelungsproblem zu verbessern, und JSX ist nicht die Antwort.

Einige Ideen:

1. Entwickeln Sie einen internen Styleguide, der von den Mitarbeitern verlangt, massive Flatterbäume in kleinere Komponenten zu zerlegen.

2. Bringen Sie dartfmt dazu, offiziell anzuerkennen, dass Flutter im Vergleich zu Dart-Paketen einzigartige Formatierungsanforderungen hat, und arbeiten Sie mit dem Flutter/Dart-Team zusammen, um eine vernünftige Lösung zu finden. @großzügig

3. Verwenden Sie Codegenerierung wie das Paket @stateless @rrousselGit , um es Entwicklern einfacher zu machen, Nummer 1 zu erledigen

Um fair zu sein, das Verschachtelungsproblem tritt meistens auf, wenn wir unseren Code nicht refraktieren wollen.

Widgets sind dafür gemacht, in viele kleinere Stücke zerbrochen zu werden.
Verwendung und Missbrauch des extract widget Refactoring-Tools.

Dies macht den Code viel lesbarer, reduziert die Redundanz und behebt möglicherweise sogar Fehler/erhöht die Leistung.

Obwohl ich größtenteils zustimme, sind Flutter-Widgets so hoch, dass ich viele Leute gesehen habe, die ganze Ansichten in einem einzigen Widget erstellt haben, weil ... es wirklich gut funktioniert und Sie keine Requisiten durch 4-5 weitergeben müssen Ebenen von Widgets. Was Sie dabei verlieren, ist dieser schreckliche verschachtelte Code, der dartfmt in etwas Unkenntliches zerschmettert. Ich verstehe also, warum die Leute es tun, ich verstehe, dass es eine Lösung gibt, aber ich verstehe auch, warum die Leute die Lösung nicht verwenden.

JSX entsteht, weil React im Kern eine Mischung aus Javascript und HTML ist. Die XML-Syntax mit Javascript-Interpolation/Injection erzeugt natürlich JSX.

Wie erklären Sie sich die Tatsache, dass React Native JSX verwendet und nichts mit HTML zu tun hat?

Wie erklären Sie sich die Tatsache, dass React Native JSX verwendet und nichts mit HTML zu tun hat?

Weil es React verwendet. Wahrscheinlich wollten sie die Syntax nicht neu erfinden

Weil es React verwendet. Wahrscheinlich wollten sie die Syntax nicht neu erfinden

JSX ist also nicht wirklich die Mischung aus Javascript und HTML, wie @lukepighetti feststellt , sondern eher ein XML-like syntax extension to ECMAScript without any defined semantics... who's purpose is to define a concise and familiar syntax for defining tree structures with attributes.
Es ist alles in der Spezifikation beschrieben: https://facebook.github.io/jsx/

Soweit ich weiß, wurde React zuerst als react + react-dom mit einem jsx -Compiler veröffentlicht, daher war die Mischung aus HTML und JavaScript natürlich. Danach wurde react verwendet, um andere Renderer wie react-native , react-vr , react-pdf usw. anzutreiben. Ich bleibe also immer noch bei meiner ursprünglichen Aussage vernünftig und sensibel für die Geschichte und den Stammbaum von React. Die Spezifikation von 2019 ist die Spezifikation von 2019 und geht nicht auf die Geschichte von React ein.

Ich stimme zu

Aber für mich gibt es ein größeres Problem. Vue und React funktionieren in dieser Hinsicht ähnlich.
React hat eine createElement und Vue hat eine h Funktion.

Wir instanziieren niemals manuell Komponenten in React und Vue. Es ist der Rahmen, der sich darum kümmert.

Flutter verhält sich anders. Wir manipulieren direkt die Instanz eines Widgets.

Als solches bedeutet ein <Foo /> in der Flutter-Welt einfach nur new Foo()

Aber in diesem Fall ist JSX völlig unabhängig von Widgets. Wir ändern nur die Syntax, wie wir Klassen in Dart instanziieren.

Für mich klingt das so, als würden wir die Bedeutung dessen verlieren, was das Erstellen eines Widgets ist.

@lukepighetti
react-pdf ist kein weiterer Reaktionsrenderer, Sie müssen an react-canvas denken.
Also react != react-dom != react-native . Das Paket react ist für die Verwaltung von Komponentenhierarchien mit Hilfe von JSX verantwortlich, sodass es react egal ist, ob es react-dom , react-native generiert react-canvas , also geht es react nicht wirklich um HTML.

Die Spezifikation von 2019 ist die Spezifikation von 2019 und geht nicht auf die Geschichte von React ein.

Es gibt keine JSX-Spezifikation von 2019. Es gibt nur eine Version von JSX und es ist die Originalversion, die 2014 über den von mir bereitgestellten Link (https://facebook.github.io/jsx/) veröffentlicht wurde.

@rrousselGit

Wir ändern nur die Syntax, wie wir Klassen in Dart instanziieren.

Bei DSX mit Flutter macht genau das der Transpiler.

Für mich klingt das so, als würden wir die Bedeutung dessen verlieren, was das Erstellen eines Widgets ist.

Wie können Sie etwas verlieren, wenn nichts entfernt wird, Sie gewinnen nur eine andere Möglichkeit, etwas zu tun (mit Vor- und Nachteilen), und jetzt haben Sie die freie Wahl, wählen Sie diejenige aus, die am besten zu Ihnen passt.

Hallo, ich glaube, Sie haben meine Nachricht möglicherweise missverstanden. react steuert andere Reaktionsrenderer wie react-dom , react-native , react-pdf , react-vr usw. Afaik, react und react-dom wurden gleichzeitig veröffentlicht, also ist das Erbe von jsx meiner Meinung nach ziemlich klar. Ich hoffe, Sie graben sich nicht in meine Nachricht ein, da wir unterschiedliche Meinungen zum Wert von JSX im Kontext von Flutter haben. Wäre wahrscheinlich am besten, es beim Thema zu halten und nicht Haare zu spalten.

Hallo lukepighetti, hast du ein bis zwei Monate lang React Native mit JSX verwendet? Wenn dies der Fall ist, müssen Sie verstehen, warum das Erstellen einer App mit JSX AND React Native (oder React, ich weiß, dass sie unterschiedlich sind) Framework-Stil einfach und gut strukturiert ist.
Wenn Sie jedoch eine Zeit lang nicht verwendet haben, können Sie nie verstehen, warum JSX so hilfreich und wichtig ist.

Ich hoffe immer noch, dass Google die Schönheit von JSX verstehen kann, da wir viele Leute hatten, die dies unterstützten. Das Google-Team könnte eines Tages über DSX oder JSX für ein von React inspiriertes Framework nachdenken, flattern.

Hallo lukepighetti, hast du ein bis zwei Monate lang React Native mit JSX verwendet? Wenn dies der Fall ist, müssen Sie verstehen, warum das Erstellen einer App mit JSX AND React native (oder React, ich weiß, dass sie unterschiedlich sind) Framework-Stil einfach und gut strukturiert ist.

Ich kann nicht für lukepighetti sprechen, aber ich arbeite seit zwei Jahren professionell mit React und mache jetzt etwas Vue. Ich kenne mich also ziemlich gut aus, wenn es um JSX geht.

Ebenso benutze ich Flutter seit ungefähr 2 Jahren. Zuerst dachte ich auch, dass Flutter eine Art JSX braucht.
Aber Flutter hat sich in dieser Zeit ziemlich verbessert, und ich habe meine Meinung geändert.

• JSX ist schrecklich von Hand zu schreiben. Es erfordert eine Menge Tools, um es erträglich zu machen, einschließlich automatisch schließender Tags, automatisch umbenennter Tags und Emmet. Und selbst dann ist es bei weitem nicht so einfach wie Flutters Syntax.

Beispielsweise ist das Refactoring Foo() in Foo(child: Bar()) einfach.
Aber das Refactoring <Foo /> in <Foo><Bar /></Foo> ist das nicht.

• Flutter bietet viele Refactoring-Optionen, die das Bearbeiten von Klammern noch einfacher machen

• Virtuelle Schluss-Tags, die Flutter anbietet, gleichen das Fehlen von End-Tags aus.
  _Aber sie tauchen nicht in Code-Reviews auf!_
  Das tun sie tatsächlich! Sie können Ihre Code-Reviews von Ihrer IDE aus durchführen. Siehe https://code.visualstudio.com/blogs/2018/09/10/introducing-github-pullrequests

  • JSX lässt sich für das Flutter-Modell nicht gut übersetzen.

Was ist, wenn ein Widget sowohl child als auch children nimmt? Bekommen wir:

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

?

In diesem Fall bedeutet dies, dass child aus Konsistenzgründen immer als benanntes Argument behandelt werden sollte, anstatt den Slot children zu verwenden.

Die Sache ist, dass nur sehr wenige Widgets children . Die überwiegende Mehrheit ist entweder ein einzelnes child oder eine Kombination aus benutzerdefinierten benannten Parametern (wie Scaffold ).

Dies bedeutet, dass die überwiegende Mehrheit der Widgets, die JSX verwenden, folgendermaßen aussehen wird:

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

Was ist dann _schlechter_:

Container(
  child: Bar(),
)

Alles in allem finde ich Flutter in Ordnung. Und selbst wenn JSX verfügbar wäre, bezweifle ich, dass es die Dinge tatsächlich verbessern würde.

Wie ich im Upthread sagte, gibt es meiner Meinung nach eine Menge Vermischungen zwischen dem, was eigentlich JS/ECMAScript/allgemeine Webfunktionen sind (Objektverteilung, Destrukturierung, Austauschbarkeit von Objekten/Hashmaps, alle DOM*-Knoten mit einer sehr ähnlichen Schnittstelle, die Flexibilität von HTML in allgemein usw.) mit den JSX-Funktionen. Die ersteren machen es meiner Meinung nach angenehm, JSX zu schreiben. Ohne sie schreiben Sie nur XML, und die meisten Leute, die ich kenne, die tatsächlich eine Wahl haben, schreiben XML nicht gern.

*Bemerkenswert ist, dass dies vor allem mein größter Widerstand gegen den Versuch ist, Flutter auf XML umzurüsten. Ich glaube nicht, dass es wirklich Sinn macht zu leugnen, dass JSX/React tiefe Wurzeln im Web hat und DOM-Elemente einen langjährigen Standard für jeden Knoten mit _Attributen_ und _Kindern_ haben. Auf der anderen Seite verpflichtet Flutter Entwickler nicht dazu, den Platz eines benutzerdefinierten Widgets für andere Widgets children oder sogar child zu benennen, und ich sehe keinen Grund, warum es damit beginnen sollte.

Ich kann sehen, warum der andere JSX-Thread gesperrt war. Ich sollte meine Fähigkeiten/Erfahrung nicht in GitHub-Kommentaren verteidigen müssen, um zu erklären, warum ich denke, dass JSX Flutter nicht zugute kommt. Ich könnte leicht sagen: "Du hast nicht genug Erfahrung mit Flutter, um eine Meinung zu Flutter zu haben." Fühlt sich nicht gut an, tut es. Ihr genießt euren Keyboard-Krieger-Stamm.

Was ist, wenn ein Widget sowohl child als auch children ? Bekommen wir:

Warum muss ein Widget sowohl child als auch children haben? Entweder dies oder das.
Ein weiteres Thema，Flutters einige Widgets verwenden children und die anderen verwenden child , niemand denkt, dass es kompliziert und leicht zu verwirren ist？ children enthält child , also nein Egal wie viele child Sie haben, eins oder mehr als eins, verwenden Sie einfach children , um die Arbeit zu erledigen.

@rrousselGit

JSX ist schrecklich von Hand zu schreiben. Es erfordert viel Werkzeug, um es erträglich zu machen,

Nicht nur die gesamte React-Welt widerspricht Ihnen, sondern auch die gesamte HTML-Welt und die XML-Welt.

Flutter bietet viele Refactoring-Optionen, die das Bearbeiten von Klammern noch einfacher machen

Sie sagen also, dass Flutter auch viel Werkzeug benötigt, aber da Sie voreingenommen sind, haben Sie das Bedürfnis, die andere Seite zu zerstören. FYI: Das Beste, was Sie tun können, ist zu akzeptieren, dass es mehr als eine Art gibt, etwas zu tun, und dass manche Leute die andere Art, es zu tun, bevorzugen werden.

Das tun sie tatsächlich! Sie können Ihre Code-Reviews von Ihrer IDE aus durchführen.

Das löst nicht das Problem für alle anderen Online-Code-Review-Tools, die von Teams verwendet werden. Diese Tools manipulieren den Quellcode und wenn es nicht im Quellcode ist, existiert es nicht.

JSX lässt sich für das Flutter-Modell nicht gut übersetzen.

Das ist nur Ihre schlechte Meinung, jeder kann sehen, dass DSX Erweiterungen zu JSX hinzufügt, die perfekt zu Flutter passen.
https://spark-heroku-dsx.herokuapp.com/index.html

Sie sagen also, Flutter erfordert viel Werkzeug

Nein, ich sagte "noch einfacher" nicht "erträglich".

Ich antworte häufig auf StackOverflow/Slack und manchmal sogar von meinem Telefon aus.
Und ich habe eindeutig eine schlechte Zeit bei der Beantwortung von HTML-bezogenen Fragen – aber Flutter ist in Ordnung.

Das Beste, was Sie tun können, ist zu akzeptieren, dass es mehr als eine Art gibt, etwas zu tun, und dass einige Leute die andere Art, es zu tun, bevorzugen.

Das funktioniert umgekehrt. Sie sollten das deutlich sehen, die Community ist nicht 100% Fan von JSX. Die Anzahl der Ablehnungen sowohl zu diesem als auch zum vorherigen Thema beweist es.

Das ist nur Ihre schlechte Meinung, jeder kann sehen, dass DSX Erweiterungen zu JSX hinzufügt, die perfekt zu Flutter passen.

Ich bin nicht einverstanden. Die Syntax enthält viele komplexe Zeichen, die auf vielen Tastaturlayouts schwer zugänglich sind.
Es enthält auch Tonnen von Wiederholungen.

Ich verstehe jedenfalls nicht, warum du dauernd so aggressiv bist. Wir alle versuchen, Flutter besser zu machen.
Es hat keinen Sinn, hart zu sein und diese Diskussion wieder zu beenden.

Wenn JSX im Flattern nicht gut funktioniert, kann ich akzeptieren, JSX nicht beizutreten, aber wir sollten Nested Hell in Betracht ziehen.

Eine weitere Nebengeschichte ist das Semikolon der Dart-Sprache. Es ist wirklich nervig.

Eine weitere Nebengeschichte ist das Semikolon der Dart-Sprache. Es ist wirklich nervig.

Dazu gibt es eine Anfrage auf dart-lang/language: https://github.com/dart-lang/language/issues/69
Gib ihm ein 👍

In dieser langen Diskussion geht es darum, dies verwenden zu können:

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

An Stelle von:

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

Auch wenn man der früheren Syntax zustimmt, überlegen zu sein, was ich persönlich nicht tue, bringt dies laufende Wartungskosten, höhere Komplexität und neue mögliche Fehlerquellen mit sich, nicht nur in der Sprache / im Framework, sondern auch in den umgebenden Tools wie IDEs, Debugger, Linter usw. Es erhöht auch die Build-Zeiten. Und es erfordert, dass Entwickler eine neue Syntax lernen und sich mit den Interna des Transpilers beschäftigen, um zu verstehen, wann und wie Instanzen erstellt werden. Das alles so ziemlich mit dem einzigen Ziel von React & Co. Entwickler fühlen sich wie zu Hause.

Bevor ich mit neuen Sprachen beginne, konzentriere ich mich lieber auf die Verbesserung von Dart, das alles andere als ideal ist und wichtige Funktionen wie Musterabgleich , Datenklassen , ADTs , Destrukturierung , richtige Optionals usw. vermisst. Einige dieser PRs sind bereits 5+ offen Jahre. Im Gegensatz zum Hinzufügen einer kosmetischen und unnötigen Markup-Ebene zum Erstellen von Widgets hat dies einen enormen Einfluss auf Architektur, Sicherheit und allgemeine Codequalität.

Auch wenn dies auf „von der Gemeinschaft angetrieben“ verbannt wird, ist es immer noch Zeit, die die Gemeinschaft damit verbringen könnte, an etwas Sinnvollem zu arbeiten. Aber natürlich kann jeder mit seiner Zeit machen was er will. Hören Sie bitte auf, diesen unverhältnismäßigen Druck auf das Flutter-Team auszuüben.

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

Hey i-Schütz.
Es gibt einen Antwortbereich.

Das habe ich in diesem langen Beitrag gesagt. JSX hat das "Spaghetti-Problem von HTML und XML" (unlesbarer und komplizierter UI-Code) behoben. Meiner persönlichen Meinung nach ist es nach der Verwendung von Flutter komplizierter als JSX oder am schlimmsten.

In diesen Jahren habe ich Leute gesehen, die sagten, Flutter könne einige der Vorteile von React nicht nutzen, zum Beispiel, die wahre Idee von allem seien Komponenten.

Ich bin mir nicht sicher, ob ich folgen kann. In dem von Ihnen hervorgehobenen Text sagt der Benutzer, dass er JSX leichter zu erlernen fand, weil er mit HTML vertraut war und es eine ähnliche Syntax hat. Ich sehe nicht ein, wie dies die Existenz von JSX und noch weniger eine Imitation von Flutter in irgendeiner Weise rechtfertigt.

Ich habe die Antworten nicht zu den Screenshots hinzugefügt, einfach weil die Bilder zu viel Platz beanspruchen würden. Sie schienen das, was ich gepostet hatte, eher zu unterstützen, also auch überflüssig. Links habe ich gepostet.

@JonathanSum ist Flutter komplizierter als JSX, oder unterscheidet sich Flutter von _React_ und das verursacht Reibung bei dir? Es ist in einigen Fällen ausführlicher, ja, und ohne virtuelle schließende Tags in einer IDE wohl weniger lesbar, aber ich bin mir nicht ganz sicher, warum die Verwendung von Konstruktoren _komplizierter_ ist als das Schreiben einer XML-ähnlichen DSL, und ich bin mir immer noch nicht ganz sicher warum so viele Leute zu denken scheinen, dass XML-ähnliches DSL eine Wunderwaffe wäre, die die Verwendung von Flutter leichter _verstehen_ machen würde. Vor allem wenn man bedenkt, dass Flutter keine Vorgeschichte mit den Problemen hat, für deren Lösung React/JSX geschaffen wurde – React macht die DOM-Manipulation einfacher und sauberer, und das ist schön, aber was genau hat das nochmal mit Flutter zu tun?

In diesen Jahren habe ich Leute gesehen, die sagten, Flutter könne einige der Vorteile von React nicht nutzen, zum Beispiel, die wahre Idee von allem seien Komponenten.

Ohne die Vorstellung zu berühren, dass React eine "wahre" Vorstellung davon hat, dass alles Komponenten sind, die Flutter nicht hat, gibt es auch einige Vorteile des Designs von Flutter/Dart, die React/JS nicht erfassen kann. Und Sie können dasselbe (und umgekehrt) für die meisten anständigen UI-SDKs/Frameworks/Bibliotheken sagen. Unglaublicherweise sind verschiedene Projekte tatsächlich verschieden; Vielleicht sind die Leute, die zu einem Projekt kommen, besser bedient, wenn sie nicht zu Beginn erwarten, dass es [Projekt einfügen, das sie in der Vergangenheit verwendet haben] ist. 🙂

Es gibt einige interessante Ideen da draußen https://github.com/munificent/ui-as-code

Es wäre höchstwahrscheinlich eine ziemlich bahnbrechende Änderung, aber der Vorschlag zur Parameterfreiheit brachte mich zum Nachdenken, wie viel prägnanter Build -Methoden sein könnten, wenn Dart zB Crystals method arguments spec hätte.

Natürlich würde der Compiler von Crystal in einem Rennen gegen eine Schnecke und eine Schildkröte den letzten Platz belegen, also das war's 😅

Ich stimme jetzt zu, JSX nicht hinzuzufügen und keinen zusätzlichen Druck auf das Flattern auszuüben.

Aber was Dart betrifft, ist es weitaus weniger elegant als JS oder TS. Ich fühle mich hilflos

Beispielsweise ist der Entwicklungsweg der Microsoft-UI-Technologie WinForm zu WPF，und jetzt in Flutter，WPF aufgeben und stattdessen WinForm verwenden。Als Reaktion auf die Beschwerden der Entwickler hat das Flutter-Team hart daran gearbeitet, das visuelle Fenster und den Eigenschaftseditor von WinForm zu implementieren。

Als Flutter-Neuling muss ich sagen, dass dies auf der Roadmap stehen sollte. Wenn nicht jsx, eine besser lesbare Art, Widgets abzulegen.

Ich kann eine Renderfunktion der React-Klasse und ein Bild der gerenderten Klasse sehen und im Moment assoziieren.

Ich kann eine Dart-Datei und den gerenderten Inhalt sehen und ich werde 5-6 Minuten brauchen, um herauszufinden, wie es funktioniert ...

Ich kann eine halbkomplexe Reaktionsklasse in 5 Minuten in einem einfachen Texteditor erstellen, weil es intuitiv ist

Ich kann das nicht im Flattern. Ohne Autovervollständigung bin ich als Entwickler fertig. Ich bin nicht gerne auf eine Erweiterung angewiesen, um etwas zu entwickeln -.-

Aber. Es wird interessant sein, wie Dart-Entwickler mit diesem "Problem" umgehen. In Dart 2 haben sie es lesbarer gemacht. Ich weiß nicht, wie sie die Lesbarkeit in Dart 3 -4 -5 verbessern werden. aber ich denke, dass früher oder später eine Überarbeitung der Komponenten-Build-Funktion erforderlich sein wird.

BEARBEITEN:
Macht nichts, habe gerade React Native noch einmal ausprobiert, und ich hasste jsx, das Requisitensystem, die Tatsache, dass alles dynamisch war, war wieder ein wirklich beängstigendes Konzept, ich denke, es ist dann nur eine persönliche Meinung. Flattern lassen wie es ist....

Sie forderten DSX an, nicht nur, weil sie JSX lieben. Sie wollen Flutter.

Die UI-Deklaration sollte im Code visuell getrennt werden, um die Lesbarkeit und Unterstützung des Codes zu verbessern. Vor allem in großen Mannschaften mit vielen Junioren/Mittleren. Von Adobe Flex kommend kann ich sagen, dass das Lesen der UI-Deklarationen von Flutter die Produktivität stark reduziert.
Wenn nicht DSX (was meiner Meinung nach großartig wäre), sollte mit der aktuellen Situation zumindest auf IDE-Ebene etwas unternommen werden.
Alle früheren UI-Entwicklungsframeworks hatten diese Funktion und wir sollten sie auch haben.

Die UI-Deklaration sollte im Code visuell getrennt werden, um die Lesbarkeit und Unterstützung des Codes zu verbessern.

und für eine bessere Integration mit anderen Tools wie zum Beispiel 'GUI-Buildern'.

Von Adobe Flex kommend kann ich sagen, dass das Lesen der UI-Deklarationen von Flutter die Produktivität stark reduziert.

Stellen Sie sich eine UI-Deklaration wie MXML mit Flutters-Power vor! Ich kann nur träumen!

Jetzt, wo wir Codegen-Unterstützung haben, ist der beste Weg, so etwas in das Produkt zu bekommen, ein Paket zu erstellen, das es ermöglicht und zeigt, dass es sehr beliebt ist.

@Hixie gibt es einen Hinweis auf doc für Codegen?

Jetzt, wo wir Codegen-Unterstützung haben, ist der beste Weg, so etwas in das Produkt zu bekommen, ein Paket zu erstellen, das es ermöglicht und zeigt, dass es sehr beliebt ist.

Es sieht für mich so aus, als wäre Codegen nur für .dart -> .dart, die Eingabedatei muss eine gültige .dart-Datei sein. Das ist für .dsx-Dateien nicht sehr nützlich, da es sich um eine Obermenge von dart handelt. Ich brauche immer noch Unterstützung für das Cross-Compiling in .dart mit Quellkarten wie Funktionen zum Debuggen usw.

Bitte werfen Sie einen Blick auf SwiftUI, das gestern veröffentlicht wurde. Dies scheint das Ziel von Flutter zu sein, anstelle von React-ähnlichem Markup.

Allein Swifts implizite Mitgliederausdrücke wären so erstaunlich

Ich bin gemischt über die SwiftUI-Syntax. Es ist sicher leicht, aber einige Aspekte sehen magisch aus.

Aber wir können technisch schon etwas relativ Ähnliches haben:

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

Das ist gültiger Dart-Code, wobei Column _noch_ eine Klasse ist.

Hier ist ein zustandsloses Widget, das es zeigt:

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

  final List<Widget> children;

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

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

Es ist Boilerplat-ish, aber ein Code-Generator kann helfen – besonders bei den kommenden Erweiterungsmitgliedern.

Das einzige Problem bei diesem Ansatz ist, dass wir sowohl konstante Konstruktoren verlieren (da er eine Funktion verwendet, um untergeordnete Elemente anzugeben) als auch die Widget-Klasse _zweimal_ instanziieren.

Wenn diese Syntax gewünscht wird, sollte sie idealerweise anstelle einer call -Methode mit Konstruktor-Currying implementiert werden.

@rrousselGit Ich bin neugierig, welche Aspekte von SwiftUI für Sie magisch aussehen - es scheint mir eine ziemlich einfache Erweiterung der Swift-Syntax zu sein.

Auf ihrem Codebeispiel von hier :

• Content ist änderbar? Bedeutet das, dass sie einen eingebauten Mobx / Vue Store haben?
• Was ist das @State ?
• Warum ist body eine Variable? Ist das ein Getter? Wenn ja, wann wird der Getter erneut aufgerufen?
• ist body Teil einer Schnittstelle oder viele ähnliche Variablen innerhalb Content ?
• Was macht das item in _genau_? Warum ist der rechte Operand von in nichts Iterierbares, sondern das "Ergebnis"?
• Warum ist das Image links neben dem Titel/Untertitel ausgerichtet, wenn es kein HStack gibt?

Ich kann mich nicht genau erinnern, aber ich bin mir ziemlich sicher, dass ich solche Fragen nicht hatte, als ich Flutter in die Hand nahm.

@rrousselGit Das könnte an Ihrem Hintergrund liegen, nicht daran, dass Flutter-Syntax oder -Semantik von Natur aus offensichtlich ist (ich habe viele Leute getroffen, die davon ziemlich ratlos waren). Und die Punkte, die Sie angesprochen haben, scheinen eine seltsame Kreuzung zu sein, bei der ein 14-zeiliges Code-Snippet auf Fehler überanalysiert wird, ohne die Sprache zu kennen, in der es geschrieben ist.

• Es ist aber nicht wirklich veränderbar (im Sinne von Dart oder JS)? Es ist eine Struktur. Auch Stores im Stil von MobX/Vue (dh das Überschreiben einer ziemlich begrenzten Sprachunterstützung) sind nicht die einzige Möglichkeit, mit Mutabilität umzugehen

• @State ist ein Attribut, in einigen Sprachen auch als Anmerkung bekannt (z. B. Dart), ansonsten als eine sehr häufige Sache im Swift-Code bekannt. Wenn Sie meinen, was es tut, markiert es höchstwahrscheinlich eine Eigenschaft als Zustand, der sich im Laufe der Zeit ändert, auch ohne sich die Dokumente anzusehen.

• body ist eine berechnete Eigenschaft, die für Swift-Entwickler leicht ersichtlich ist. Wenn es neu berechnet wird, sagt Ihnen Widget build(BuildContext context) auch von Natur aus, wann es erneut aufgerufen wird?

• Content (wieder ganz klar für Swift-Entwickler) erweitert/implementiert View , wo Sie nach Antworten auf Ihre Frage suchen würden (es hat tatsächlich eine sehr schöne API-Referenzseite).

• Das ist so ziemlich "Warum ist das Schlüsselwort in dieser Sprache nicht dasselbe wie das Schlüsselwort in der Sprache, die ich verwende", nichts besonders "Magisches". Das Schlüsselwort in hier ist nicht dasselbe wie ein for...in -Konstrukt – es zeigt an, dass der Hauptteil einer Closure gleich beginnt. { item in ... } ist ein Funktionsblock, der an den Konstruktor List übergeben wird; a ListView 's itemBuilder , wenn Sie so wollen.

• Fragen Sie berechtigterweise, warum eine Ansicht ihre eigenen gekapselten Layoutregeln hat?

Auf SwiftUI:

1-Es ist schön zu sehen, dass der Zustand in der Ansicht deklariert wird und nicht als seitlicher Anhang.

2-Nette individuelle Methoden, um Dinge zu setzen, anstatt alles an den Konstruktor weitergeben zu müssen (Methoden ermöglichen es, dass Aktionen wirksam werden, anstatt nur Daten zu übergeben).

3-Sehr schön zu sehen, dass deklarative Vektorgrafiken mit allem anderen, was deklarativ ist, vermischt sind (wie ich in der Vergangenheit mit deklarativen SVG-ähnlichen Widgets vorgeschlagen habe) !!!
https://developer.apple.com/tutorials/swiftui/drawing-paths-and-shapes

4-Sehr einfache Animations- und Übergangskonstrukte
https://developer.apple.com/tutorials/swiftui/animating-views-and-transitions

5-Drag&Drop-Design-Tools synchron mit dem Code-Editor in beide Richtungen.

Es gibt Warzen wie alles andere, aber ich konzentriere mich lieber auf das, was sie sehr schön gemacht haben.

Diese "Fragen" existieren nur, um potenziell verwirrende Punkte aufzuzeigen. Das sind keine _eigentlichen Fragen_.

Das mag an deinem Hintergrund liegen

Wahrscheinlich. Ich sage nicht, dass ihr Ansatz schlecht oder so ist. Ich sage, es fühlte sich für mich nicht so natürlich an wie bei Flutter.
Flutter-Widgets verwenden fast keine "ausgefallenen Sprachfunktionen" und könnten in fast allen Sprachen implementiert werden (obwohl die jüngsten if / for-Sammlungen dies ändern).
Während ihr Schaufenster von SwiftUI ausgiebig Swift-spezifische Funktionen nutzt.

Wenn es neu berechnet wird, sagt Ihnen Widget build (BuildContext context) auch von Natur aus, wann es erneut aufgerufen wird?

Mein Punkt hier ist die fehlende Beziehung zwischen State und der Neuberechnung von body .
React und Flutter sind in dieser Angelegenheit sehr explizit: setState.
Vue/Mobx sind "magisch" und verwenden dieselbe @State -Funktion.

Es ist wirklich in Ordnung, aber das ist ein anderes Muster.

Fragen Sie berechtigterweise, warum eine Ansicht ihre eigenen gekapselten Layoutregeln hat?

Nein, es ist eher ein "explizit" vs. "implizit".
Es scheint, dass sie sich wirklich darauf konzentriert haben, "so viel wie möglich in so wenig Code wie möglich zu tun", auch wenn dies einen Teil der Logik verbirgt (in diesem Fall die Logik von ltr vs. rtl ).

Flutter würde Sie bitten, ein Row zu verwenden.

Flutter verwendet und stützt sich auf viele "ausgefallene Sprachfunktionen" (sprich: Sprachfunktionen, an die der Sprecher nicht gewöhnt ist und / oder mit denen er nicht einverstanden ist). Ganz spontan sind konstante Konstruktoren (und Darts Art der Benennung von Konstruktoren im Allgemeinen), das Überladen von Operatoren, Klassen als implizite Schnittstellen, @covariant und Mixins Funktionen, die Reaktionen von Verwirrung auf die direkte Kennzeichnung als hervorrufen würden ein Codegeruch, der vom Hintergrund eines Entwicklers abhängt. Ich könnte wahrscheinlich eine längere Liste erstellen, wenn ich eine Stunde darüber nachdenke. Und das ist weder eine Anklage gegen Flutter noch eine Anklage gegen SwiftUI - ich verstehe nicht, warum man denken sollte, dass es eine Tugend ist, Software in einer bestimmten Sprache zu schreiben, damit sie in jeder Sprache auf die gleiche Weise geschrieben werden kann - was soll's Punkt verschiedener Sprachen, wenn wir so tun sollen, als gäbe es keine Unterschiede zwischen ihnen?

Außerdem stimme ich überhaupt nicht zu, dass entweder setState oder @State ihre Beziehung zum Wiederaufbau einer Ansicht explizit angeben. In beiden Fällen wird Ihnen einfach gesagt, dass, wenn Sie etwas ändern, das als Status markiert ist, das Framework aussortiert, was zu bauen ist. In beiden Fällen hat der Entwickler immer noch keine explizite Kontrolle darüber, was passiert oder wann genau. Sie finden einen Funktionsaufruf vertrauter, Leute, die in anderen Sprachen arbeiten, finden Dekorateure vertrauter. Aber das Aufrufen einer Funktion macht die Dinge nicht unmagisch.

Flutter würde Sie bitten, ein Row zu verwenden

Ich nehme an, Sie haben noch nie ListTile verwendet, das das gleiche Verhalten wie hier gezeigt hat, aber mit benannten Parametern? Sollten wir uns auch fragen, warum ein Scaffold "magisch" eine Menüschaltfläche links in Ihrer Appbar platziert, obwohl Sie es nicht darum gebeten haben?

Der Unterschied besteht darin, dass Dart im aktuellen Zustand den meisten Mainstream-Sprachen sehr ähnlich ist.

Das ist wichtig.
Die Frage "Muss ich Dart lernen oder kann ich gleich anfangen Flutter zu lernen?" kommt ziemlich oft vor.
Im Moment lautet die Antwort: "Lernen Sie einfach Flutter. Sie können nach einem einzigen Tag effektives Dart schreiben."
Das wird garantiert nicht für immer so bleiben, aber ich denke, dass dies eine der Stärken von Flutter ist.

Der Rest der Diskussion ist etwas off-topic. Wenn Sie möchten, können wir diesen Teil per E-Mail fortsetzen (meine Github-Mail funktioniert).

Warum ist das nicht gesperrt? Dies entwickelt sich bereits schlecht, und es ist genau das gleiche wie ein gesperrtes Problem früher.

Ich habe hier eine einfache gemacht:
https://github.com/danialdezfouli/flutterjsx
https://www.npmjs.com/package/flutterjsx
https://www.youtube.com/watch?v=Oj1JMSurphA

Dieser Thread wurde automatisch gesperrt, da es nach seiner Schließung keine Aktivitäten mehr gegeben hat. Wenn Sie immer noch ein ähnliches Problem haben, öffnen Sie bitte einen neuen Fehler, einschließlich der Ausgabe von flutter doctor -v und einer minimalen Reproduktion des Problems.