Flutter: Considérez JSX-like comme React Native

Cela fait longtemps qu'on se le demande :
https://github.com/flutter/flutter/issues/11609
Prototype fonctionnel développé :
https://spark-heroku-dsx.herokuapp.com/index.html
Cela montre l'alternative et certains avantages...

Le problème actuel avec DSX concerne l'intégration correcte avec les outils Flutter afin de fournir une excellente expérience de développement avec un débogueur, une saisie semi-automatique, etc. travaillant sur des fichiers .dsx.

Dire aux utilisateurs qu'ils peuvent utiliser DSX mais qu'ils ne peuvent pas utiliser le débogueur ou profiter de la saisie semi-automatique n'est pas un début pour moi. Si quelqu'un veut aider, ce dont j'ai besoin est de trouver un moyen d'ajouter une prise en charge complète du prétraitement (avec carte source) au plug-in Dart Tools et VS Code Dart. Une fois que les outils prennent en charge ce DSX ou tout autre langage de transpilation (tout langage qui est un sur-ensemble de Dart mais compile tout jusqu'à Dart) fonctionnerait simplement.

Si vous pouvez et souhaitez aider, faites le moi savoir.

Je ne peux pas être d'accord. Surtout en utilisant un IDE comme Dart Code, vous obtenez des balises de fermeture virtuelles qui facilitent la lecture. Avec Dart2 où vous pouvez omettre new , cela ira encore mieux.

De plus, je trouve que cela vous décourage de créer des arborescences de widgets trop grandes sans les déconstruire en classes de widgets plus petites et plus faciles à gérer.

J'utilise Androïd Studio. Je ne vois même pas de balise de fermeture virtuelle. Même si nous avons une balise de fermeture virtuelle, c'est plus compliqué que le HTML que tout le monde déteste. Dart n'est qu'un langage de programmation. Les gens de Google ne comprennent pas l'importance de la simplification.

Je ne pense pas non plus que j'aimerais une syntaxe de type JSX, mais oui, j'utilise IntelliJ et il faut faire quelque chose avec l'outillage pour que le code de l'interface utilisateur soit plus facile à comprendre.

De plus, je trouve que cela vous décourage de créer des arborescences de widgets trop grandes sans les déconstruire en classes de widgets plus petites et plus faciles à gérer.

Je ne vois pas en quoi cela est différent de JSX... à mesure que l'arbre s'agrandit, vous pouvez vous diviser en sous-arbres plus petits avec les deux.

Je ne pense pas non plus que j'aimerais une syntaxe de type JSX, mais oui, j'utilise IntelliJ et il faut faire quelque chose avec l'outillage pour que le code de l'interface utilisateur soit plus facile à comprendre.

et il devrait être facile à lire sur toutes les plateformes et pas seulement sur Intellij ; Je veux dire qu'il devrait être facile à lire sur Bitbucket lors de la révision du code ; et il devrait également être valide lors de l'utilisation de n'importe quel éditeur ; Je veux dire avec ces "annotations de commentaires", que se passe-t-il si quelqu'un utilisant "vi" tape un commentaire différent là-dedans ?

Ceci est une copie du #11609 verrouillé
@sethladd ?

Toutes mes excuses, vous devriez voir les "balises de fermeture virtuelles" dans IntelliJ et Android Studio.

cc @devoncarew pour vérifier quelle version l'a activé, ou si l'utilisateur doit s'inscrire ?

Nous vous remercions pour vos commentaires concernant la syntaxe de type JSX. Nous pensons qu'il existe une opportunité à travers le langage, nos outils et nos plugins pour faciliter l'édition du code de l'interface utilisateur.

Cela fait dupe # 11609 mais j'aimerais que @devoncarew ou @mit-mit ajoute une note sur la façon d'activer les "balises de fermeture virtuelles", si possible.

Merci!

@JonathanSum , les étiquettes de fermeture ne sont malheureusement pas disponibles dans Android Studio 3.0. Vous aurez besoin d'au moins IntelliJ 2017.3 ou Android Studio 3.1. Android Studio 3.1 est actuellement en phase de release candidate, et nous prévoyons de publier demain un plug-in Flutter avec prise en charge.

Indépendamment de la conversation autour d'une syntaxe de type JSX, nous souhaitons travailler à faciliter l'écriture de code d'interface utilisateur dans Dart, à la fois dans IntelliJ / Android Studio et dans VS Code. C'est d'abord le travail d'étiquette de clôture, mais aussi la récente vue Flutter Outline. Cela montre la structure de votre méthode build () dans une vue hiérarchique et vous permet de naviguer dans les widgets et de voir plus facilement leurs relations parent / enfant. C'est actuellement disponible dans IntelliJ - nous espérons pouvoir également l'apporter à VS Code.

@zoechi - Cela pourrait être un doublon; mais l'autre fil s'est chauffé et s'est verrouillé. Il n'y a donc aucun moyen de contribuer à cette conversation. Je ne pense pas que vous devriez fermer ce fil en tant que doublon simplement parce que vous n'aimez pas que les gens demandent une fonctionnalité. Cela devrait probablement être le nouveau fil de discussion pour les réponses des nouvelles personnes venant et demandant le support JSX (ou une fonctionnalité similaire).

@sethladd - Veuillez ne pas verrouiller ce fil ; Je pense qu'il est utile que la communauté discute des avantages et des inconvénients des méthodes de mise en page alternatives. J'aurais participé au #11609 s'il n'avait pas été verrouillé.

Je viens d'un milieu NativeScript. Je dois dire que c'est un domaine dans lequel je pense que NativeScript est considérablement plus facile à utiliser que Flutter. Je peux faire fonctionner des écrans assez complexes en moins de 5 minutes et itérer facilement la conception rapidement. Ajoutez ensuite le code qui exécute l'écran.

En NativeScript, nous avons en fait les fichiers suivants :

• screen.js / screen.ts (.ts est transpilé en .js si vous préférez le tapuscrit). Il s'agit de la logique principale de l'écran que vous affichez.
• screen.css (ou screen.android.css et/ou screen.ios.css ) qui est une version beaucoup plus limitée de CSS mais prend en charge des choses comme la hauteur, la largeur, la couleur, l'arrière-plan, etc. La plupart du temps un seul fichier CSS est nécessaire, mais parfois, si vous faites quelque chose de bizarre, vous pouvez séparer votre CSS pour Android et iOS. Il prend entièrement en charge les classes, les éléments et les identifiants. Je peux donc faire TextArea.Login #Password et il se limitera en fait à cette chaîne d'éléments spécifique.
• screen.xml (Encore ou screen.android.xml et/ou screen.ios.xml ) - Ceci est la disposition de l'écran. Vous POUVEZ coder la mise en page en JS si vous le souhaitez (essentiellement comme flutter); mais le XML est tellement plus facile. Exemple:

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

La chose intéressante est qu'ActionBar est un composant spécifique à la page uniquement (c'est-à-dire qu'il est spécifique à la seule page); donc fondamentalement, ce qui se passe est la page de l'analyseur XML See; crée un nouvel élément de page ; puis crée un composant ActionBar qu'il exécute ensuite une fonction builderChild sur le composant Page ; le composant de page remplace le builderChild par défaut et regarde si l'enfant est une ActionBar ; Si c'est; puis il l'affecte en interne à la variable appropriée ; sinon le reste est passé par parent/super qui l'affecte ensuite automatiquement aux composants "enfant" ou "enfants". Le système de construction est incroyablement polyvalent dans la mesure où chaque composant peut utiliser la fonction builderchild du parent ou la remplacer pour faire des éléments supplémentaires comme le support <Label>Hi</Label> et l'affecter automatiquement à la valeur Text. Cela rend la mise en page incroyablement facile à mettre en place et à exécuter sans aucun code.

Parce que la plupart des éditeurs ont une bonne capacité d'édition XML, il est automatiquement colorisé et avec la définition xsd appropriée, intellij (& vscode) effectue une vérification automatique et une prise en charge limitée du contexte.

Maintenant, techniquement, tout est en fait un composant JavaScript ; vous pouvez donc faire tout cela manuellement (comme ce que fait Flutter); mais je trouve que la facilité de disposer un écran est triviale dans NativeScript. Et vous n'avez pas besoin du JS ou du CSS lorsque vous démarrez pour la première fois ; ensuite, vous pouvez ajouter le CSS (généralement, vous ne codez pas en dur dans la mise en page les propriétés basées sur CSS ; mais vous pouvez si vous le souhaitez).

La bonne chose à ce sujet; est-ce qu'il permet aux développeurs Web de se lancer directement avec très peu (le cas échéant) de recyclage. En réalité; en raison de son moteur de rendu flexible et de sa base JS - NativeScript prend en charge Angular et Vue - de sorte que vous pouvez réellement partager près de 95% de la base de code entre le Web et votre application mobile si vous utilisez Angular ou Vue. Puisqu'il utilise des composants natifs du système d'exploitation comme React Native (pas une vue Web comme Cordova); c'est vraiment un système multiplateforme décent (qui est à mon humble avis meilleur que React Native). Cependant, je peux voir où Flutter possède certaines forces qui en font un bon outil complémentaire pour certains développements mobiles, car il y a certaines applications pour lesquelles NativeScript est pire et certaines sont encore meilleures pour et sur la base des réponses à mon questions de Ian ; restera l'outil considérablement meilleur dans ces domaines.

Mieux vaut ouvrir ce fil verrouillé et y copier ces commentaires afin que nous ayons un historique des discussions complètes.

@JonathanSum , il ne s'agit pas de savoir si quelqu'un veut ou ne veut pas la fonctionnalité,
il s'agit de savoir si c'est l'endroit pour avoir une discussion animée à ce sujet. Je suppose que reddit ou similaire sont de meilleurs endroits.

@cbazza - Je ne suis pas en désaccord ; mais vous devez être très prudent à l'avenir pour ne pas insinuer des choses sur les gens. Cela ne fait qu'enflammer la discussion, peu importe à quel point vous pensez qu'ils sont idiots.

@zoechi - En fait, je pense que toute discussion sur une nouvelle fonctionnalité devrait être ici. L'historique doit être conservé de sorte que lorsque John Doe arrive dans un mois et recherche une fonctionnalité XYZ, il peut :+1 : une fonctionnalité existante et/ou y contribuer.

Je ne pense pas que ce fil soit vraiment verrouillé aussi longtemps à cause de mes commentaires. Si ce que j'ai dit était si mauvais, comment se fait-il que je puisse commenter tout le reste, comme par exemple ce fil ?

Le fil est verrouillé car l'équipe Flutter n'a aucun intérêt à faire cela et veut juste que les gens arrêtent d'en parler.

Gardons la discussion dans ce numéro axée sur les cas d'utilisation et les exemples d'une fonctionnalité de type JSX.

En fait, si NativeScript est si bon, pourquoi s'embêter avec Flutter au lieu d'essayer de faire en sorte que Flutter NativeScript ressemble.
Je viens d'une plate-forme basée sur XML (Xamarin Forms) et je pensais au début qu'il serait peut-être plus difficile de concevoir en code, mais ce n'est pas le cas.
Au contraire, il est très facile de décomposer votre conception en classes distinctes faciles à entretenir.

JSX conçoit en code !!!

@sethladd

Gardons la discussion dans ce numéro axée sur les cas d'utilisation et les exemples d'une fonctionnalité de type JSX.

OK, parlons de mon design DSX qui peut être consulté ici :
https://spark-heroku-dsx.herokuapp.com/index.html

Il fournit un mappage direct à la façon dont les widgets sont actuellement construits tout en fournissant une saveur de type JSX qui est très légère et familière aux développeurs de React. Manque-t-il quelque chose dans cette conception? Cette conception peut-elle générer tous les widgets possibles dans la nature ?

En règle générale, si vous pensez qu'un point d'exclamation n'est pas suffisant, vous devriez probablement vous éloigner du clavier et faire une pause.

Je suis un nouveau venu sur Flutter, n'ayant qu'une certaine expérience avec Android et Java, et je dois dire que je trouve ce que propose Flutter bien mieux que ce qui est proposé ici. J'ai tendance à trouver que XML est laid et peu maniable. C'est tellement plus beau d'avoir un personnage final singulier, plutôt qu'une mer decela rend mon code 5 fois plus long, une de mes haines lors de l'édition d'Android XML, et juste des balises de fermeture virtuelles que la grande majorité des IDE que les gens utilisent prennent en charge. Ceci est incroyablement utile lors de la conception de structures plus longues. À mon avis, l'imbrication XML soignée ne compense pas le reste des inconvénients, en particulier lorsque 'child:/children:' fait presque aussi bien son travail. Dart est incroyablement propre, et c'est une raison pour laquelle je l'aime tant. Je serais incroyablement déçu si cela devait être ruiné.

Je sais que React le fait comme ça, mais la dernière fois que j'ai vérifié, cet endroit dit Flutter. Ce n'est pas parce que React le fait que nous devons le faire - vous n'êtes pas les seuls à sauter le pas jusqu'ici ! Je suis tout à fait d'accord avec tous les points soulevés par @escamoteur . Je ne vois pas l'intérêt d'ajouter encore une autre langue que les gens doivent gérer lors de l'utilisation de Flutter. Nous utilisons déjà Dart pour en programmer la plupart, nous n'avons pas besoin de beaucoup d'autres choses à maîtriser ! La cohérence et la simplicité doivent être valorisées.

Quelques remarques à partir de vos extraits DSX vs Dart générés :

1. Subjectif : Je ne vois pas de grands gains de lisibilité. La verbosité est similaire - sinon un peu plus longue. Le plug-in Dart IDE fournit des balises de fermeture automatique, qui reflètent les balises de fermeture de balisage déclaratives. Si JSX est conçu dans le code, je ne vois pas comment les widgets dans Dart ne le sont pas.

2. Plusieurs propriétés à <vars>

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

Pouvoir définir des styles globaux mélangeant plusieurs propriétés est une bonne idée.
Cependant, quand je repense à ma modeste expérience de flottement, je ne vois pas où je les utiliserais.

Pour Text , il semble que la plupart de ce que j'ai besoin de réutiliser soit défini dans TextStyle , plutôt qu'un mélange de plusieurs propriétés. Vous pouvez peut-être trouver un autre exemple que Text où ce n'est pas le cas.

En regardant TextStyle , je trouve que l'actuel immutable + copy() est idéal pour réutiliser et composer dans 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,
  ),
),

Pour Container réutilisables partageant le même style, je pense que la création d'un widget sans état personnalisé fonctionne mieux qu'un <vars> défini en externe. La plupart du temps, je veux aussi un rembourrage, une encre, un écouteur de geste ou une ombre.

Pour tous ces cas, j'aurais besoin de composer Container avec un autre widget : Material , Padding , Center etc. Donc, si je dois créer un de toute façon, je ne vois pas grand intérêt à avoir un style externe <vars> qui définirait simplement les propriétés d'un seul widget dans ma hiérarchie de widgets réutilisables.

Je ne vois pas "tout est un widget" de Flutter bien fonctionner avec les styles "propriétés multiples".

1. Non mis en évidence dans vos exemples DSX actuels : comment coderiez-vous une interface avec des widgets dynamiques ? Signification : comment afficher ou non certains widgets en fonction d'une condition.

Lors de la conception dans Dart, il est facile et pratique d'ajouter ou non un widget particulier dans children .
Il est également très pratique d'envelopper dynamiquement un widget avec un autre. Cela rend la fonction build() fluide et facile à comprendre.

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

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

    children.add(wb);

@ SirComputer1 la proposition DSX est un ajout, la manière actuelle ne change pas donc si vous ne l'aimez pas, ne l'utilisez pas, continuez comme vous êtes aujourd'hui.

La chose <var> n'a été faite que pour la démo parce que je ne voulais pas analyser Dart en entier. La solution finale n'inclurait pas <var> mais utiliserait n'importe quelle variable de fléchette. De plus, le '@' n'a été utilisé que pour la démo afin de faciliter l'analyse. La solution finale ne l'inclurait pas.

N'oubliez pas que tout le reste du fichier est votre code Dart normal, vous pouvez donc l'utiliser pour tout le reste.

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

Arrêtons de comparer DSX avec la manière actuelle, l'un n'est pas en concurrence avec l'autre. Certaines personnes préféreront JSX et ce fil est pour elles. Ce que je veux savoir, c'est comment puis-je améliorer DSX pour gérer les choses pour lesquelles cela ne fonctionnera pas.

@escamoteur - Je n'ai pas tendance à utiliser un marteau comme tournevis. J'évalue les différentes technologies et j'utilise la bonne pour le bon cas d'utilisation. Cela ne signifie pas que leurs choses ne peuvent pas être modifiées pour le mieux sur chacune des plates-formes. :sourire:

Par exemple; intégration de plugins tiers. NativeScript est vraiment roi sur toutes les autres plateformes croisées. Rien d'autre ne se rapproche même à distance de NativeScript ; et l'intégration de tiers. J'ai un client qui demande à utiliser https://github.com/vipulasri/Timeline-View . Flutter pratiquement impossible ; NativeScript me donne quelques heures et cela fonctionnera comme n'importe quel autre contrôle NS, probablement même avec une liaison de données entièrement fonctionnelle. D'un autre côté, le flottement a de sérieux atouts là où les drapeaux NS ...

Utilisez l'outil approprié pour le travail. :sourire:

J'ai tendance à aimer la disposition d'écran basée sur XML ; mais je comprends pourquoi les gens ne le font pas. L'ajout de la capacité de construction basée sur XML ne signifie PAS l'élimination de la méthode existante ; c'est juste complémentaire ; choix. Pour ceux d'entre vous qui n'ont pas pris la peine de lire, je peux faire la même chaîne d'appels en NS que nous faisons en flottement ; mais utiliser xml est beaucoup moins typé et plus facile à lire. A chacun ses préférences...

J'ai en fait pensé à ajouter un moteur de rendu basé sur XML à Flutter en tant que POC ; mais je n'ai pas eu le temps libre. Je voulais juste contribuer à la conversation et dire que j'aimerais voir cela avancer; mais en fait , je ne m'attends pas à ce que l'équipe de base y travaille. Je pense que le format XML NS pourrait être réalisé en tant que projets communautaires où ceux d'entre nous qui s'en soucient (c'est-à-dire probablement moi : souriant :) seraient prêts à faire le travail dessus. Cependant, ma plus grande préoccupation @sethladd -- est si je passe beaucoup de temps sur un patch ; sera-t-il rejeté parce que quelqu'un de l'équipe de base s'oppose absolument à cette capacité. C'est ce que je voudrais préciser avant de passer du temps là-dessus...

@NathanaelA Perspective fantastique !!!!!!! et regardez, j'ai utilisé beaucoup de points d'exclamation ;-) Vous l'avez littéralement cloué sur la tête.

Oui, je peux faire DSX mais j'ai besoin d'un moyen de l'intégrer dans le système de construction Flutter actuel, j'ai donc besoin de l'engagement de l'équipe Flutter actuelle avant d'aller de l'avant. L'intégration IDE est pratiquement triviale sur VS Code mais pas tellement avec Intellij (sauf si Google a accès au support Intellij JSX).

@zoech , non ! Je pense que c'est un problème. Je me souviens avoir développé une application Android avec Java et XML natifs. Nous utilisons toujours XML pour la partie langage de l'interface utilisateur. Je pense que l'utilisation de Dart pour la logique et l'interface utilisateur est un peu étrange, et ce problème est assez évident. De plus, j'espère juste que Google va ajouter l'idée d'interface utilisateur de React dans le flottement. La partie UI de React est très puissante et concise.

@JonathanSum J'ai vu de nombreux commentaires à ce sujet.
Pour moi, cela ressemble toujours à quelque chose que les gens veulent parce qu'ils hésitent à changer leurs habitudes, pas parce que c'est un avantage pour la plateforme.

Certaines personnes aiment jsx, d'autres non. Pourquoi ne pas prendre en charge les deux façons d'implémenter l'interface utilisateur. Vous pouvez écrire une syntaxe de type jsx, et elle sera finalement compatible avec la syntaxe native flutter, pourquoi ne pas la prendre en charge ?

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

@zoechi

Pour moi, cela ressemble toujours à quelque chose que les gens veulent parce qu'ils hésitent à changer leurs habitudes

C'est une observation juste, mais ne serait-il pas préférable que Flutter soit un catalyseur et élimine autant de frictions que possible pour que les personnes (en dehors de Google) adoptent Flutter ? Ce comportement de contrôle ne gagne pas le cœur et l'esprit des développeurs.

@yuu2lee4

Certaines personnes aiment jsx, d'autres non. Pourquoi ne pas prendre en charge les deux façons d'implémenter l'interface utilisateur. Vous pouvez écrire une syntaxe de type jsx, et elle sera finalement compatible avec la syntaxe native flutter, pourquoi ne pas la prendre en charge ?

Excellente question. Étant donné que je fais tout le travail sur DSX, qui est comme JSX, et @Hixie m'a personnellement envoyé un e-mail enthousiasmé par les progrès, je ne vois pas pourquoi ne pas le soutenir, je ne vois pas pourquoi ne pas tendre la main et dire 'Que puis je faire pour t'aider? Qu'est-ce qui vous empêche de faire ça ?'

honnêtement, je commence à penser que cette rubrique va dans le même sens que la précédente... ce qui n'arrangerait rien...

@cbazza

@Hixie m'a personnellement envoyé un e-mail enthousiasmé par les progrès.

Alors pourquoi ne continuez-vous pas et les autres qui peuvent aider devraient également monter à bord et aider ? Si nous ne voulons pas que cela apparaisse comme l'autre fil... Je pense que nous devrions discuter de ce qui bloque, comment s'y prendre et comment le faire fonctionner et le diffuser... et Je pense aussi que l'équipe flutter et fléchettes a en quelque sorte commencé à travailler sur la réduction de la nature verbeuse de l'écriture de l'interface utilisateur ...
Peut-être que l'équipe ne pourra peut-être pas se joindre à nous maintenant, mais je pense que si sa cause louable, ce que je pense être bien pour moi, ça va, quelle que soit l'approche ... ils se rattraperont à un moment donné ... alors @cbazza continuons avec quoi vous faites et sortez-le ... comme ce que ce gars a fait http://mutisya.com/ au début même si je ne connais pas son état ... Je sais aussi que @NathanaelA peut aider car il a contribué des trucs et des outils vraiment incroyables pour Nativescript... Sortons-le pour donner plus d'options à plus de développeurs...

@MichaelSowah
La raison de ne pas investir plus de temps là-dessus est comme @NathanaelA a dit :

Cependant, ma plus grande préoccupation @sethladd -- est si je passe beaucoup de temps sur un patch ; sera-t-il rejeté parce que quelqu'un de l'équipe de base s'oppose absolument à cette capacité. C'est ce que je voudrais préciser avant de passer du temps là-dessus...

Bon, voici ce que j'ai :
(a) Un préprocesseur qui prend les fichiers *.dsx et sort les fichiers *.dart.

Voici ce dont j'ai besoin :
(1) Quelqu'un pour s'occuper de l'intégration du 'VS Code'. De mon enquête, il semble simple.
(2) Quelqu'un pour comprendre comment ajouter une capacité de pré-processeur dans le système de construction Flutter afin que le débogage fonctionne correctement. Je veux dire que le pas à pas de code serait sur les fichiers *.dsx via quelque chose comme sourcemap, etc.

Une fois les 2 éléments ci-dessus terminés, nous avons un système initial de bout en bout pour lancer le processus. N'importe quels preneurs?

Ainsi, comme vous pouvez le voir ci-dessus, (1) et (2) nécessitent des modifications dans le code Flutter que l'équipe Flutter peut rejeter, donc sans support/engagement, cette fonctionnalité est bloquée.

@cbazza génial, alors demandons à l'un des membres de l'équipe de flutter de nous faire savoir s'il est prêt à en prendre un et deux... alors qui pouvons-nous faire venir ici pour nous aider à progresser... ?

Pour (2) je pense que le mieux est de contacter l'équipe Dart, probablement via [email protected] ou leur outil de suivi des problèmes ? Je crois que l'un des objectifs de Dart 2 était de créer une infrastructure pour plus d'expérimentation avec le langage et de laisser la communauté créer des expériences comme DSX. Peut-être que @anders-sandholm @mit-mit ou @mraleph peuvent vous orienter dans la bonne direction.

@sethladd Merci pour la réponse rapide et pourriez-vous également copier les personnes ressources et éventuellement
équipe de fléchettes à ce fil aussi
@cbazza pourriez-vous intervenir pour lancer ce discours avec la personne-ressource indiquée.
en ce qui concerne l'intégration 'VS Code', je suis sûr qu'une fois que nous en aurons 2, peut-être que @DanTup pourrait être intéressé à aider

Juste quelques pensées

Bon, voici ce que j'ai :
(a) Un préprocesseur qui prend les fichiers *.dsx et sort les fichiers *.dart.

C'est probablement tout ce dont vous avez besoin pour démarrer, cela et un observateur de fichiers pour reconstruire les modifications - voir FileSystemEntity . Le défi est que cette grammaire .dx est un sur-ensemble de dartlang, vous devrez donc également analyser tout Dart. Ce sera délicat car contrairement à JavaScript, < et > sont utilisés à plus d'endroits. Je pense que l'analyseur Dart est déjà écrit dans Dart, et quelque part dans le référentiel sdk, mais je ne sais pas où

1. Pour l'intégration vscode et Intellij, ce n'est pas le système de construction flutter, c'est l' analyseur de fléchettes que vous voulez. Je pense que vous pouvez créer un plugin pour cela qui consommerait le dx, le transpilerait en fléchettes, puis mapperait les résultats sur le fichier d'origine. C'est ainsi que fonctionne le plugin d'analyseur angulaire pour fournir des choses comme la saisie semi-automatique aux fichiers html.

2. Vous voulez build runner , c'est un package beaucoup plus sophistiqué pour faire a .

@MichaelSowah
Excellent donc je suppose que vous prenez (1) et (2) pour que je puisse me concentrer sur le transpiler ?

@jonahwilliams
Je sais que l'analyse complète des fléchettes sera compliquée et pas vraiment nécessaire pour le moment car je peux toujours utiliser mes marqueurs pour la première version (https://spark-heroku-dsx.herokuapp.com/index.html)

Mais une chose est sûre, nous avons besoin que l'IDE et le débogueur fonctionnent correctement, sinon les gens n'utiliseront pas DSX car le compromis est trop important. Je veux dire « utilisez DSX et oubliez le débogage symbolique », ce n'est pas une offre très convaincante. C'est aussi la raison pour laquelle je veux qu'au moins un IDE soit pris en charge et VS Code serait aussi simple que bonjour (puisqu'il prend déjà en charge JSX dans leurs fichiers json de définition de syntaxes Typescript et Javascript)

re: IDE et débogueur, vraisemblablement en implémentant cette fonctionnalité dans l'infrastructure Dart 2 et le "frontal commun", vous devriez pouvoir activer les niveaux supérieurs de la pile pour qu'ils soient conscients de DSX. Je recommande de travailler avec l'équipe Dart et d'apprendre à explorer les différentes parties du Common Front End et de ses API.

@MichaelSowah J'ai mis en CC les gens de Dart dans https://github.com/flutter/flutter/issues/15922#issuecomment -376960770

@NathanaelA seriez-vous intéressé à participer aux (1) et (2) puisque maintenant nous avons clairement le soutien de l'équipe

Pas certain; en ce moment -- je suis submergé par plusieurs projets clients. Mais je serais prêt à examiner comment se connecter au pipeline de compilation et éventuellement créer des cartes source. (c'est-à-dire 2) Mais cela pourrait prendre quelques semaines avant que je puisse le faire.

@NathanaelA Il n'y a pas d'urgence ou quoi que ce soit donc vous êtes bon :-)

Si DSX est simplement Dart + Virtual closing tag alors il n'y a aucun avantage réel. L'un des avantages de Dart est que nous pouvons utiliser des fonctions et des variables pour créer une partie du widget et augmenter la lisibilité.

De plus, avec DSX et le pré-processeur, nous perdrons la capacité de rechargement à chaud en moins d'une seconde, n'est-ce pas @cbazza ?

Non, DSX est comme JSX et complètement différent de "Dart + balise de fermeture virtuelle", ce que vous pouvez faire aujourd'hui avec votre arborescence de widgets Dart uniquement et votre IDE.

DSX est décrit ici :
https://spark-heroku-dsx.herokuapp.com/index.html

DSX est Dart, donc tous les avantages de Dart que vous décrivez sont là. Les personnes familières avec JSX l'obtiendront tout de suite et l'adoreront.

Non, vous ne perdrez rien, rien ne change pour le fichier *.dart normal que vous créez, vous avez toujours un rechargement à chaud en moins d'une seconde.
Maintenant, si vous avez un fichier *.dsx, il sera d'abord transpilé en *.dart et ce processus est plus rapide que je ne peux clignoter !!! Il sera donc imperceptible pour les utilisateurs de DSX.

Avant que celui-ci ne soit à nouveau fermé, laissez-moi d'abord terminer ce que je veux dire.
L'interface utilisateur actuelle de la partie flutter est un problème, et je n'essaie pas de vendre l'idée de React.
Parce que la structure de l'interface utilisateur du flottement est très difficile à réaliser dans l'esprit avec ces parenthèses, nous avons vraiment besoin de quelque chose à améliorer. Je suggère fortement d'utiliser React Native ou le tout comme React. React rend non seulement les gens faciles à lire, mais il sépare également un énorme code d'interface utilisateur en différents groupes. En conséquence, je peux gérer plus rapidement un énorme code d'interface utilisateur complexe et le lire facilement. Par contre, avec beaucoup d'arbres avec des parenthèses uniquement dans le flottement, je ne sais pas comment les lire.

@JonathanSum avez-vous essayé la dernière version d'Android Studio (3.1) avec des étiquettes de fermeture ?

@ 14n Oui, je vois ces balises et commentaires de fermeture virtuels.

Une grande arborescence de widgets de type XML peut être aussi difficile à lire que n'importe quelle autre grande chose, que ce soit Dart, JSON, YAML ou JSX. Il ne semble pas que JSX lui-même résolve le problème de lisibilité.

Je n'ai eu aucun problème à lire des arborescences de widgets de taille raisonnable avec la syntaxe actuelle. De plus, Flutter favorise la composition, donc une fois qu'un widget devient trop gros, il est trivial de le diviser en plusieurs widgets plus petits.

Avis subjectif sur le format DSX proposé :

1. Visuellement, aucun avantage réel et encore une fois - la lecture d'un grand arbre XML peut être aussi pénible, il ne semble donc pas que cela résolve le problème. La promotion des pratiques Clean Code, par exemple, résoudrait en fait les problèmes de lisibilité, mais ces pratiques peuvent être appliquées à (presque) n'importe quelle syntaxe.
2. Nécessite l'apprentissage d'un autre DSL/syntaxe. J'aime vraiment-vraiment-vraiment le fait que je n'ai besoin de connaître qu'une seule syntaxe - Dart - pour tout faire - mise en page, styles, animations, logique. C'est tellement plus convivial pour les nouveaux arrivants et les développeurs expérimentés par rapport à ce qui est arrivé au Web avec html/js/jsx/ts/coffee/css/sass/scss. En fait, je considère même cela comme un avantage majeur de Flutter par rapport aux autres plates-formes.

Cela dit, je pense qu'il y a place à l'amélioration pour que Dart soit plus expressif lorsqu'il est utilisé pour décrire les interfaces utilisateur, même si je préférerais qu'il s'agisse davantage d'une extension de la syntaxe Dart existante plutôt que d'un tout nouveau DSL.

S'il vous plaît, arrêtez d'essayer de faire de Flutter une "nouvelle chose à la mode". C'est la nouveauté en soi, laissez-la explorer de nouveaux paradigmes.

@naiveaiguy Je pense que c'est chaud. Cela me rend très productif et me permet de partager du code avec des applications de navigateur et de serveur.
Je n'ai pas besoin de battage médiatique pour un été. J'ai besoin de quelque chose qui me permette de faire mon travail.
C'est exactement ce que font Flutter et Dart.

Mes réflexions sur ce miroir reflètent ce que @pulyaevskiy a dit dans https://github.com/flutter/flutter/issues/15922#issuecomment -377666972. Tous les exemples que j'ai vus qui ne sont pas lisibles peuvent généralement être rangés dans le code existant et je pense qu'il peut y avoir plus de modifications mineures qui pourraient être apportées à Dart (similaire à la suppression de new/const) qui pourraient l'améliorer davantage . Maintenir un tout autre ensemble de fichiers avec une toute autre syntaxe et un tout nouvel ensemble de code d'outillage semble être un coût élevé pour ce que je pense être un gain relativement faible (FWIW, je préfère également React sans JSX).

Je ne sais pas si c'est totalement applicable ici puisque le dsx proposé autorise aussi le code Dart normal, mais chaque fois que j'entends quelqu'un parler d'une nouvelle syntaxe, je me souviens de ce super article de Gilad A DOMain of Shadows . Ces choses sont toujours plus compliquées qu'on ne le pense. Ce n'est pas aussi simple que de simplement transpiler le code parce que les gens s'attendraient à des erreurs en temps réel, à l'achèvement du code, à des refactorisations, à des info-bulles, etc. - c'est une grosse entreprise.

Plutôt qu'un transpileur fonctionnel, je serais plus intéressé de voir une comparaison à trois voies entre un code considéré comme difficile à lire, à quoi il ressemblerait dans cette syntaxe proposée et à quoi il ressemblerait si vous pouviez apporter des modifications à la syntaxe Dart existante sans remplacer tous les crochets. Par exemple, quelque chose que j'aime dans React, c'est que les enfants sont passés comme varargs comme dernier paramètre - je pense que child et children ajoutent beaucoup de bruit dans Flutter - peut-être y a-t-il place à l'amélioration . Il y a également des discussions sur la question de savoir si la modification de la mise en forme ou la mise en surbrillance des noms de classe Widget pourrait aider. On dirait qu'un refactorisateur Extract Widget est sur le point de décomposer facilement les méthodes de construction volumineuses. Et bien sûr, IntelliJ a la vue Flutter Outline qui vous permet de voir le code dans un arbre et la sélection reste synchronisée avec la position du curseur dans l'éditeur (et j'espère vraiment obtenir quelque chose de similaire dans VS Code, bien qu'il soit bloqué par certaines fonctionnalités de VS Code comme celle-ci , alors n'hésitez pas à le 👍 !).

@pulyaevskiy
Je comprends ce que vous dites mais l'expérimentation c'est bien, c'est la voie de l'évolution. Même si mon expérimentation avec DSX échoue, j'espère que d'autres expérimenteront beaucoup d'autres choses et rassembleront les meilleures idées pour créer une technologie incroyable.

@sethladd
Merci pour les pistes.
J'adorerais avoir des nouvelles de @anders-sandholm @mit-mit ou @mraleph sur
comment travailler avec l'infrastructure Dart 2 et le "front end commun".
J'examinerai cela avec @NathanaelA.

@DanTup

Ces choses sont toujours plus compliquées qu'on ne le pense. Ce n'est pas aussi simple que de simplement transpiler le code parce que les gens s'attendraient à des erreurs en temps réel, à l'achèvement du code, à des refactorisations, à des info-bulles, etc. - c'est une grosse entreprise.

Oui vous avez raison. Mon commentaire «trivial, simple comme bonjour à mettre en œuvre» ne s'appliquait qu'à faire en sorte que l'éditeur reconnaisse la syntaxe .dsx. J'ai regardé Intellij et ils ont besoin d'un analyseur de langage complet pour cela (donc c'est complexe), alors que VS Code était beaucoup plus facile avec les fichiers de syntaxes et j'ai également remarqué que les fichiers de syntaxes Typescript/Javascript avaient déjà un support pour JSX (et DSX n'a ​​que modifications mineures de JSX).

Nous vous demanderons certainement de l'aide/des directives pour faire avancer notre expérimentation.

En résumé, j'ai :
(a) Un préprocesseur qui prend les fichiers *.dsx et sort les fichiers *.dart.
https://spark-heroku-dsx.herokuapp.com/index.html

J'ai besoin d'aide pour :
(1) Quelqu'un pour s'occuper de l'intégration du 'VS Code'.
(2) Quelqu'un pour comprendre comment ajouter une capacité de pré-processeur dans le système de construction Flutter afin que le débogage fonctionne correctement. Je veux dire que le pas à pas de code serait sur les fichiers *.dsx via quelque chose comme sourcemap, etc.

@NathanaelA aidera avec (2).

Je suis donc toujours à la recherche de personnes pour m'aider (1)
N'importe quels preneurs? @birkir @yuriy-manifold @tehfailsafe @alexkrolick @sanketsahusoft

@DanTup - Je ne suis pas un pro de JSX, mais je peux parler du format XML NativeScript. Je peux faire:

Toute propriété prise en charge par la classe StackLayout peut être ajoutée au XML. C'est donc une relation un à un; qui élimine une tonne de cruft supplémentaire : Alors regardons la démo Flutter :
https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/gallery/home.dart#L39 -L63

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

Je trouve cela plus facile à lire et à comprendre si je le convertis correctement. :sourire:

@NathanaelA Que se passe-t-il si vous devez faire quelque chose de plus dynamique, comme appeler map ? Voici du code de ce même fichier :

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

À quoi ressemblerait children: _kBackgroundLayers.map(...) dans cette syntaxe ?

JSX/DSX spécifie uniquement la transformation de balise comme :

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

Dans:

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

En dehors:

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

et vous pouvez utiliser {} pour mettre n'importe quel code Dart valide, comme l'évaluation de variables et les fonctions anonymes, etc. Le {} peut être placé à 3 endroits. L'exemple ci-dessous montre {} utilisé à 2 endroits (attributs de balise et en tant qu'enfants), le 3ème étant avec l'opérateur de propagation.

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

Mettez le code ci-dessus dans un fichier Javascript et affichez-le avec VS Code/Intellij. Notez le +/- (côté gauche de la ligne) que vous pouvez utiliser pour ouvrir et réduire les nœuds XML afin de réduire/agrandir l'arborescence.

Pourquoi ne pouvons-nous pas simplement admettre le problème et adopter la méthode React Native ? Allons-nous le faire ou pas ?

@JonathanSum désolé d'être dirigé ici, mais qui pensez-vous être? Il n'y a pas de problème général juste quelque chose que vous n'aimez pas.
Avez-vous même écrit une seule application avec Flutter ?
Les exemples ci-dessus mélangeant Dart avec XML semblent bien pires que juste Dart. Rien à gagner ici.
Je viens de Xamarin Forms qui utilise xaml et j'ai vraiment aimé ça. Mais au lieu de me plaindre du fait que Flutter ne supporte pas Xaml, j'ai plongé dedans et j'ai commencé à m'adapter et à apprendre.
Faites-y face si vous voulez travailler comme dans React, puis utilisez Reactive au lieu d'ennuyer tout le monde ici.

Voici le même bloc de code que ci-dessus, mais en Dart pur et refactorisé pour éviter l'imbrication profonde.
Vous voulez savoir quelles parties de l'extrait ci-dessous sont difficiles à lire et/ou à comprendre ?

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

En fait, personnellement, je le ferais ressembler à quelque chose comme ça:

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

Encore une fois, il semble que nous mélangeons ici deux problèmes différents :

1. Aversion pour la syntaxe Dart et besoin d'une syntaxe de type XML/JSX
2. Lisibilité du code Flutter.

Y a-t-il des gens ici qui pensent que la mise en œuvre de JSX résoudra la lisibilité ? Il serait toujours possible de créer des arborescences profondément imbriquées dans le code et les développeurs auraient toujours besoin de suivre les mêmes étapes que je viens d'effectuer avec la version Dart pour rendre les choses lisibles.

Mais ce que cela ajouterait certainement, c'est une étape supplémentaire de construction/transpilation avec les cartes source et co, et beaucoup de travail pour prendre en charge cette infrastructure dans les IDE et le SDK Dart (analyseur, débogueur, etc.).

@JonathanSum @escamoteur Nous ne parlons pas de manière agressive sur ce projet. Veuillez rester collégial en collaboration. Merci. La discussion récente a été amicale et productive, alors merci à tous ceux qui ont participé à cette discussion !

Dans l'ensemble, il me semble que l'ajout de DSX fragmenterait l'écosystème Flutter à ses débuts, avec beaucoup de travail en cours pour essayer de garder les deux syntaxes complètes, n'aiderait pas réellement la lisibilité de manière significative dans la plupart des cas, et attirerait le genre de développeurs qui sont attirés par les projets uniquement parce qu'ils ont une syntaxe et/ou un paradigme similaire à une nouveauté.

@Hixie désolé d'avoir perdu mon sang-froid mais je pense que Flutter est sur la bonne voie et que les développeurs de Flutter ont assez à faire sans demandes comme celle-ci

@escmoteur - Je pense que c'est pour ça que j'ai spécifiquement dit effort "communautaire". Je ne pense pas que cela doive impliquer l'équipe de base de Flutter au-delà de sa volonté d'accepter des correctifs... Ce que Seth semble avoir dit que nous sommes en mesure de continuer. Si vous n'êtes pas intéressé par cette fonctionnalité ; alors ne l'utilisez pas... :grinning:

@escamoteur , je suis désolé pour la manière dont j'ai dit.
J'ai construit des applications flottantes à partir de tutoriels. Tout ce que je ressens à propos du flottement, c'est que tout est un objet plutôt qu'un widget. C'est comme un énorme morceau de codes de programmation orientés objet compliqués collés ensemble de manière désordonnée.

Je pense que la chose la plus importante est de créer un cadre facile à lire et à gérer, et cela ne devrait pas être compliqué comme l'enfer. Plus important encore, je pense que la façon dont React-Native construit suit ce que les humains construisent naturellement. D'autre part, le flutter doit connecter le widget avec état au sans état et ... De plus, la plupart des frameworks d'interface utilisateur que nous utilisons ces dernières années se concentrent sur cette manière de réagir en tant que norme, et je pense que le flutter devrait se concentrer davantage sur cela. plutôt que le rechargement à chaud (lorsque j'essaie d'ajouter de nouvelles classes, la console me dit de tout redémarrer au lieu de faire un rechargement à chaud). Je pense vraiment que c'est un problème, pas un commentaire ou une demande.
naiveaiguy a dit :

S'il vous plaît, arrêtez d'essayer de faire de Flutter une "nouvelle chose à la mode". C'est la nouveauté en soi, laissez-la explorer de nouveaux paradigmes.

Vous pouvez aller les consulter.
https://facebook.github.io/react-native/
Penser en Réagir :
https://reactjs.org/docs/design-principles.html
Battement:
https://flutter.io/tutorials/animation/

Regardez le React-Native, il place même la gestion de l'état au-dessus et les parties de l'interface utilisateur en dessous. C'est un art et un comportement naturel de l'être humain. C'est pourquoi la courbe d'apprentissage et le temps de gestion sont faibles. Ainsi, veuillez ne pas comparer XML ou même Xamarin au React Native. De plus, le Futter est juste comme un chaos et un désordre. L'état sans état se connecte à l'état sans état et l'état de création connecte tout dans l'état sans état. Avec React-Native, vous dessinez une belle image avec un crayon. Avec un flutter, c'est comme laisser tomber de l'eau sur un papier et séparer l'eau en différentes parties. Mais je pense que nous en sommes encore aux premiers jours du flutter. React-Native a sa propre philosophie et ses propres objectifs, et le flottement n'est qu'un projet sérieux, ou tout le monde n'est pas d'accord avec moi.

@JonathanSum

J'ai construit des applications flottantes à partir de tutoriels. Tout ce que je ressens à propos du flottement, c'est que tout est un objet plutôt qu'un widget. C'est comme un énorme morceau de codes de programmation orientés objet compliqués collés ensemble de manière désordonnée.

Vous n'avez pas fourni de raison pour laquelle votre sentiment subjectif à ce sujet justifierait l'énorme quantité de fragmentation qu'il entraînerait inévitablement. Quand entre ces deux approches, personne n'est clairement meilleur objectivement que l'autre, je ne pense pas que cela en vaille la peine, et certainement pas au stade où Flutter se trouve actuellement en tant qu'écosystème.

Je pense que la chose la plus importante est de créer un cadre facile à lire et à gérer, et cela ne devrait pas être compliqué comme l'enfer.

C'est une tautologie. Évidemment, tout le monde veut cela, mais les gens ont différentes façons d'aborder le problème. Le paradigme de Flutter en fait partie.

Plus important encore, je pense que la façon dont React-Native construit suit ce que les humains construisent naturellement.

Je ne pense pas que quelque chose d'aussi mineur que la syntaxe de construction de l'interface utilisateur influence la facilité d'utilisation d'un framework dans l'ensemble.

D'autre part, le flutter doit connecter le widget avec état au sans état et ...

Il semble que vous soyez fondamentalement en désaccord avec la façon dont Flutter aborde les applications. Pourquoi l'utilisez-vous ? De plus, ce n'est pas vraiment un argument valable. Vous n'exprimez pas quelque chose que vous pensez être faux, vous dites simplement "Je pense que les connexions entre les widgets sans état et avec état sont fausses et compliquées d'une manière vague que je ne vais pas expliquer."

De plus, la plupart des frameworks d'interface utilisateur que nous utilisons ces dernières années se concentrent sur cette méthode React en standard,

Arguments ad populum.

et je pense que le flutter devrait se concentrer davantage sur cela plutôt que sur le rechargement à chaud (lorsque j'essaie d'ajouter de nouvelles classes, la console me dit de tout redémarrer au lieu de faire un rechargement à chaud)

Oui, car le rechargement à chaud n'est pas une fonctionnalité très facile à réaliser de la manière dont Flutter l'a fait. Je dirais que le cycle de développement que Flutter a réussi à atteindre, même dans 30 à 40% des changements de code, est vraiment impressionnant et ne serait ralenti que par des couches de transpilation.

Cependant, le plus futant est juste comme le chaos et le désordre.

Ici, vous avez clairement indiqué que vous n'aimez tout simplement pas l'approche de Flutter. Ne l'utilisez pas alors. Et si vous pensez que d'une manière ou d'une autre, comme par magie, la modification de la syntaxe de l'interface utilisateur fera de Flutter non "chaos et désordre", alors vous devrez fournir des preuves claires que cela fonctionne dans les mêmes types de paramètres et de contraintes avec lesquels Flutter travaille.

C'est pourquoi la courbe d'apprentissage et le temps de gestion sont faibles. Veuillez ne pas comparer XML ou même Xamarin au React Native.

Assez juste - utilisez React Native alors. Les développeurs y font un excellent travail avec leur paradigme.

L'apatride se connecte à l'état avec état et à l'état de création dans l'apatride

Quoi? Non. C'est tout simplement faux - quel est votre point ici ?

Avec React-Native, vous dessinez une image avec un crayon. Avec un flottement, c'est comme si de l'eau tombait sur un papier et séparait l'eau en différentes parties.

Franchement, cette analogie n'a que peu de sens pour moi. Je pourrais facilement énoncer l'opinion inverse et nous serions de retour là où nous avons commencé ici.

Vous agissez comme si cela allait de soi ("avouons-le") et nous sommes juste prétentieux et/ou insupportables ici pour dire que l'équipe Flutter ne devrait pas avoir à gérer cela. Ce n'est pas une bonne attitude à adopter si vous voulez que les autres vous prennent au sérieux.

Point supplémentaire : veuillez ne pas prétendre que c'est quelque chose que les développeurs tiers peuvent faire sans aucune implication ou travail de la part de l'équipe principale de Flutter. L'équipe Flutter devra faire beaucoup de travail supplémentaire avec les IDE et les plugins d'éditeur, et l'évangélisation, et traiter les problèmes de GitHub, si une telle fonctionnalité doit être implémentée de manière satisfaisante en tant que partie harmonieuse de Flutter.

@naiveaiguy
D'accord, je pense que tu as raison. Je suis juste une personne au hasard comparant tout le monde ici et une personne qui aime React. Flutter a sa propre voie, et React aussi. Je suis désolé pour mon attitude et je n'ai pas été gentil.

@JonathanSum Je pense que vous avez juste besoin de plus de temps pour vraiment comprendre comment les applications Flutter sont construites. Pour être juste, il n'y a pas beaucoup de documentation sur l'architecture, comment utiliser correctement les widgets hérités et comment connecter votre modèle de vue aux widgets.

Ce que j'aimerais savoir, c'est pourquoi vous vous intéressez à Flutter ? Pour moi, React est interdit à cause de JS

Tant de commentaires, si peu de temps, peut-être devrais-je me concentrer...

@escamoteur qu'est-ce que tu entends exactement par :

Pour moi, React est interdit à cause de JS

ES6/7 ou Typescript sont si proches de Dart/Kotlin/Swift que je danserai volontiers avec n'importe laquelle de ces dames :)

Ce qui m'attire chez Flutter, c'est le support graphique et d'animation. Graphiques Direct Skia Vector construits sur OpenGL pour une UX ultra rapide à 60 ips pour implémenter facilement des choses comme ce que vous voyez sur :
https://uimovement.com/
Je suis dans l'UX personnalisé et Flutter le permet. J'ai implémenté des trucs UX pendant des décennies et j'aime vraiment pouvoir construire cela en utilisant des techniques déclaratives/réactives, et Flutter prend en charge cela.

@pulyaevskiy

Encore une fois, il semble que nous mélangeons ici deux problèmes différents :

• Aversion pour la syntaxe Dart et besoin d'une syntaxe de type XML/JSX
• Lisibilité du code Flutter.

Correct, ce ticket ici (et le précédent) veut juste des capacités de type JSX. Il existe d'autres tickets pour des améliorations du langage Dart afin de réduire la verbosité du code de construction actuel de l'interface utilisateur.

Y a-t-il des gens ici qui pensent que la mise en œuvre de JSX résoudra la lisibilité ?

C'est peut-être pour eux, chacun le sien.

Oui, l'exemple que vous avez fourni rend l'arbre plus petit, mais en le divisant en morceaux et en déplaçant des morceaux ailleurs, il est également encore plus difficile de voir toute la structure dans le code. Je préférerais conserver la structure complète au même endroit et retirer de l'arborescence certaines propriétés associées (paramètres nommés) et utiliser l'opérateur de propagation de DSX pour les intégrer. Juste ma préférence.

Mais ce que cela ajouterait certainement, c'est une étape supplémentaire de construction/transpilation avec les cartes source et co, et beaucoup de travail pour prendre en charge cette infrastructure dans les IDE et le SDK Dart (analyseur, débogueur, etc.).

Nous gérons cela et @sethladd a déclaré que 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

Je dirais que le cycle de développement que Flutter a réussi à atteindre, même dans 30 à 40% des changements de code, est vraiment impressionnant et ne serait ralenti que par des couches de transpilation.

Oui, j'apprécie vraiment le chargement à chaud même si cela ne fonctionne pas tout le temps. Je vais certainement accepter cela, mais votre commentaire sur le ralentissement de la transpilation est sans fondement. Si vous n'utilisez pas DSX, cela n'ajoutera rien à votre temps de compilation. Si vous utilisez DSX, le transpileur est si rapide que vous ne le remarquerez même pas.

Point supplémentaire : veuillez ne pas prétendre que c'est quelque chose que les développeurs tiers peuvent faire sans aucune implication ou travail de la part de l'équipe principale de Flutter. L'équipe Flutter devra faire beaucoup de travail supplémentaire avec les IDE et les plugins d'éditeur, et l'évangélisation, et traiter les problèmes de GitHub, si une telle fonctionnalité doit être implémentée de manière satisfaisante en tant que partie harmonieuse de Flutter.

Pas vraiment. Nous le faisons et demandons seulement de ne pas être bloqués. Nous demandons des conseils pour nous orienter dans la bonne direction. Je ne ferai pas tout ça toute seule, alors maintenant nous sommes 2 (merci @NathanaelA) et nous recherchons plus de personnes (au moins 1 de plus) si elles veulent aider.

Salutations à tous ! Tout d'abord, je voudrais souligner qu'il n'est pas très logique de poursuivre les échanges sur cette question - elle deviendra importante et difficile à suivre en raison de la structure linéaire. Vos arguments seront perdus et ressassés encore et encore. Réduisons cela à des nombres purs :

• Si vous êtes POUR cette fonctionnalité, approuvez le tout premier commentaire sur ce problème.
• Si vous êtes CONTRE cette fonctionnalité - rejetez le tout premier commentaire sur ce problème.

Ensuite, je voudrais clarifier la déclaration de @sethladd , elle devrait se lire _"l'un des objectifs de Dart 2 était de créer une infrastructure pour plus d'expérimentation avec le langage pour l'équipe Dart "_.

Même dans Dart 2, nous ne fournissons aucune API vous permettant de modifier facilement la syntaxe du langage Dart, sans reconstruire le SDK Dart (ou les artefacts du moteur Flutter). Ce que Dart 2 fournit est une infrastructure _common front-end_ (CFE) (située dans pkg/front_end dans les sources du SDK Dart) - qui est un analyseur pour le langage Dart écrit en Dart. Pour les changements de langage de sucre purement syntaxiques comme DSX, vous devriez pouvoir simplement éditer le code CFE, créer le SDK Dart (ou le moteur Flutter) et avoir tous les outils (à l'exception du code de coloration syntaxique intégré aux plugins IDE respectifs) pour récupérer votre nouvelle extension de syntaxe. Notez qu'actuellement, seuls VM et dart2js utilisent réellement CFE, l'analyseur est programmé pour passer ensuite. Comme vous pouvez le constater, il existe certaines barrières à l'entrée ici.

Une chose importante à souligner ici est que parce qu'il n'y a pas d'API pour étendre la syntaxe Dart, vous devrez travailler avec l'équipe de langage Dart pour que le langage soit étendu. Actuellement, il n'y a pas de processus formalisé pour cela, mais pour une fonctionnalité comme DSX, il faudrait beaucoup de preuves et de motivation pour qu'elle soit incluse dans Dart. (/fyi @leafpetersen @lrhn - corrigez-moi si je me trompe)

Voici mes recommandations aux partisans d'une solution similaire à DSX :

• Tout d'abord, vous devez en fait mettre votre proposition par écrit et déplacer la discussion vers un endroit qui facilite la discussion non linéaire. Lorsque vous proposez des changements de langage, vous devez avoir une description _élaborée_ de ce que vous essayez de résoudre et de la manière dont il est résolu à l'aide des extensions de syntaxe que vous proposez. Sinon, il est impossible d'évaluer les coûts et les avantages du changement proposé. Ensuite, vous avez besoin d'un moyen d'avoir des discussions non linéaires sur les différentes parties de la proposition, par exemple

  • si vous placez votre proposition dans Google Doc, les utilisateurs peuvent utiliser des commentaires intégrés pour discuter des différents composants de votre proposition ;
  • vous pouvez également créer un référentiel GitHub avec une description de démarque de votre proposition, et utiliser le problème GitHub et les PR pour affiner et discuter de votre proposition.

  Notez que je ne dis pas que vous devez proposer une _spécification formelle_ pour votre changement qui serait comparable à la spécification du langage Dart au niveau du raffinement. Au lieu de cela, vous devez disposer d'exemples détaillés du fonctionnement du changement proposé et des avantages qu'il procure.



• Ensuite, si vous le pouvez, vous devriez essayer d'avoir une implémentation. La barrière est élevée ici même avec l'infrastructure CFE - mais beaucoup plus basse qu'elle ne l'était auparavant.

@mraleph Je pense que les arguments concernant l'intégration dans Dart concernaient davantage les crochets pour invoquer la génération de code ou similaire, pas pour changer la langue.
Je n'ai aucune idée que quelque chose comme ça soit nécessaire.
Je pense que cela pourrait principalement être implémenté comme Angular avec son plugin Analyzer, juste DSX au lieu de HTML

@mraleph

Merci beaucoup pour les éclaircissements.
Nous ne voulons pas vraiment modifier le langage Dart, nous avons besoin d'une capacité de pré-traitement afin de transformer notre DSX expérimental en Dart.
Au fait, vous pouvez l'essayer en ligne sur :
https://spark-heroku-dsx.herokuapp.com/index.html

Le fait est que lorsque Dart est sorti pour la première fois, il a pu se transpiler en Javascript et en utilisant des cartes source, il a pu simplement se connecter à l'écosystème Javascript (plusieurs autres langages ont fait de même : Coffeescript, Typescript, etc.). Ce que nous recherchons est quelque chose de similaire pour Dart/Flutter. Nous recherchons une capacité de prétraitement générique qui permettrait à tout autre langage de transpilation d'être construit au-dessus de Dart/Flutter.

En ce qui concerne le vote, le ticket précédent a quelques numéros:
https://github.com/flutter/flutter/issues/11609

@cbazza

Nous ne voulons pas vraiment modifier le langage Dart, nous avons besoin d'une capacité de pré-traitement afin de transformer notre DSX expérimental en Dart.

Je parlais du point de vue que les fichiers *.dsx sont en fait des fichiers Dart dans lesquels vous pouvez utiliser une syntaxe supplémentaire. Et comme je l'ai dit, il n'y a actuellement aucune API ou point d'extension qui facilite la création de telles extensions de syntaxe d'une manière qui permette à ces extensions de syntaxe d'interagir de manière transparente avec tous les outils de l'écosystème Dart. De plus, je ne pense pas qu'il y ait de plans immédiats pour concevoir et fournir de telles API ou points d'extension - donc votre meilleur pari à ce jour est de bifurquer Dart SDK et d'intégrer le support DSX dans CFE.

Je recommande également de penser aux cas d'angle - plutôt que de penser aux cas simples. Par exemple, imaginez que vous modifiez votre fichier DSX. Dans ce cas, vous souhaiterez probablement voir l'achèvement en temps réel sur le code à moitié terminé, par exemple les noms de constructeur et les noms d'attribut. Comment cela fonctionnerait-il avec le mappage de source ? Des choses comme ça constituent l'expérience du développeur.

@mraleph Merci encore une fois.

Nous visons certainement à offrir une excellente expérience utilisateur aux utilisateurs de DSX, c'est certain.

Certaines personnes aiment la syntaxe de type XML, certaines personnes la détestent. Peut-être que l'ajout d'une syntaxe de type jsx est trop exagéré. Ma principale préoccupation à propos de Flutter est la lisibilité. principalement sur les parenthèses imbriquées profondes, child , children , les bruits de point-virgule, etc.)
Republier un exemple de code[1]ici,

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

Version Dart 2 avec new et point-virgule en option (code de @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, la version kotlin est propre et a meilleure apparence. La version Dart 2 est très proche et peut encore être améliorée (si Dart prend en charge les méthodes d'extension ?). Je pense donc que l'amélioration de la syntaxe Dart pour réduire la verbosité est la bonne direction.

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

Un autre angle, j'aime la capacité de composition de JSX.

Travailler avec les composants (widgets) est très simple et accessible, les déplacer de haut en bas dans l'arborescence d'un éditeur n'est qu'une question de raccourci clavier (Alt+HAUT / Alt+BAS). Cela est particulièrement vrai lorsque vous déplacez des éléments dans et hors d'un conteneur, d'une ligne, d'une colonne, etc.

Mais ce n'est pas quelque chose que DSX résoudrait tout seul. Les widgets eux-mêmes devraient être
plus restreint avec la dénomination de la propriété pour que cela fonctionne. Dans React, il s'agit d'une propriété appelée children et c'est un principal principal dans JSX. Flutter permet une flexibilité dans la dénomination des enfants (enfants, enfants, corps, etc.).

Voici une excellente discussion sur les avantages et les inconvénients : https://github.com/jsforum/jsforum/issues/1

Dard	DSX

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

Je dois admettre que l'échantillon DSX semble attrayant. Mais je crains que dès que vous le mélangez avec Dart Code, par exemple lorsque vous utilisez un widget de construction, il aura l'air vraiment moche.

@birkir DSX devrait pouvoir prendre en charge quelque chose comme le modèle d' accessoires de rendu pour les emplacements enfants multiples/non children . S'il peut prendre des fonctions ou des références de classe comme accessoires (ce qu'il ferait probablement automatiquement), cela fonctionnerait immédiatement.

En ce qui concerne l'implémentation des outils, les outils Javascript prennent en charge depuis longtemps la syntaxe et l'extension de langage non standard (Flowtype/Typescript/Babel), de sorte que de nombreux outils pour JSX exploitent les transpilers existants. Afaik Dart n'a pas connu ce niveau de fragmentation, donc l'outillage n'existe pas encore. Mais c'est le bon moment pour commencer à le construire 😄

À mon humble avis, la syntaxe de type json est bien meilleure que la syntaxe de type ~ xml ~ !

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

@jaychang0917
Je ne pense pas que JSX puisse être comparé à XML. Je pense que JSX et XML sont deux choses différentes en tant qu'avions à hélices supersoniques.

Avec JSX, vous pouvez faire des choses comme suit :

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

ou

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

Avec JSX, nous pouvons même tout casser morceau par morceau comme ci-dessus, ou vous pouvez regrouper une grande partie de l'interface utilisateur dans une balise <> pour mettre cette grande partie de l'interface utilisateur où vous voulez.

C'est pourquoi React remplace HTML et XML et adopte JSX pour créer une application iPhone ou une application Web, ou les gens disent que JSX est juste une version plus cool de HTML.

• Je n'aime pas à la fois XML et HTML et j'adore JSX.

• Je pense que la chose la plus importante n'est pas la performance de l'iPhone par rapport au bureau.

• La chose la plus importante est la facilité d'utilisation de l'iPhone par rapport au bureau.

Par exemple:

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

ou écrire

< AwkwardScrollingImage/>

écrire-une-fois-fonctionne-partout

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 utilise un langage de programmation pour créer une interface utilisateur. ~

Référence:

Battement:
https://flutter.io/tutorials/layout/
React Native qui construit Android, Iphone et même le bureau :
https://facebook.github.io/react-native/

@birkir
Ohh ça a l'air trop bon !!! juste de la viande et pas d'os :)
Imaginez que vous utilisez https://builderx.io/ avec (regardez la deuxième image animée - la construction d'interface utilisateur à 2 voies comme Flex l'utilise :)

@escamoteur
avec les constructeurs en ligne, cela aurait l'air aussi désordonné qu'avec la méthode actuelle ; des échantillons ont été fournis ci-dessus :
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

Quoi qu'il en soit, je pense que la méthode actuelle est claire et cohérente. Mélanger un code de fléchettes et une balise < dans un fichier de fléchettes me donne l'impression que le code est maladroit et peu clair. Du point de vue d'un développeur Android, cela ressemble à écrire du code java/kotlin dans un fichier xml de mise en page :)

JUSTE MES DEUX CENT

@JonathanSum euh...

Alors, quels sont les avantages de l'utilisation de JSX que le flutter actuel ne peut pas faire ? Je ne vois aucun argument que vous avez qualifié de fort.

JSX n'est pas comme XML. JSX est plus simple et puissant que ce XML.

Au fait, JSX est de type xml , si l'équipe Facebook ne me ment pas :)

@jaychang0917
JSX n'est pas XML car JSX est plus simple et plus puissant que ce XML (je dis que JSX n'est pas comme XML)

Si vous dites qu'il n'y a pas d'arguments solides, laissez-moi vous poser une question.
Permettez-moi de terminer mon discours ici. Si les gens veulent JSX ou DSX, il y en aura un similaire à l'avenir.

• Référence:
  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.

Les vraies balises de fermeture de XML me manquent cependant :)
Idée : Balises de fermeture générées automatiquement

Kotlin aurait également résolu ce problème. Regardez à quel point Kotlin-react et Anko sont géniaux

Kotlin-react n'est pas si génial, KSX aurait été mieux :)

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

Les tags n'ont tout simplement pas leur place ici :)

Étant sur le camp JSX/DSX/KSX, je crois certainement que les balises appartiennent au code :)

@saied89
Voulez-vous utiliser une balise pour imbriquer un élément dans un autre élément, tout comme HTML ? Ou voulez-vous taper un mot "enfants", "enfant" ou [ ] ? De plus, JSX fournit des éléments tels que la réutilisation de centaines de codes d'interface utilisateur en ne tapant qu'une seule balise.

Peut-être un autre aspect est le formatage par défaut que fait dart format . À mon humble avis, il est difficile de lire surtout avec l'enfant principal : /children.

Je préférerais vraiment une mise en forme qui met l'accent sur la structure arborescente quelque chose comme ça:

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

Ce n'est peut-être pas la solution idéale, mais cela devrait montrer la direction.
@sethladd a -t-il une chance de faire quelque chose dans ce sens ?

Tout d'abord, je suis content que cela ne devienne pas aussi chaud que son problème frère l'était : smile:.

Si on me demandait de choisir l'une des 2 syntaxes, je pencherais pour le côté Dart. Cela repose sur plusieurs faits :

• Je préfère basculer entre le moins de contextes possible. Qu'on le veuille ou non, sauter entre les syntaxes est une façon de le faire. Cela peut être aidé avec un support d'outillage, mais cela mène au point ci-dessous.
• Je préfère que l'équipe de développement consacre du temps à d'autres problèmes qui nous empêchent de coder certaines fonctionnalités et/ou empêchent les gens de se lancer dans Flutter. Je pense que ne pas avoir de syntaxe de type JSX ne devrait pas être la raison pour laquelle une entreprise/développeur/quoi que ce soit rejette Flutter.
• Nous bénéficierions de chaque mise à jour de Dart. Cela est particulièrement vrai pour Dart puisque Flutter est l'un de ses principaux clients et qu'il s'agit d'un framework d'interface utilisateur. Voir les changements new/const par exemple.
• J'accorde une grande importance à la sécurité de type. Ne disant pas qu'une syntaxe de type JSX ne peut pas être de type sûr, je ne crois pas que l'effort pour l'accomplir vaut ses revenus.

Cela mis à part, je privilégie en fait une syntaxe de type Kotlin. Surtout si ladite syntaxe apporte certaines fonctionnalités de Kotlin à Dart : innocent :.

@emalamela ,

Voici le truc, il n'y a pas de changement de contexte comme vous l'appelez, il suffit de demander à n'importe quel développeur React chevronné. De plus, cette séparation de syntaxe est en fait une fonctionnalité intéressante car lorsque vous regardez le code, vous pouvez facilement voir ce qui est déclaratif et ce qui est impératif.

Je pense que ne pas avoir de syntaxe de type JSX ne devrait pas être la raison pour laquelle une entreprise/développeur/quoi que ce soit rejette Flutter.

Mais malheureusement, ce sera pour beaucoup de développeurs React.

Nous bénéficierions de chaque mise à jour de Dart.

Je ne vois pas comment DSX ne bénéficie pas également des mises à jour de Dart puisqu'il s'agit d'un sur-ensemble de Dart.

J'accorde une grande importance à la sécurité de type. Ne disant pas qu'une syntaxe de type JSX ne peut pas être de type sûr, je ne crois pas que l'effort pour l'accomplir vaut ses revenus.

L'effort pour assurer la sécurité du type dans DSX est nul car DSX n'est qu'une minuscule couche de sucre syntatique au-dessus de Dart, il utilise donc le système de type Dart tout comme il utilise les instructions de contrôle Dart, etc.
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

Merci pour votre contribution @cbazza !

Voici le truc, il n'y a pas de changement de contexte comme vous l'appelez, il suffit de demander à n'importe quel développeur React chevronné.

Je ne suis pas un développeur chevronné de React, donc pour moi, c'est un changement de contexte. Tout comme dans Android, vous devez passer de Java/Kotlin à XML, bien que le saut soit plus important. Un langage, le même outillage, moins de frais généraux.

De plus, cette séparation de syntaxe est en fait une fonctionnalité intéressante car lorsque vous regardez le code, vous pouvez facilement voir ce qui est déclaratif et ce qui est impératif.

La façon dont il est maintenant est assez déclarative à mon avis.

Je ne vois pas comment DSX ne bénéficie pas également des mises à jour de Dart puisqu'il s'agit d'un sur-ensemble de Dart.
L'effort pour assurer la sécurité du type dans DSX est nul car DSX n'est qu'une minuscule couche de sucre syntatique au-dessus de Dart, il utilise donc le système de type Dart tout comme il utilise les instructions de contrôle Dart, etc.

Points justes. Mais DSX est encore quelque chose à maintenir et à améliorer, cela implique toujours des efforts que j'aimerais voir se concentrer sur d'autres aspects plus critiques/manquants de l'écosystème.

Un autre aspect de la discussion avec lequel je ne suis pas d'accord est la comparaison constante avec React. Je comprends sa pertinence mais je ne veux pas que Flutter soit une copie de React sans le pont JS et en changeant le nom des composants en widgets. Si c'est pareil, pourquoi changer ? Cela ne signifie pas que Flutter devrait essayer d'être le plus loin possible de React. Flutter devrait avoir sa propre identité. Je préfère que la culture Flutter consistant à fournir des solutions soit proactive et non réactive. Nous devrions utiliser React uniquement comme un point de contraste, pas comme une ligne directrice.

En ce qui me concerne, si un développeur choisissait de ne pas développer dans Flutter parce que DSX/JSX n'était pas pris en charge, eh bien, cette personne ne voulait pas du tout rejoindre Flutter.

Un autre aspect de la discussion avec lequel je ne suis pas d'accord est la comparaison constante avec React. Je comprends sa pertinence mais je ne veux pas que Flutter soit une copie de React sans le pont JS et en changeant le nom des composants en widgets. Si c'est pareil, pourquoi changer ?

Parce que React a des lacunes que Flutter pourrait combler, puis vous créez quelque chose de meilleur que React car il corrige les inconvénients de React avec les performances Dart et les graphiques accélérés par GPU, tout en conservant les meilleures parties de React ainsi que sa familiarité.

En ce qui me concerne, si un développeur choisissait de ne pas développer dans Flutter parce que DSX/JSX n'était pas pris en charge, eh bien, cette personne ne voulait pas du tout rejoindre Flutter.

Peu importe, le résultat final est que si les développeurs mobiles qui utilisent des outils multiplateformes ne rejoignent pas Flutter, Flutter échouera sur le marché. Flutter doit donc attirer les développeurs React Native pour sa survie.

Parler d'évolution, ce n'est pas "la survie du plus apte", c'est "la survie du plus adaptable". Adaptez-vous ou vous périrez.

@cbazza

Peu importe, le résultat final est que si les développeurs mobiles qui utilisent des outils multiplateformes ne rejoignent pas Flutter, Flutter échouera sur le marché.

Quoi? Pourquoi en aurait-il besoin ? Flutter peut former sa propre niche pendant qu'il est en version bêta (comme il l'a fait avec beaucoup de succès), puis se développer de manière organique sans avoir besoin d'attirer des papillons de nuit avec des caractéristiques superficiellement similaires. Aussi, qu'entendez-vous par "échec" ? Flutter n'a pas besoin d'être populaire pour être un succès.

@naiveaiguy
Écoutez, je sais que vous avez rejeté les réponses de cbazza.
Mais pourriez-vous passer 15 secondes à regarder cela avant de voter contre ma réponse ?

Avant de penser à DSX.
Jetez un œil ci-dessous, ce n'est qu'un JSX.

Après avoir créé une barre de navigation et un corps, vous pouvez simplement importer le code à barres de navigation à partir de votre code à barres de navigation.

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?

Peut-être que quelqu'un déteste JSX parce qu'il vient de Facebook, mais en fait, il provient d'une petite société de jeux japonaise.

Ayant fait des applications avec React Native et Flutter, je pense qu'à l'état actuel, JSX est plus facile à lire et à ajuster que les classes Dart imbriquées pures.
Cependant, comme mentionné précédemment, Facebook avait une raison d'utiliser JSX en raison de la façon dont JavaScript est écrit (par exemple, aucun paramètre de constructeur nommé), ce qui n'est pas le cas avec Dart. De plus, la sécurité de type Dart ajoutée est vraiment agréable!
Donc, au cas où Flutter s'en tiendrait à la syntaxe Dart pure à la fin, j'espère voir des améliorations avec le surligneur de syntaxe et le formateur automatique. Les nouveaux commentaires de balise de fermeture sont déjà une grande amélioration, mais pas assez pour atteindre la productivité JSX.

@JonathanSum Vous expliquez l'idée de composants réutilisables. Vous n'avez pas besoin de JSX pour créer des composants réutilisables. Je pense qu'il pourrait y avoir quelque chose de mieux en affinant la syntaxe de Dart, mais DSX n'est pas du tout une bonne façon de s'y prendre.

@hartmannj Nous sommes toujours à la recherche d'améliorations de la syntaxe, du surligneur et du formateur Dart qui contribueront à la productivité. Pour toute idée ou proposition spécifique pour de telles améliorations auxquelles vous ou d'autres avez pu penser, je serais très curieux d'en savoir plus.

À mon humble avis, la suppression de la nécessité d'utiliser new/const a déjà beaucoup aidé. J'ai de réelles difficultés dans la façon dont le format Dart formate les arbres. il ne met pas assez l'accent sur la structure arborescente à mon humble avis par rapport à:

    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 ne nécessite pas l'utilisation de JSX, mais la plupart des gens le trouvent utile comme aide visuelle lorsqu'ils travaillent avec l'interface utilisateur dans le code JavaScript. Cela permet également à React d'afficher des messages d'erreur et d'avertissement plus utiles.

Lorsque tant de développeurs désireux d'utiliser JSX-like pour créer une interface utilisateur, cela signifie que la voie est nécessaire et qu'ils ne doivent pas être ignorés.

@woodstream Le genre de personnes désireuses d'utiliser JSX sont déjà des fans de fanboys de React. Ils utilisent déjà React Native. Flutter s'adresse à un type de développeur très différent.

EDIT : J'avoue que mon utilisation de fanboy était mauvaise ici.

@naiveaiguy , @Hixie

Le genre de personnes désireuses d'utiliser JSX sont déjà des fanboys de React. Ils utilisent déjà React Native. Flutter s'adresse à un type de développeur très différent.

Vous avez tort et votre nom appelant des commentaires qui divisent ("Réagissez les fanboys" et "différents types de développeurs") ne sont pas les bienvenus. JSX/DSX a un mérite technique et d'autres le préfèrent. Ce fil est pour en discuter, si vous ne l'aimez pas, désabonnez-vous. Arrêtez également de voter contre chacun de mes commentaires, cela n'augure rien de bon pour vous.

Je suggère simplement d'offrir deux façons aux développeurs de choisir ce qu'ils aiment, et quelqu'un aime-t-il donner un coup de pouce devant des opinions différentes ? La technologie devrait être ouverte et inclusive plutôt que de jouer dans une communauté fermée.

@anders-sandholm Je suis d'accord avec @escamoteur sur la nécessité d'améliorer la visibilité de l'arborescence des widgets. J'aurais fait son exemple comme suit:

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

De plus, je pourrais imaginer mettre en évidence les noms de classe Widget avec une couleur, un style de police ou un poids différents afin qu'ils soient encore plus reconnaissables tout de suite.

@cbazza

Appel de nom ? Je n'ai pas laissé entendre que ces personnes étaient négatives, seulement qu'elles étaient différentes. J'aime ce fil, mais m'accuser d'argumenter de mauvaise foi est un peu ironique.

Le mot "fanboy" est généralement considéré comme péjoratif, et a également été pris dans ce contexte. Je recommande d'éviter des mots comme ça dans les discussions ici.

S'il vous plaît tout le monde, soyez civil et constructif. Nous parlons ici de style , quelque chose de très subjectif, donc peu importe à quel point chacun aime sa propre préférence, il est peu probable qu'elle soit intrinsèquement supérieure à celle de tout le monde. Énumérez les avantages et les inconvénients que vous voyez avec les syntaxes existantes et proposées, mais rappelez-vous que tout le monde ne le voit pas de la même manière, et c'est parfaitement bien.

@hartmannj

Juste quelques petites précisions...

Cependant, comme mentionné précédemment, Facebook avait une raison d'utiliser JSX en raison de la façon dont JavaScript est écrit (par exemple, aucun paramètre de constructeur nommé), ce qui n'est pas le cas avec Dart.

En fait, depuis ES2015/ES6, JS a des paramètres nommés ; vous pouvez simplement utiliser 'déstructuration' pour cela :)
Voici un exemple:

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

De plus, la sécurité de type Dart ajoutée est vraiment agréable!

Vous obtenez la même sécurité de type avec DSX, ce qui est en effet agréable.

Puisqu'il s'agit d'un doublon du https://github.com/flutter/flutter/issues/11609 rapporté précédemment, je vais fermer celui-ci en faveur de celui-là.

Je ne comprends vraiment pas comment les gens peuvent voter contre cela - quelque chose qui est si naturel par rapport à la façon dont le code déclaratif est écrit à l'ère d'Internet.

<like><this /></like>

s'il vous plaît soyez assez flexible pour donner à Flutter la chance de voler !

Malheureusement, cela semble sans espoir, chaque technologie utilisait le balisage pour créer une interface utilisateur dans le passé et même maintenant et toute cette expérience de développeur est maintenant gaspillée par le flutter.

nous n'avons pas besoin de le faire comme réagir natif ou html, utilisez simplement xml simple

et peut-être... xml intégré dans Dart ! ;P

Le mardi 28 août 2018 à 21h29, Touseef [email protected] a écrit :

nous n'avons pas besoin de le faire comme réagir natif ou html, utilisez simplement xml simple

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/flutter/flutter/issues/15922#issuecomment-416550338 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AC8aNdVb_NV8c8JH4t36OS1OOvX6kY58ks5uVSmjgaJpZM4S6HPa
.

--
Tony Polinelli

Pour moi, la fonctionnalité de type JSX est l'avenir et elle deviendra une construction standard pour les frameworks déclaratifs comme React, Vue & Flutter.

nous n'avons pas besoin d'intégrer xml dans dart si nous pouvons simplement avoir 2 fichiers séparés pour l'interface utilisateur et la logique, nous pouvons facilement suivre mvvm, mvc ou tout autre modèle souhaité.

Je l'ai dit dans l'autre fil mais :

Si vous voulez vraiment JSX, un bon démarreur utilise la génération de code. Allez avec un fichier .html ou .xml et générez des widgets à partir de ceux-ci.

Évidemment, ce n'est pas un JSX à part entière, mais c'est un début. Assez pour voir comment la communauté y réagira.
Si cette syntaxe gagne du terrain, peut-être que l'équipe Flutter reconsidérera le sujet.

Sinon, je pense que c'est juste une perte de temps. Nous pouvons clairement voir d'ici qu'il s'agit d'un sujet fortement débattu.

Si flutter introduit et xml / jsx / appelez-le comme vous voulez pour créer l'interface utilisateur, je commencerais à l'utiliser pour les applications de niveau de production en un clin d'œil !

Je suis d'accord @leossmith c'est la seule chose qui est un obstacle pour les applications de niveau de production.

Personnellement, je préférerais ne pas ajouter JSX ou un langage de balisage externe. Je préfère tout garder dans un seul langage dont le type est vérifié. Je pense qu'une meilleure approche consiste à continuer à améliorer le langage Dart dans le but de coder des arbres d'interface utilisateur déclaratifs profondément imbriqués. Ils ont déjà ajouté quelques fonctionnalités intéressantes dans ce domaine :

• Rendre les mots-clés new et const facultatifs aide.
• Balises de fermeture virtuelles dans l'IDE
• dartfmt aide aussi

Je préfère tout garder dans une seule langue vérifiée

C'est exactement ce que fait DSX/JSX, le langage est Dart pour DSX, Javascript pour JSX !!!

Je pense qu'une meilleure approche consiste à continuer à améliorer le langage Dart dans le but de coder des arbres d'interface utilisateur déclaratifs profondément imbriqués.

DSX est une amélioration du langage Dart pour mieux prendre en charge les arbres déclaratifs profondément imbriqués. Tout comme JSX est pour Javascript.

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

Le but de cette spécification est de définir une syntaxe concise et familière pour définir des structures arborescentes avec des attributs.

@cbazza Vous soulevez un bon point. JSX est juste une amélioration de JavaScript.

Alors d'abord, séparons clairement deux choses :

1. DSL externe pour définir l'interface utilisateur. Je suis à 100% contre ça. J'ai toujours cru que cela créait plus de problèmes qu'il n'en résolvait. J'ai écrit un article de blog sur ce point. Il a obtenu 58 000 vues et, étonnamment, presque aucune opinion dissidente : 80 % de mon codage le fait (ou pourquoi les modèles sont morts)
2. Améliorations linguistiques. Pour faciliter la construction et la visualisation de structures arborescentes d'interface utilisateur profondément imbriquées. Sur ce point, nous convenons tous les deux qu'il y a place à l'amélioration.

Mais nous différons légèrement sur l'approche. Il y a deux raisons pour lesquelles JSX a plus de sens pour React :

1. Structure des données : sur le Web, JSX correspond exactement à la chose générée (nœuds HTML DOM). En flutter, nous générons des instances Widget.
2. Familiarité : Les gens sont habitués à regarder du code html. Mais la proposition DSX s'écarte de JSX/XML juste assez pour invalider ce point.

Vous trouverez ci-dessous les deux choses (je crois) qui rendent XML bon (et lisible) pour la construction d'arborescences d'interface utilisateur. La question est de savoir si cela peut être réalisé sans introduire XML dans le langage :

1. XML a des balises de fin. Ceci est possible avec ou sans une syntaxe xml-ish. Visual Basic l'avait dans les années 90 (pensez à End If). Et d'autres langues l'ont. L'IDE fournit des "balises de fin virtuelles", mais c'est un peu sommaire. Je préférerais un soutien linguistique.
2. XML a un traitement spécial des enfants. Les attributs sont distincts des enfants. Mais je dirais que c'est une épée à double tranchant. Dans certains cas, Dart est en fait plus clair et expressif que XML à cet égard. Par exemple, des widgets de conteneur avec différents modèles de contenu enfant :

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

Proposition de Dave pour le problème de balise de fin

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

Ce serait facile à lire par les humains. Et un analyseur remplacerait simplement le )ButtonsView par ) . En outre, l'IDE pourrait fournir une meilleure vérification et une meilleure assistance avec ce schéma. Je le rendrais obligatoire chaque fois que les parenthèses ouvertes et fermées ne sont pas sur la même ligne.

Proposition de Dave pour le problème des enfants imbriqués

Certains langages (comme kotlin) autorisent un traitement spécial pour les arguments de type lambda. Ils vous permettent de mettre l'argument lambda en dehors des parenthèses. Voir Passer un lambda au dernier paramètre .

Je propose quelque chose de similaire pour Dart, mais comme argument de type List, pas pour les lambdas. Je propose une syntaxe spéciale pour passer un argument de type list nommé "children":

```
//au lieu de cela:
Foo(a:1, b:10,c:44, enfants:[...])

// on fait ça :
Foo(a : 1, b : 10, c : 44)[

]

Pour les constructeurs/fonctions qui prennent un seul enfant ou 2 enfants (comme top et bottom), laissez-le tel quel, aucun changement.

Je préfère tout garder dans une seule langue vérifiée

C'est exactement ce que fait DSX/JSX, le langage est Dart pour DSX, Javascript pour JSX !!!

Je pense qu'une meilleure approche consiste à continuer à améliorer le langage Dart dans le but de coder des arbres d'interface utilisateur déclaratifs profondément imbriqués.

DSX est une amélioration du langage Dart pour mieux prendre en charge les arbres déclaratifs profondément imbriqués. Tout comme JSX est pour Javascript.

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

Le but de cette spécification est de définir une syntaxe concise et familière pour définir des structures arborescentes avec des attributs.

@StokeMasterJack - votre proposition pour le problème de balise de fin ressemble à ma proposition il y a quelque temps.
Idée : Balises de fermeture générées automatiquement

Je pense que Flutter a besoin de quelque chose comme ça. J'ai du mal à insérer de nouveaux widgets dans un nid profond la plupart du temps. J'utiliserais une syntaxe de type JSX juste pour obtenir la notation de balise de fin.

Je ne veux pas avoir à écrire des balises de fermeture. C'est une douleur dans JSX/html/xml. Surtout quand je veux refactoriser.
Je pense que les balises de fermeture virtuelles sont plutôt soignées. Cela semble être un bon compromis entre les deux mondes.

Si nous avons vraiment besoin d'améliorations ici, je pense que nous pouvons continuer à explorer du côté de l'IDE. Par exemple, vscode fournit le panneau suivant :

(Presque sûr qu'Android Studio a le même)

Au lieu de s'arrêter à la méthode ciblée, nous pourrions également ajouter des constructeurs imbriqués.
Ainsi, lors du survol d'une classe spécifique, nous obtenons l'interface utilisateur suivante :

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

S'il s'agit de séparer visuellement les widgets des autres types de contenu, l'IDE peut le refaire aussi.

Nous pouvons avoir une coloration syntaxique différente pour les widgets. Au lieu de la couleur habituelle utilisée pour les classes, nous pouvons avoir une couleur spécifique pour la sous-classe de widget

S'il s'agit de possibilité de modification, Flutter fournit déjà tous les outils dont vous avez besoin.

Il existe de nombreuses options de refactoring, notamment :

• Envelopper dans un nouveau widget
• Supprimer le widget
• Échanger le widget avec l'enfant
• Échanger le widget avec le parent

Avec ces éléments à l'esprit, vous n'avez plus à vous soucier des parenthèses.

En toute honnêteté, j'ai passé des heures quotidiennement à jouer autour de Flutter pendant des mois. Et je n'ai ressenti aucun manque de lisibilité ou aucune gêne dans l'écriture de widgets imbriqués.
Alors qu'en comparaison, j'ai utilisé React pour autant et il y a des choses qui me frustrent.

@rrousselGit - ces options de refactoring dont vous disposez semblent utiles. Je ne les vois pas sur Android Studio 3.2.
Je pensais qu'Android Studio fournirait les meilleures fonctionnalités pour le développement de Flutter.

@Rockvole

Voici une capture d'écran d'Android Studio :

Activé en tant que correctif rapide Option+Enter (macOS).
Je les utilise tout le temps, super utile.

Sur le sujet : il semble que l'équipe Flutter explore des options pour "l'interface utilisateur en tant que code" et nous pourrions obtenir plus d'améliorations sur ce front tôt ou tard. Bien que les idées de @StokeMasterJack semblent intéressantes.

@Rockvole Les grands esprits se ressemblent !

@StokeMasterJack

Belle réponse !!!

Il y a deux raisons pour lesquelles JSX a plus de sens pour React :

1. Structure des données : sur le Web, JSX correspond exactement à la chose générée (nœuds HTML DOM). En flutter, nous générons des instances Widget.

La puissance de JSX ne réside pas dans la génération de nœuds HTML/DOM, mais dans la gestion des hiérarchies de composants ; React Native n'a pas de nœuds HTML/DOM, n'est-ce pas ?

1. Familiarité : Les gens sont habitués à regarder du code html. Mais la proposition DSX s'écarte de JSX/XML juste assez pour invalider ce point.

Tout comme ci-dessus, il ne s'agit pas de code HTML, il s'agit d'une syntaxe qui devient clairement distincte des constructions impératives du langage hôte et crie un balisage déclaratif pour la construction de hiérarchies arborescentes .

Je ne suis pas fan de votre proposition ou de celle de Kotlin car cela ressemble à un hack fait pour éviter de faire un bon design. Au lieu de concevoir un DSL qui semble distinct, je dois maintenant regarder le code et essayer de comprendre ce qu'il fait ; La syntaxe semble ambiguë. Il y a des avantages à séparer les constructions impératives et déclaratives ; Les outils tiers peuvent facilement localiser le balisage XML à l'intérieur du code, par exemple.

@Rockvole

J'utiliserais une syntaxe de type JSX juste pour obtenir la notation de balise de fin

Bon à savoir ;)

@rrousselGit

Je ne veux pas avoir à écrire des balises de fermeture.

Vous n'êtes pas obligé de le faire; WebStorm, par exemple, génère automatiquement la balise de fermeture et renomme même les balises d'ouverture ou de fermeture lorsque vous modifiez l'autre. Fonctionnalité d'éditeur vraiment géniale que les autres devraient suivre (en vous regardant 'VS Code').

En toute honnêteté, j'ai passé des heures quotidiennement à jouer autour de Flutter pendant des mois. Et je n'ai ressenti aucun manque de lisibilité ni aucune gêne à l'écriture de widgets imbriqués

J'espère que vous comprendrez que votre expérience ne reflète pas l'expérience de tout le monde. Avec l'outillage, l'écriture n'est pas aussi pénible que la lecture du code. Allez sur github pour lire le code des autres et vous remarquerez que la lecture est pénible, le code est trop verbeux et long avec des structures imbriquées. Il semble que lorsque les chaînes de promesses étaient utilisées avant que async/wait ne montre un meilleur moyen. De plus, on a l'impression que les techniques déclaratives sont moins importantes que les impératives ; Je veux dire pourquoi n'y a-t-il pas de constructions graphiques vectorielles déclaratives? à la place, je dois utiliser des appels impératifs à Skia pour le dessin de graphiques vectoriels par exemple.

Vous n'êtes pas obligé de le faire; WebStorm par exemple génère automatiquement

Vscode le fait aussi. Mais que ce n'est toujours pas parfait. Surtout dans l'étape de refactorisation lors du déplacement des choses.
Je pense que les balises virtuelles offrent une expérience beaucoup plus fluide ici.

J'espère que vous pouvez comprendre que votre expérience ne reflète pas l'expérience de tout le monde

Avec certitude ! Je voulais juste souligner qu'il peut s'agir davantage d'une inexpérience avec l'outillage que d'un véritable manque 😄

Allez sur github pour lire le code des autres et vous remarquerez que la lecture est pénible, [...]

Je ne vois pas très bien en quoi vos arguments ici sont liés au sujet.
Le problème que vous avez répertorié provient de mauvaises pratiques, pas d'une mauvaise syntaxe. Ce n'est pas la faute de Flutter si les gens veulent créer un arbre de 500 widgets de long.

@pulyaevskiy - merci pour le conseil utile, sous Linux, la solution rapide est Alt-Entrée. Pas une fonctionnalité très facile à découvrir, j'ai parcouru les options du menu supérieur mais il semble qu'elle ne soit nulle part sauf en appuyant sur une touche magique :)

Je pense que les balises virtuelles offrent une expérience beaucoup plus fluide ici.

Ces balises virtuelles apparaissent-elles sur le fichier source dans github par exemple ?

Je ne vois pas très bien en quoi vos arguments ici sont liés au sujet.

Fondamentalement, le langage pourrait fournir des constructions pour rendre les choses moins verbeuses, comme je l'ai mentionné dans l'exemple promesses vs asynchrone/attente. Dans Flutter Widget, les constructeurs sont énormes et prennent souvent beaucoup de paramètres. avec DSX, vous pouvez utiliser l'opérateur de propagation , par exemple, pour compresser un constructeur de 10 lignes en un constructeur de 1 ligne et, par conséquent, vous pouvez toujours avoir la hiérarchie complète de l'arbre visible avec moins de bruit autour d'elle. Cela facilite la lecture du code et permet une séparation nette du style de l'arborescence par exemple. Je ne dis pas que cela ne peut pas être fait en restructurant votre code Dart, mais cela peut être fait sans trop d'efforts ni de restructuration. Vous n'avez pas besoin de vous adapter aux limites de la langue, la langue s'adapte à vous.

Le problème que vous avez répertorié provient de mauvaises pratiques, pas d'une mauvaise syntaxe.

Avant async/wait, les meilleures pratiques consistaient à utiliser des promesses au lieu de rappels d'événements fous partout. L'utilisation de promesses entraîne des problèmes de lisibilité qui ont été résolus par async/wait. C'est fondamentalement la même chose, juste du sucre syntaxique, mais async/wait est plus clair lors de la lecture du code de quelqu'un d'autre.

Ceci est un exemple terrible @woodstream

Mise à jour : Juste pour faire valoir mon point de vue et pas seulement pour dénigrer des mots sans aucun argument. L'équivalent DSX est tout aussi long... Cela n'a rien à voir avec le nombre de lignes ou HTML.

class MusicImage extends StatelessWidget {

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

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

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

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

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

En tant que développeur React, je pense que ce que cette communauté doit faire est de fournir cette fonctionnalité elle-même et lorsque les développeurs commencent à l'adapter et à l'utiliser réellement ; les principaux contributeurs seront alors contraints de l'adapter nativement également. Je suis un développeur React et j'ai beaucoup de problèmes avec la façon dont l'interface utilisateur est écrite en flutter, j'aimerais passer à flutter mais la syntaxe n'aide pas, je chercherais même comment implémenter la syntaxe de type JSX moi-même, comme dit précédemment "C'est bien d'avoir l'option".

Je pense que l'une des principales raisons pour lesquelles les gens s'opposent à cela, c'est qu'ils ne peuvent pas les imaginer l'utiliser. La vérité est que vous n'êtes vraiment pas obligé de le faire, tout comme les gens utilisent (par rapport à réagir) React.createElement(Component, {}, null) par opposition à <Component /> Si cela est implémenté, cela incitera les gens à utiliser Flutter dans le premier lieu, et c'est ce que nous voulons vraiment. Une grande communauté dédiée à Flutter avec le soutien les uns des autres. Si ce n'est pas le genre de syntaxe que vous utiliseriez, eh bien. Mais des tonnes préféreraient une notation de type JSX par opposition à la méthode actuelle.

Personnellement, je pense que SGML et ses dérivés sont tout simplement laids. Si nous faisons un DSL, pourquoi pas un avec une syntaxe de type QML ?

Je pense également que certains des points pro-DSX confondent les fonctionnalités de Javascript en tant que langage (que Dart n'a pas en tant que langage) et les fonctionnalités de JSX en tant que DSL. Par exemple,

Fondamentalement, le langage pourrait fournir des constructions pour rendre les choses moins verbeuses, comme je l'ai mentionné dans l'exemple promesses vs asynchrone/attente. Dans Flutter Widget, les constructeurs sont énormes et prennent souvent beaucoup de paramètres. avec DSX, vous pouvez utiliser l'opérateur de propagation , par exemple, pour compresser un constructeur de 10 lignes en un constructeur de 1 ligne et, par conséquent, vous pouvez toujours avoir la hiérarchie complète de l'arbre visible avec moins de bruit autour d'elle.

Ce n'est pas une fonctionnalité que DSX accorderait comme par magie, c'est une fonctionnalité que JSX a parce que Javascript l'a. Dart en tant que langage pourrait gagner l'opérateur de propagation (plutôt improbable IMO), auquel cas vous seriez en mesure de l'utiliser avec des constructeurs et d'autres appels de fonction sans avoir besoin d'un DSL spécial en plus. C'est aussi une fonctionnalité qui fonctionne en grande partie parce que les objets, les hashmaps et les tableaux de Javascript sont tous essentiellement la même chose, ce qui n'est certainement pas le cas avec Dart et ne changera presque jamais.

Et je pense que c'est le problème que beaucoup de gens contre la proposition ont même si ce n'est pas vocalisé - c'est essentiellement une demande pour que Dart se comporte (ou fasse semblant de se comporter) comme Javascript, et bien qu'il y ait des avantages, le fait est que ce sont simplement des langues différentes qui divergent de plus en plus depuis les débuts de Dart 1.

Edit : Ce qui ne veut pas dire qu'un DSL de balisage/modélisation pour l'interface utilisateur est entièrement une mauvaise idée. Honnêtement, ce n'est pas le cas, mais je pense que l'inspiration devrait provenir de langages/frameworks qui sont un peu plus similaires à Dart/Flutter (dans le paradigme de typage ainsi que d'autres détails sémantiques - je ne parle pas de syntaxe simple) que Javascript est.

Dart en tant que langage pourrait gagner l'opérateur de propagation (plutôt improbable IMO)

En fait, la propagation pour les collections est déjà spécifiée et prête à être implémentée, voir Spread Collections et l'ensemble "Language funnel" pour plus d'informations sur les fonctionnalités à venir du langage Dart.

@mraleph Je parlais de l'opérateur de propagation spécifiquement utilisé dans les appels de fonction/constructeur et avec des objets, pas seulement avec des listes ou des cartes - c'est ce que je pense être peu probable. Désolé si ce n'était pas clair !

(Je suis vaguement au courant de cette proposition, mais la dernière fois que je l'ai vérifiée, vous ne pouvez pas simplement diffuser une fléchette Size(10, 10) comme vous pouvez diffuser/détruire un Javascript Size { width: 10, height: 10 } , ou diffuser une liste /map des arguments dans un appel de fonction normal (sans utiliser Function.apply , ce qui sacrifierait la sécurité du type))

@filluchaos

Personnellement, je pense que SGML et ses dérivés sont tout simplement laids. Si nous faisons un DSL, pourquoi pas un avec une syntaxe de type QML ?

Parce que beaucoup de gens, contrairement à vous, ne pensent pas que c'est moche et préfèrent plutôt ça. Vous n'avez pas besoin d'avoir beaucoup de vision pour voir tous les développeurs enthousiastes de React.

JSX/DSX apporte le balisage dans le langage hôte Javascript/Dart d'une manière qui améliore le langage hôte et permet toutes les constructions de langage de programmation sur le balisage. Des trucs très simples et puissants.

Ce n'est pas une fonctionnalité que DSX accorderait comme par magie, c'est une fonctionnalité que JSX a parce que Javascript l'a.

Pas vrai du tout; DSX peut implémenter la propagation par lui-même, il n'a pas besoin de Dart pour le supporter. Ce serait bien si c'était le cas, mais ce n'est pas une obligation. C'est la beauté de la transpilation d'un langage supérieur vers Dart, le langage supérieur n'a pas besoin d'être contraint par Dart.

Mon prototype de transpilateur DSX en ligne traite très bien l'opérateur de diffusion , jetez-y un coup d'œil :
https://spark-heroku-dsx.herokuapp.com/index.html

Et je pense que c'est le problème que beaucoup de gens contre la proposition ont même si ce n'est pas vocalisé - c'est essentiellement une demande pour que Dart se comporte (ou fasse semblant de se comporter) comme Javascript, et bien qu'il y ait des avantages, le fait est que ce sont simplement des langues différentes qui divergent de plus en plus depuis les débuts de Dart 1.

Arrêtez de penser à ce qu'est Dart actuel et concentrez-vous sur ce qu'il pourrait être en prenant les meilleures idées de toutes les autres langues.

Je pense que l'inspiration devrait provenir de langages/frameworks qui sont un peu plus similaires à Dart/Flutter (dans le paradigme de typage ainsi que d'autres détails sémantiques - je ne parle pas de syntaxe simple) que Javascript ne l'est.

Typescript est tapé et prend en charge JSX. Le framework d'interface utilisateur le plus proche de Flutter est React, et devinez ce que React a décollé à cause de JSX. S'il vous plaît, proposez quelque chose de mieux que JSX/DSX et si vous le faites, les gens arrêteront de demander JSX/DSX mais je n'ai rien vu là-bas que je considère meilleur, donc pour le moment, JSX est l'état de l'art .

Il est agréable de voir cependant que les gens du langage Dart prennent les meilleures idées d'autres langages comme Python (liste et compréhension du dictionnaire).

@cbazza

Parce que beaucoup de gens, contrairement à vous, ne pensent pas que c'est moche et préfèrent plutôt ça.

Et vice versa. Pourquoi cette syntaxe et pas une autre, surtout quand elle n'a pas vraiment de relation forte avec le langage ? (Avec le SDK Android, Java et XML avaient une relation depuis des années. Idem avec Javascript et HTML, auxquels JSX ressemble fortement. DSX tel que proposé apporterait une syntaxe SGML basée sur celle-ci, ce qui aurait du sens pour d'autres langages mais pas nécessairement pour _Dart_).

JSX/DSX apporte le balisage dans le langage hôte Javascript/Dart d'une manière qui améliore le langage hôte et permet toutes les constructions de langage de programmation sur le balisage. Des trucs très simples et puissants.

Pas vrai du tout; DSX peut implémenter la propagation par lui-même, il n'a pas besoin de Dart pour le supporter. Ce serait bien si c'était le cas, mais ce n'est pas une obligation. C'est la beauté de la transpilation d'un langage supérieur vers Dart, le langage supérieur n'a pas besoin d'être contraint par Dart.

Il est plutôt intéressant de regarder ces deux déclarations en juxtaposition, car elles ne font que prouver mon point de vue. JSX est génial (pour Javascript) spécifiquement en raison de sa simplicité - c'est simplement du sucre sur ce qui sont déjà des constructions de langage JS, il n'implémente pas vraiment de sémantique spéciale lui-même. Vous louez à juste titre cette simplicité, puis continuez en disant que DSX devrait implémenter la sémantique par elle-même indépendamment du langage cible, apparemment sans reconnaître 1) combien de travail supplémentaire il faut demander, et 2) comment cela va complètement à l'encontre du point d'être un DSL simple mais puissant.

Mon prototype de transpilateur DSX en ligne traite très bien l'opérateur de diffusion , jetez-y un coup d'œil :
https://spark-heroku-dsx.herokuapp.com/index.html

J'ai déjà vu votre transpiler, et bien qu'il soit impressionnant, il ne se rapproche en rien du traitement de l'opérateur de propagation de la même manière que Javascript en tant que langage (et donc JSX) le fait par défaut. Comme cela a été mentionné, la diffusion (et éventuellement la déstructuration) des collections n'est pas très en contradiction avec Dart, et est en fait en cours de mise en œuvre. Répartir et déstructurer n'importe quel objet (qui, contrairement à JS, ne sont pas la même chose que Maps) l'est, et votre transpileur ne semble pas non plus gérer cela (et nécessite en fait de mettre des arguments à l'intérieur de Maps, ce qui est plutôt unidiomatique et Dart inutilisable (ne peut pas être interagi avec une manière décemment sécurisée, par exemple)).

Arrêtez de penser à ce qu'est Dart actuel et concentrez-vous sur ce qu'il pourrait être en prenant les meilleures idées de toutes les autres langues.

Sûr. Mais parmi les langues disponibles pour Dart, personnellement, JS n'est pas très élevé sur la liste - je pense honnêtement qu'essayer d'être trop comme JS (pour des raisons d'interopérabilité) a paralysé Dart à ses débuts.

J'aimerais un UI DSL, bien sûr. Mais ce DSL devrait être idiomatique pour _Dart_, et non tiré en gros d'une langue sémantiquement différente en raison de sa seule popularité.

Et j'aimerais aussi que les gens arrêtent de confondre ce que fait Javascript avec ce que fait JSX le DSL, car certains des avantages mentionnés sont en fait des demandes de fonctionnalités déguisées au niveau du langage. Pour continuer avec l'opérateur de propagation, si Dart en tant que langage supportait réellement la gamme complète de l'opérateur tel qu'il est dans JS, je ne vois pas comment return <SomeWidget {...someArgs, arg: newValue } />; est préférable de lire que return SomeWidget(...someArgs, arg: newValue); ou comme QML return SomeWidget { ...someArgs, arg: newValue }; moins que l'on ait un attachement à SGML.

@filluchaos

Pourquoi cette syntaxe et pas une autre, surtout quand elle n'a pas vraiment de relation forte avec le langage ? (Avec le SDK Android, Java et XML avaient une relation depuis des années. Idem avec Javascript et HTML, auxquels JSX ressemble fortement. DSX tel que proposé apporterait une syntaxe SGML basée sur celle-ci, ce qui aurait du sens pour d'autres langages mais pas nécessairement pour Dart).

Arrêtez de jumeler des choses que vous pensez aller ensemble (et avez une relation) et concentrez-vous sur la sélection des meilleures idées, quelle que soit leur origine. Vous êtes en quelque sorte en train de séparer artificiellement les choses quand ce n'est pas nécessaire.

Je choisis la syntaxe JSX car elle est bien considérée dans React et c'est ce que les gens de React attendent et veulent. Ce billet est à ce sujet, si ce n'est pas pour vous, ne l'utilisez pas.

Il est plutôt intéressant de regarder ces deux déclarations en juxtaposition, car elles ne font que prouver mon point de vue. JSX est génial (pour Javascript) spécifiquement en raison de sa simplicité - c'est simplement du sucre sur ce qui sont déjà des constructions de langage JS, il n'implémente pas vraiment de sémantique spéciale lui-même. Vous louez à juste titre cette simplicité, puis continuez en disant que DSX devrait implémenter la sémantique par elle-même indépendamment du langage cible, apparemment sans reconnaître 1) combien de travail supplémentaire il faut demander, et 2) comment cela va complètement à l'encontre du point d'être un DSL simple mais puissant.

Qu'il implémente ou non une nouvelle sémantique, cela n'a pas d'importance. La simplicité vient de son utilisation. S'il est facile à utiliser pour les utilisateurs/développeurs, ils l'utiliseront. Les utilisateurs/développeurs ne se soucient pas de la complexité interne de quelque chose (ou de la quantité de travail à faire), ils se soucient simplement de la simplicité avec laquelle cela rend leur vie et améliore leur code.

J'ai déjà vu votre transpiler, et bien qu'il soit impressionnant, il ne se rapproche en rien du traitement de l'opérateur de propagation de la même manière que Javascript en tant que langage (et donc JSX) le fait par défaut.

Mon intention avec la propagation sur DSX était simplement de diffuser des attributs et non une implémentation JS complète de la propagation. Cela fonctionne très bien pour ce que c'est et il n'y a aucun problème de sécurité de type. La vérification/l'exactitude du type se produit lorsque Dart compile ce que DSX génère.

a paralysé Dart à ses débuts.

Ce qui a paralysé Dart au début n'était pas de fournir une interopérabilité JS simple, de sorte que les bibliothèques JS actuelles pouvaient être utilisées facilement avec le code Dart (et vice-versa). C'est aussi exactement la même raison pour laquelle Typescript a réussi là où Dart a échoué.

J'aimerais un UI DSL, bien sûr. Mais ce DSL devrait être idiomatique pour Dart, et non tiré en gros d'un langage sémantiquement différent en raison de sa seule popularité.

La popularité dicte tout. Les meilleures idées sont les meilleures idées parce qu'elles deviennent populaires parce que beaucoup de gens apprécient ses avantages.

Et j'aimerais aussi que les gens arrêtent de confondre ce que fait Javascript avec ce que fait JSX le DSL, car certains des avantages mentionnés sont en fait des demandes de fonctionnalités déguisées au niveau du langage.

Encore une fois ce n'est pas pertinent.

Ce dont nous avons vraiment besoin de la part des gens de Google (Dart/Flutter), c'est un support de transpilation générique via des cartes source afin que n'importe quel langage de niveau supérieur puisse être développé qui cible Dart/Flutter et cela fonctionnerait très bien avec les outils actuels (IDE, débogueur, etc.) . Égalisez les règles du jeu et vous garantissez que les meilleures idées viendront des autres sur la plate-forme.

@cbazza

Je choisis la syntaxe JSX car elle est bien considérée dans React et c'est ce que les gens de React attendent et veulent. Ce billet est à ce sujet, si ce n'est pas pour vous, ne l'utilisez pas.

Cela me semble plutôt source de division et me donne un peu droit. Pourquoi Flutter devrait-il avoir un support de première classe pour la syntaxe spécifiquement React ? Pourquoi pas les fichiers de composants Vue ou la syntaxe Xamarin.Forms ? Pourquoi le DSL d'interface utilisateur (vraisemblablement officiel) pour Flutter doit-il être basé sur ce qu'un ensemble particulier de personnes utilisant un cadre différent dans une langue différente attend et veut? Si vous voulez un outil communautaire spécifiquement pour les développeurs React/JS, ce serait une chose. Mais demander que le cadre lui-même l'inclue uniquement pour répondre à tous, c'est un peu beaucoup à l'OMI.

Qu'il implémente ou non une nouvelle sémantique, cela n'a pas d'importance. La simplicité vient de son utilisation. S'il est facile à utiliser pour les utilisateurs/développeurs, ils l'utiliseront. Les utilisateurs/développeurs ne se soucient pas de la complexité interne de quelque chose (ou de la quantité de travail à faire), ils se soucient simplement de la simplicité avec laquelle cela rend leur vie et améliore leur code.

C'est une forme de droit tellement étrange à mon avis. Et non, les développeurs se soucieront de la complexité d'une implémentation lorsqu'elle commencera à causer des problèmes et une dérive des fonctionnalités, comme la complexité des abstractions a tendance à le faire. Les développeurs qui veulent faire plus que simplement utiliser le DSL - l'étendre, par exemple - se soucieront très certainement de la complexité de l'implémentation. Les développeurs qui devraient le construire et le maintenir sont également des personnes qui méritent d'être prises en compte à cet égard.

Mon intention avec la propagation sur DSX était simplement de diffuser des attributs et non une implémentation JS complète de la propagation. Cela fonctionne très bien pour ce que c'est et il n'y a aucun problème de sécurité de type. La vérification/l'exactitude du type se produit lorsque Dart compile ce que DSX génère.

Il "n'a pas de problèmes de type sécurisé" seulement si vous n'y pensez pas du tout. Ce que j'ai dit, c'est que les cartes d'arguments ne sont pas _utilisables_ de manière totalement sûre avec le reste d'une base de code Dart, où vous voudriez probablement interagir avec ces arguments comme vous le pouvez avec des accessoires et autres en JavaScript - passez-les d'un autre Widget, importez-les à partir d'un autre module, etc. - et ne vous contentez pas de les déclarer à un seul endroit, auquel cas quel est l'intérêt par rapport à un appel de constructeur normal ?

Pour illustrer ce que je veux dire, vous pouvez le faire en JS :

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

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

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

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

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

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

Mais avec Dart et votre transpiler qui nécessite des hashmaps d'arguments :

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

Ce qui a paralysé Dart au début n'était pas de fournir une interopérabilité JS simple, de sorte que les bibliothèques JS actuelles pouvaient être utilisées facilement avec le code Dart (et vice-versa). C'est aussi exactement la même raison pour laquelle Typescript a réussi là où Dart a échoué.

L'interopérabilité de Dart avec JS n'a jamais été complexe, à moins que (et c'est un point que je continue à souligner) vous vouliez simplement continuer à écrire du Javascript et que vous soyez opposé à apprendre autre chose. Typescript étant un sur-ensemble n'a pas tant d'opérabilité avec JS qu'il s'agit simplement de JS, au point d'avoir délibérément un système de type malsain juste pour répondre à JS (ainsi qu'aucun runtime pour réellement appliquer son système de type expressif, qui est un putain de honte depuis tant d'années). Mais revenons à mon point de vue, je pense personnellement que Dart a pris quelques mauvaises décisions de conception pour le bien de JS et que Dart 2 aurait vraiment dû être la première itération du langage.

La popularité dicte tout. Les meilleures idées sont les meilleures idées parce qu'elles deviennent populaires parce que beaucoup de gens apprécient ses avantages.

Les "meilleures", ou plutôt les bonnes idées sont de bonnes idées car elles ont du mérite . Parfois, ils deviennent populaires, parfois non. Parfois, les mauvaises idées deviennent populaires, parfois non. Suggérer que la popularité est un indicateur direct du mérite est franchement absurde et c'est une attitude que je préférerais personnellement ne pas déborder sur la communauté Dart, aussi petite soit-elle.

Ce dont nous avons vraiment besoin de la part des gens de Google (Dart/Flutter), c'est un support de transpilation générique via des cartes source afin que n'importe quel langage de niveau supérieur puisse être développé qui cible Dart/Flutter et cela fonctionnerait très bien avec les outils actuels (IDE, débogueur, etc.) . Égalisez les règles du jeu et vous garantissez que les meilleures idées viendront des autres sur la plate-forme.

... Je ne pensais pas qu'il était possible d'avoir encore plus de droits que vous ne l'étiez auparavant, et pourtant nous y sommes. Pourquoi est-ce ce SDK d'interface utilisateur unique qui doit pouvoir être ciblé par toutes les langues de haut niveau du monde ? Encore une fois, la proposition se présente fortement comme "Make Dart/Flutter into my language/framework" - vous pourriez tout aussi bien dire que vous voulez créer des applications Flutter avec Javascript. Et oui, plus d'huile dans votre coude et je serais tout à fait d'accord pour contribuer à un projet communautaire comme celui-là, mais c'est franchement ridicule d'attendre une réponse positive si vous demandez un soutien officiel pour cela.

Encore une fois, réitérant - cela ne me dérange pas un UI DSL et j'en aimerais vraiment un. Mais si nous demandons à l'équipe de l'intégrer, il devrait s'agir d'un DSL idiomatique pour Dart. Parce que oui, il y a des dizaines d'entre nous ici qui aiment réellement Dart comme langue.

Encore une autre modification : ce serait une chose de demander un DSL, de suggérer JSX comme source d'inspiration possible pour la syntaxe/syntaxe et d'être ouvert à d'autres suggestions. C'est l'insistance sur DSX qui me frotte (et je soupçonne beaucoup de ceux qui ont commenté) mal.

@filluchaos

Vous êtes hilarant confus et je n'ai pas encore beaucoup de temps à perdre.

La seule chose que je demande à l'équipe Dart/Flutter est ce que j'ai déjà dit :

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.

Cela fournit tout le nécessaire pour implémenter DSX, les fichiers de composants Vue, Xamarin.Forms, NativeScript, QML, etc. et permettrait donc à la communauté de proposer tout ce qu'elle veut et personne n'a à "prendre" mon DSX. Vous n'aimez pas DSX, vous pouvez utiliser Dart ordinaire ou créer facilement votre propre chose.

Je dirais que vous recherchez des choses comme https://github.com/dart-lang/build et dartanalyzer.
Vous manquerez probablement un morceau ou deux (comme la possibilité de créer des plug-ins d'analyseur en tant que dépendance de pub), mais je suis à peu près sûr que l'équipe Dart est d'accord pour vous aider.

Dans tous les cas, je ne pense pas qu'être dur les uns envers les autres en permanence aidera le cadre à progresser de quelque manière que ce soit.
Le maximum que nous en tirerons est un autre problème définitivement fermé car il est devenu "trop ​​​​échauffé".

@filluchaos

En ce qui concerne votre exemple 'foo', la propagation DSX est une chose au moment de la compilation, donc la carte devrait être définie comme const ou je pourrais proposer tout ce que je voulais faire au moment de la compilation (par exemple créer un nouveau mot clé ou annotation DSX pour celui-ci suivi de la carte const). Cela doit être au moment de la compilation, et non au moment de l'exécution, car Dart ne prend pas en charge l'insertion de paramètres de constructeur dynamique au moment de l'exécution. Ce n'est pas un problème car cela résout le problème que je voulais résoudre, c'est-à-dire la diffusion d'attributs sur les constructeurs.

@cbazza Le fait est qu'une partie de ce qui rend l'opérateur de propagation si pratique dans JS/JSX est que vous n'avez pas à imposer de restrictions telles que "vous ne pouvez utiliser qu'un hashmap" ou "tous vos arguments doivent être connus au moment de la compilation" ou "vous ne pouvez pas interagir avec les arguments/accessoires que vous voulez passer à un Widget de la même manière que vous pouvez interagir avec tout le reste" (notez que vous n'avez rien suggéré pour gérer le cas où la chose avec les propriétés que vous le besoin est en fait un objet, pas un littéral de carte) -0 c'est bien beau quand c'est un exemple simple, mais ce genre de chose deviendrait extrêmement frustrant _fast_ dans n'importe quel projet de taille moyenne. Je veux dire, à quel moment arrête-t-on d'accumuler des solutions de contournement, des compromis et des annotations, prend du recul et se demande si l'extension est réellement adaptée au langage tel qu'il existe ?

JSX a été un tel succès (par rapport à la plupart des modèles) car il ne vous oblige pas à programmer d'une certaine manière (ou plutôt, ne vous oblige pas à écrire du code différemment de ce que vous auriez en Javascript de toute façon). C'est à peu près complètement indolore à utiliser avec _any_ JavaScript; c'est ce que je veux dire par la création d'un DSL qui correspond réellement à la langue. C'est une chose similaire avec Redux. Redux dans une base de code JS est une beauté (lorsqu'il est utilisé correctement); d'un autre côté, tous les exemples de Flutter que j'ai vus en utilisant Redux de manière intensive semblent honnêtement pénibles par rapport à l'utilisation de Streams/le modèle BLoC. Cela ne veut pas dire qu'il n'y a pas de choses qui se chevauchent avec un grand succès : Context de React et Context InheritedWidget Flutter mettent en œuvre un concept commun qui répond incroyablement bien aux points forts des deux. Je ne suis tout simplement pas convaincu que JSX soit actuellement l'une de ces choses - à moins de plusieurs changements au niveau du langage, il semble honnêtement que DSX serait pénible à développer _et_ pénible à utiliser pour autre chose que des exemples triviaux, alors qu'on pourrait probablement écrire un transformateur JSX complet à partir de zéro en un week-end paresseux en raison de la simplicité de mappage vers JS.

Aussi j'ai été un peu agressif tout à l'heure et je m'en excuse.

@filluchaos

Je n'essaie pas de créer un opérateur de propagation entièrement générique qui fonctionne partout et pour tout, même celui prévu pour le futur Dart n'est pas aussi générique que celui de JS. Ce que je veux gérer dans le contexte de DSX, ça marche très bien. DSX n'a ​​pas besoin de propagation d'objets par exemple.

Propagation Collections
https://github.com/dart-lang/language/issues/47

J'ai développé de très gros projets avec JSX et je n'ai vraiment jamais eu besoin d'utiliser les attributs de propagation sur les balises. JSX fonctionne très bien sans cela. La raison pour laquelle j'ai ajouté DSX est qu'il résout un problème pour les widgets Flutter qu'il n'y a pas de solution simple, en particulier si un widget prend 20 paramètres sur le constructeur, comment pouvez-vous écrire cela en moins de 20 lignes continues qui feront le widget arbre une pyramide de malheur. La seule fonctionnalité de la propagation DSX est de permettre de retirer certaines de ces lignes de l'arborescence et de les placer ailleurs.

@cbazaa J'évalue s'il faut utiliser React Native ou Flutter. Je penche vers Flutter parce que tout n'est que Dart pour que le compilateur puisse vérifier mes fautes de frappe dans l'interface utilisateur. Voir aussi : https://medium.com/flutter-io/out-of-depth-with-flutter-f683c29305a8

JSX détecte-t-il également mes fautes de frappe ? J'utilise TypeScript.

Je déteste HTML / balises séparées. Par exemple, dans Angular, si j'ai mal tapé quelque chose/variables en HTML, je ne trouve mes erreurs qu'après avoir rendu la page.

@sivabudh

JSX détecte-t-il également mes fautes de frappe ? J'utilise TypeScript.

Oui, certaines fautes de frappe JSX sont interceptées au moment de la compilation (nom du composant par exemple) mais pas les noms d'accessoires (qui seront interceptés au moment de l'exécution) lors de l'utilisation de JS/ES6 ; mais puisque vous utilisez TypeScript, le système de type intercepte toutes les fautes de frappe JSX au moment de la compilation :
https://www.typescriptlang.org/docs/handbook/jsx.html

@cbazza est dsx open source ?

@pushqrdx
Pas encore, je n'ai pas publié son code source.

En tant que consommateur de React + TypeScript et Flutter, je peux me proposer comme testeur. Acclamations

Aurons-nous la source dsx? Ce sera très bien !

J'applaudis les efforts de cbazza mais je n'utiliserai pas DSX dans Flutter. Au plaisir de tester tout de même.

Le problème #27141 suit l'ajout de la prise en charge de la génération de code au système de génération. Cela se fera via https://github.com/dart-lang/build avec Builder . En théorie, il devrait être assez simple de câbler un compilateur/transpileur dsx lorsque cette fonctionnalité est prête.

Après deux numéros, j'ai rencontré pour la première fois une équipe aussi têtue.

Ce n'est pas une discussion sur JSX, mais une discussion sur l'enfer imbriqué

Même si vous ne pouvez pas donner une solution JSX, vous devriez réduire l'imbrication et rendre le code plus lisible

Je pense que l'avantage de JSX est évident, mais l'équipe Flutter essaie de l'ignorer.

JSX ne résout pas le problème d'imbrication. Réagir face au même problème

Si vous n'aimez pas cette imbrication, vous voudrez peut-être jeter un œil à hooks , qui est un port de crochets React, qui sont eux-mêmes une tentative de résoudre l'enfer de l'imbrication.

Je pense que nous devrions découvrir pourquoi JSX a vu le jour. C'est parce que la fonction h/createElement est mal écrite et que le code est peu lisible. De manière inattendue, le flottement est maintenant écrit 10 000 fois pire que la fonction h/createElement , qui peut être vue des yeux

JSX a vu le jour parce que React est, à la base, un mélange de Javascript et de HTML. La syntaxe XML avec interpolation/injection Javascript crée naturellement JSX.

Flutter est totalement séparé de Javascript et HTML, il ne se traduit donc pas bien en JSX. Je conviens que les projets Flutter sont souvent très imbriqués et cela peut être très pénible, surtout lorsque dartfmt écrase ces lignes fortement imbriquées. Horrible.

Je voudrais également noter que je sentais que Flutter était horriblement structuré quand j'étais nouveau, venant de React, mais Flutter est objectivement beaucoup plus facile à utiliser lorsque vous dépassez la courbe d'apprentissage initiale. La courbe d'apprentissage n'est pas unique à Flutter, elle est courante lors de l'apprentissage de nouveaux frameworks. Flutter est particulièrement difficile car il n'a aucune raison d'agir comme la syntaxe HTML que beaucoup de gens connaissent.

Je pense qu'il existe des moyens d'améliorer le problème d'imbrication, et JSX n'est pas la réponse.

Quelques idées:

1. Développez un guide de style interne qui oblige les gens à diviser les arbres flottants massifs en composants plus petits.

2. Obtenez dartfmt pour reconnaître formellement que Flutter a un ensemble unique de besoins de formatage par rapport aux packages Dart et travaillez avec l'équipe Flutter/Dart pour trouver une solution raisonnable. @munificent

3. Utilisez la génération de code comme le package @stateless @rrousselGit pour permettre aux développeurs de faire plus facilement le numéro 1

Pour être juste, le problème d'imbrication se pose surtout lorsque l'on ne veut pas réfracter notre code.

Les widgets sont faits pour être divisés en plusieurs petits morceaux.
Usage et abus de l'outil de refactoring extract widget .

Cela rend le code beaucoup plus lisible, réduit la redondance et corrige potentiellement même des bugs/augmente les performances.

Bien que je sois d'accord pour la plupart, les widgets Flutter sont d'un niveau si élevé que j'ai vu beaucoup de gens faire des vues entières dans un seul widget parce que... cela fonctionne vraiment très bien et vous n'avez pas à transmettre les accessoires jusqu'à 4-5 niveaux de widgets. Ce que vous perdez dans le processus, c'est que vous obtenez cet horrible code imbriqué que dartfmt brise en quelque chose de méconnaissable. Donc je comprends pourquoi les gens le font, je comprends qu'il existe une solution, mais je comprends aussi pourquoi les gens n'utilisent pas la solution.

JSX a vu le jour parce que React est, à la base, un mélange de Javascript et de HTML. La syntaxe XML avec interpolation/injection Javascript crée naturellement JSX.

Comment expliquez-vous le fait que React Native utilise JSX et que cela n'a rien à voir avec HTML ?

Comment expliquez-vous le fait que React Native utilise JSX et que cela n'a rien à voir avec HTML ?

Parce qu'il utilise React. Ils ne voulaient probablement pas réinventer la syntaxe

Parce qu'il utilise React. Ils ne voulaient probablement pas réinventer la syntaxe

Donc JSX n'est pas vraiment le mélange de Javascript et HTML comme le dit @lukepighetti mais c'est plutôt un 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.
Tout est précisé dans la spécification : https://facebook.github.io/jsx/

Si je comprends bien, React a d'abord été publié en tant que react + react-dom avec un compilateur jsx , donc le mélange HTML + JavaScript était naturel. Après cela, react a été utilisé pour piloter d'autres moteurs de rendu comme react-native , react-vr , react-pdf , etc etc. Je maintiens donc ma déclaration d'origine comme étant raisonnable et sensible à l'histoire et au pedigree de React. La spécification 2019 est la spécification de 2019 et ne traite pas de l'historique de React.

Je suis d'accord

Mais pour moi, il y a un problème plus important. Vue et React fonctionnent de la même manière dans cet aspect.
React a une fonction createElement et Vue a une fonction h .

Nous n'instancions jamais manuellement les composants dans React et Vue. C'est le cadre qui s'en charge.

Flutter se comporte différemment. Nous manipulons directement l'instance d'un Widget.

En tant que tel dans le monde Flutter, un <Foo /> signifie simplement new Foo()

Mais dans ce cas, le JSX est totalement indépendant des Widgets. Nous modifions simplement la syntaxe de la façon dont nous instancions les classes dans Dart.

Pour moi, cela sonne comme si nous perdions le sens de ce qu'est la création d'un widget.

@lukepighetti
react-pdf n'est pas un autre rendu de réaction, vous devez penser à react-canvas .
Donc react != react-dom != react-native . Le package react est responsable de la gestion des hiérarchies de composants à l'aide de JSX donc react ne se soucie pas s'il génère react-dom , react-native , react-canvas , donc react n'est pas vraiment du HTML.

La spécification 2019 est la spécification de 2019 et ne traite pas de l'historique de React.

La spécification 2019 de JSX n'existe pas. Il n'y a qu'une seule version de JSX et c'est la version originale publiée en 2014 à partir du lien que j'ai fourni (https://facebook.github.io/jsx/).

@rrousselGit

Nous modifions simplement la syntaxe de la façon dont nous instancions les classes dans Dart.

Pour le cas de DSX avec Flutter, c'est exactement ce que fait le transpiler.

Pour moi, cela sonne comme si nous perdions le sens de ce qu'est la création d'un widget.

Comment pouvez-vous perdre quelque chose si rien n'est supprimé, vous gagnez juste une autre façon de faire quelque chose (qui a des avantages et des inconvénients) et maintenant vous avez la liberté de choix, choisissez celui qui vous convient le mieux.

Bonjour, je pense que vous avez peut-être mal compris mon message. react pilote d'autres moteurs de rendu tels que react-dom , react-native , react-pdf , react-vr , etc. Afaik, react et react-dom ont été publiés simultanément, donc l'héritage de jsx est, à mon avis, assez clair. J'espère que vous ne creusez pas dans mon message car nous avons des opinions différentes sur la valeur de JSX dans le contexte de Flutter. Il serait probablement préférable de rester sur le sujet et de ne pas couper les cheveux en quatre.

Salut lukepighetti, avez-vous utilisé React Native avec JSX pendant un à deux mois ? Si tel est le cas, vous devez comprendre pourquoi la création d'une application avec JSX ET le style de framework natif (ou réactif, je sais qu'ils sont différents) est simple et bien structuré.
Cependant, si vous ne l'avez pas utilisé pendant un certain temps, vous ne comprendrez jamais pourquoi JSX est si utile et important.

J'espère toujours que Google pourra comprendre la beauté de JSX, et comme nous avons eu beaucoup de gens qui l'ont soutenu. L'équipe de Google pensera peut-être un jour à DSX ou JSX pour un framework inspiré de React, flutter.

Salut lukepighetti, avez-vous utilisé React Native avec JSX pendant un à deux mois ? Si tel est le cas, vous devez comprendre pourquoi la création d'une application avec le style de framework natif JSX AND React (ou React, je sais qu'ils sont différents) est simple et bien structurée.

Je ne peux pas parler pour lukepighetti, mais je travaille professionnellement avec React depuis deux ans, je fais maintenant du Vue. Je connais donc assez bien JSX.

De même, j'utilise Flutter depuis environ 2 ans aussi. Au début, je pensais aussi que Flutter avait besoin d'une sorte de JSX.
Mais Flutter s'est beaucoup amélioré pendant cette période et j'ai changé d'avis.

• JSX est horrible à écrire à la main. Cela nécessite beaucoup d'outils pour le rendre supportable, y compris des balises à fermeture automatique, des balises de renommage automatique et emmet. Et même alors, c'est loin d'être aussi simple que la syntaxe de Flutter.

Par exemple, refactoriser Foo() en Foo(child: Bar()) est facile.
Mais refactoriser <Foo /> en <Foo><Bar /></Foo> ne l'est pas.

• Flutter offre de nombreuses options de refactorisation qui facilitent encore plus la manipulation des parenthèses

• Les balises de fermeture virtuelles proposées par Flutter compensent le manque de balises de fin.
  _Mais ils n'apparaissent pas dans les revues de code !_
  Ils le font vraiment ! Vous pouvez faire vos revues de code depuis votre IDE. Voir https://code.visualstudio.com/blogs/2018/09/10/introducing-github-pullrequests

  • JSX ne se traduit pas bien pour le modèle Flutter.

Et si un widget prenait à la fois un child et children ? Obtient-on :

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

?

Dans ce cas, cela signifie que pour des raisons de cohérence, child doit toujours être traité comme un argument nommé au lieu d'utiliser l'emplacement children .

Le fait est que très peu de widgets prennent un children . La grande majorité est soit un seul child , soit une combinaison de paramètres nommés personnalisés (comme Scaffold ).

Ce qui signifie que la grande majorité des widgets utilisant JSX ressembleront à :

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

Ce qui est _pire_ alors :

Container(
  child: Bar(),
)

En résumé, je pense que Flutter va bien. Et même si JSX était disponible, je doute que cela améliore réellement les choses.

Comme je l'ai dit, je pense qu'il y a beaucoup de confusion entre ce qui est en fait JS/ECMAScript/fonctionnalités Web générales (diffusion d'objets, déstructuration, interchangeabilité d'objets/hashmaps, tous les nœuds DOM* ayant une interface très similaire, la flexibilité de HTML dans général, etc.) avec quelles sont les fonctionnalités JSX. Les anciens IMO sont ce qui rend JSX agréable à écrire. Sans eux, vous ne faites qu'écrire du XML, et la plupart des gens que je connais qui ont le choix n'aiment pas écrire du XML.

* Il convient de noter que c'est avant tout ma principale opposition à essayer de convertir Flutter en XML. Je ne pense pas qu'il soit vraiment utile d'essayer de nier que JSX/React a des racines profondes dans le Web, et les éléments DOM ont une norme de longue date selon laquelle chaque nœud a _attributes_ et _children_. D'un autre côté, Flutter n'oblige pas les développeurs à nommer l'emplacement d'un widget personnalisé pour d'autres widgets children ou même child et je ne vois aucune raison pour laquelle il devrait commencer à le faire.

Je peux voir pourquoi l'autre thread JSX était verrouillé. Je ne devrais pas avoir à défendre mes compétences/expérience dans les commentaires GitHub pour expliquer pourquoi je pense que JSX ne profite pas à Flutter. Je pourrais facilement dire "Vous n'avez pas assez d'expérience avec Flutter pour avoir une opinion sur Flutter." Ça ne fait pas du bien, n'est-ce pas. Vous appréciez tous votre tribu de guerriers clavier.

Et si un widget prenait à la fois un child et children ? Obtient-on :

Pourquoi un widget doit-il avoir à la fois child et children ? C'est ceci ou cela。
Un autre sujet ， Certains widgets de Flutter utilisent children , et les autres utilisent child , personne ne pense que c'est compliqué et facile à confondre？ children contient child , donc non peu importe combien de child vous avez, un ou plus d'un, utilisez simplement children pour faire le travail.

@rrousselGit

JSX est horrible à écrire à la main. Il faut beaucoup d'outillage pour le rendre supportable,

Non seulement tout le monde React n'est pas d'accord avec vous, mais aussi tout le monde HTML et le monde XML.

Flutter offre de nombreuses options de refactorisation qui facilitent encore plus la manipulation des parenthèses

Donc, vous dites que Flutter "nécessite également beaucoup d'outils", mais comme vous êtes biaisé, vous ressentez le besoin de jeter l'autre côté. Pour votre information : la meilleure chose à faire est d'accepter qu'il y a plus d'une façon de faire quelque chose et que certaines personnes préféreront l'autre façon de faire.

Ils le font vraiment ! Vous pouvez faire vos revues de code depuis votre IDE.

Cela ne résout pas le problème pour tous les autres outils de révision de code en ligne utilisés par les équipes. Ces outils manipulent le code source et s'il n'est pas dans le code source, il n'existe pas.

JSX ne se traduit pas bien pour le modèle Flutter.

C'est juste votre mauvaise opinion, tout le monde peut voir que DSX ajoute des améliorations à JSX qui correspondent parfaitement à Flutter.
https://spark-heroku-dsx.herokuapp.com/index.html

Donc, vous dites que Flutter "nécessite beaucoup d'outillage"

Non, j'ai dit "encore plus facile" pas "supportable".

Il m'arrive de répondre souvent à StackOverflow/Slack, et parfois même depuis mon téléphone.
Et j'ai clairement du mal à répondre à une question liée au html - mais Flutter va bien.

la meilleure chose à faire est d'accepter qu'il y a plus d'une façon de faire quelque chose et que certaines personnes préféreront l'autre façon de le faire.

Cela fonctionne dans l'autre sens. Vous devriez le voir clairement, la communauté n'est pas fan à 100% de JSX. Le nombre de votes négatifs sur cette question et la précédente le prouve.

C'est juste votre mauvaise opinion, tout le monde peut voir que DSX ajoute des améliorations à JSX qui correspondent parfaitement à Flutter.

Je ne suis pas d'accord. La syntaxe contient beaucoup de caractères complexes qui, sur de nombreuses dispositions de clavier, sont difficiles d'accès.
Il contient aussi des tonnes de répétitions.

En tout cas, je ne comprends pas pourquoi tu es si agressif en permanence. Nous essayons tous d'améliorer Flutter.
Inutile d'être dur et de refermer cette discussion.

Si JSX ne fonctionne pas bien en flutter, je peux accepter de ne pas rejoindre JSX, mais nous devrions envisager l'enfer imbriqué.

Une autre histoire parallèle est le point-virgule du langage des fléchettes. C'est vraiment agaçant.

Une autre histoire parallèle est le point-virgule du langage des fléchettes. C'est vraiment agaçant.

Il y a une demande pour cela sur dart-lang/language : https://github.com/dart-lang/language/issues/69
Allez lui donner un 👍

Cette longue discussion porte sur la possibilité d'utiliser ceci :

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

Au lieu de cela:

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

Même si l'on est d'accord avec l'ancienne syntaxe pour être supérieure, ce que je ne fais pas personnellement, cela s'accompagne de coûts de maintenance permanents, d'une plus grande complexité et de nouvelles sources d'erreurs possibles, non seulement dans le langage/framework mais aussi dans les outils environnants comme les IDE, débogueur, linter, etc. Cela augmente également les temps de construction. Et cela oblige les développeurs à apprendre une nouvelle syntaxe et à s'occuper des éléments internes du transpileur, pour comprendre quand et comment les instances sont créées. Tout cela à peu près dans le seul but de React & co. les développeurs se sentent chez eux.

Avant de commencer avec de nouveaux langages, je préfère me concentrer sur l'amélioration de Dart, qui est loin d'être idéal, car il manque des fonctionnalités importantes telles que la correspondance de modèles , les classes de données , les ADT , la déstructuration , les options appropriées , etc. Certains de ces PR sont déjà ouverts 5+ années. Ceci, contrairement à l'ajout d'une couche de balisage cosmétique et inutile pour créer des widgets, a un impact énorme sur l'architecture, la sécurité et la qualité globale du code.

Même si cela est relégué à « animé par la communauté », il est encore temps que la communauté puisse passer à travailler sur quelque chose de significatif. Mais bien sûr chacun peut faire de son temps ce qu'il veut. Arrêtez simplement de mettre cette pression disproportionnée sur l'équipe Flutter, s'il vous plaît.

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

Salut i-Schuetz.
il y a une section de réponse.

C'est ce que j'ai dit dans ce long post. JSX a corrigé le "problème de spaghetti de HTML et XML" (code d'interface utilisateur illisible et compliqué). À mon avis, après avoir utilisé le flutter, c'est plus compliqué que JSX ou pire.

Au cours de ces années, j'ai vu des gens dire que Flutter ne pouvait pas capturer certains des avantages de React, par exemple, la véritable idée que tout est composé.

Pas sûr de suivre. Dans le texte que vous avez mis en surbrillance, l'utilisateur dit qu'il a trouvé JSX plus facile à apprendre parce qu'il était familier avec HTML et qu'il a une syntaxe similaire. Je ne vois pas en quoi cela justifie l'existence de JSX et encore moins une imitation de Flutter en aucune façon.

Je n'ai pas ajouté les réponses aux captures d'écran simplement parce que les images prendraient trop de place. Ils semblaient plutôt favorables à ce que j'ai posté, donc aussi redondants. J'ai posté des liens.

@JonathanSum est-ce que Flutter est plus compliqué que JSX, ou est-ce que Flutter est différent de _React_ et cela vous cause des frictions ? C'est plus verbeux dans certains cas, oui, et sans doute moins lisible sans balises de fermeture virtuelles dans un IDE, mais je ne sais pas trop comment l'utilisation de constructeurs est plus _compliquée_ que d'écrire un DSL de type XML et je ne suis toujours pas tout à fait sûr pourquoi tant de gens semblent penser que le DSL de type XML serait une solution miracle qui rendrait l'utilisation de Flutter plus facile à _comprendre_. Surtout si l'on considère que Flutter n'a pas d'antécédents avec les problèmes que React/JSX a été créé pour résoudre - React rend la manipulation DOM plus facile et plus propre, et c'est bien, mais qu'est-ce que cela a à voir exactement avec Flutter à nouveau ?

Au cours de ces années, j'ai vu des gens dire que Flutter ne pouvait pas capturer certains des avantages de React, par exemple, la véritable idée que tout est composé.

Sans toucher à l'idée que React a une "véritable" idée de tout ce qui est des composants que Flutter n'a pas, il y a aussi certains avantages de la conception de Flutter/Dart que React/JS ne peut pas capturer. Et vous pouvez dire la même chose (et vice versa) pour la plupart des SDK/frameworks/bibliothèques d'interface utilisateur décents. Incroyablement, différents projets sont en fait différents ; peut-être que les gens qui viennent à un projet pourraient être mieux servis s'ils ne s'attendent pas à ce que ce soit [insérer le projet qu'ils ont utilisé dans le passé]. 🙂

Il y a des idées intéressantes là-bas https://github.com/munificent/ui-as-code

Ce serait très probablement un changement radical, mais la proposition de liberté de paramètre m'a fait penser à quel point les méthodes de construction pourraient être beaucoup plus concises si Dart avait, par exemple , les arguments de méthode de Crystal spec .

Bien sûr, le compilateur de Crystal arriverait dernier dans une course contre une limace et une tortue, alors voilà 😅

J'accepte maintenant de ne pas ajouter JSX et de ne pas mettre de pression supplémentaire sur le flottement.

Mais en ce qui concerne les fléchettes, c'est beaucoup moins élégant que JS ou TS. Je me sens impuissant

Par exemple, la voie de développement de la technologie Microsoft UI est WinForm vers WPF, et maintenant dans Flutter, abandonnez WPF et utilisez WinForm à la place. En réponse aux plaintes des développeurs, l'équipe Flutter a travaillé dur pour implémenter la fenêtre visuelle et l'éditeur de propriétés de WinForm.

En tant que nouveau venu dans le flutter, je dois dire que cela devrait être dans la feuille de route. Si ce n'est pas jsx, une manière plus lisible pour l'homme de créer des widgets.

Je peux voir une fonction de rendu de classe de réaction et une image de la classe rendue et associée pour le moment.

Je peux voir un fichier fléchette et le contenu rendu et je prendrai 5-6 minutes pour comprendre comment cela fonctionne ...

Je peux créer une classe de réaction semi-complexe en 5 minutes dans un éditeur de texte brut, car c'est intuitif

Je ne peux pas faire ça en flottant. Sans l'auto-complétion, j'ai terminé en tant que développeur. Je n'aime pas être dépendant d'une extension pour développer quelque chose -.-

Toutefois. Il sera intéressant de voir comment les développeurs de fléchettes gèrent ce "problème". Dans Dart 2, ils l'ont rendu plus lisible. Je ne sais pas comment ils vont améliorer la lisibilité dans les fléchettes 3 -4 -5 . mais je pense qu'une refactorisation de la fonction de construction des composants sera nécessaire tôt ou tard.

ÉDITER:
Peu importe, je viens d'essayer à nouveau React Native, et je détestais jsx, le système d'accessoires, le fait que tout soit dynamique était à nouveau un concept vraiment effrayant, je suppose que c'est juste une opinion personnelle alors. Laisse flotter tel quel....

Ils ont demandé DSX, pas seulement parce qu'ils aiment JSX. Ils veulent Flutter.

La déclaration de l'interface utilisateur doit être séparée visuellement dans le code pour une meilleure lisibilité et prise en charge du code. Surtout dans les grandes équipes avec beaucoup de juniors/middles. Venant d'Adobe Flex, je peux dire que la lecture des déclarations d'interface utilisateur de Flutter réduit considérablement la productivité.
Sinon DSX (ce qui serait génial IMO) mais quelque chose devrait être fait avec la situation actuelle au moins au niveau IDE.
Tous les anciens cadres de développement d'interface utilisateur avaient cette fonctionnalité et nous devrions l'avoir aussi.

La déclaration de l'interface utilisateur doit être séparée visuellement dans le code pour une meilleure lisibilité et prise en charge du code.

et pour une meilleure intégration avec d'autres outils comme les 'gui builders' par exemple.

Venant d'Adobe Flex, je peux dire que la lecture des déclarations d'interface utilisateur de Flutter réduit considérablement la productivité.

Imaginez une déclaration d'interface utilisateur comme MXML avec la puissance de Flutters ! je ne peux que rêver !

Maintenant que nous avons le support du codegen, la meilleure façon d'intégrer quelque chose comme ça dans le produit est de créer un package qui le permet et de montrer qu'il est extrêmement populaire.

@Hixie y a-t-il un pointeur vers doc pour codegen?

Maintenant que nous avons le support du codegen, la meilleure façon d'intégrer quelque chose comme ça dans le produit est de créer un package qui le permet et de montrer qu'il est extrêmement populaire.

Il me semble que codegen est juste pour .dart -> .dart, le fichier d'entrée doit être un fichier .dart valide. Ce n'est pas très utile pour les fichiers .dsx car il s'agit d'un sur-ensemble de fléchettes. J'ai toujours besoin de support pour la compilation croisée dans .dart avec des cartes source comme des fonctionnalités de débogage, etc.

Veuillez jeter un coup d'œil à SwiftUI, qui a été publié hier. Cela semble être ce que Flutter devrait viser, au lieu d'un balisage de type React.

Les expressions de membre implicites de Swift seraient à elles seules si étonnantes

Je suis mitigé sur la syntaxe SwiftUI. C'est sûr, mais certains aspects semblent magiques.

Mais nous pouvons techniquement déjà avoir quelque chose de relativement similaire :

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

C'est un code de fléchette valide, où Column est _toujours_ une classe.

Voici un widget sans état le présentant :

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

C'est un passe-partout, mais un générateur de code peut aider, en particulier avec les membres de l'extension à venir.

Le seul problème avec cette approche est que nous perdons à la fois les constructeurs const (puisqu'elle utilise une fonction pour spécifier les enfants) et instancions la classe widget _twice_.

Si cette syntaxe est souhaitée, idéalement au lieu d'une méthode call , elle doit être implémentée à l'aide du curry de constructeur.

@rrousselGit Je suis curieux de savoir quels aspects de SwiftUI vous semblent magiques - cela me semble être une extension assez simple de la syntaxe Swift.

Sur leur exemple de code d' ici :

• Content est mutable ? Cela signifie-t-il qu'ils ont un magasin Mobx / Vue intégré ?
• C'est quoi ce @State ?
• Pourquoi body est-il une variable ? C'est un getter ? Si oui, quand le getter est-il appelé à nouveau ?
• body fait-il partie d'une interface, ou de nombreuses variables similaires à l'intérieur Content ?
• Qu'est-ce que ces item in font _exactement_ ? Pourquoi l'opérande droit de in n'est-il pas itérable, mais le "résultat" à la place ?
• Pourquoi le Image est-il aligné à gauche du titre/sous-titre alors qu'il n'y a pas HStack ?

Je ne me souviens pas avec certitude, mais je suis presque sûr que je n'avais pas de telles questions lorsque j'ai choisi Flutter.

@rrousselGit C'est peut-être à cause de vos antécédents, pas parce que la syntaxe ou la sémantique de Flutter est intrinsèquement évidente (j'ai rencontré beaucoup de gens qui étaient assez perplexes). Et les points que vous avez soulevés semblent être une jonction étrange de suranalyse d'un extrait de code de 14 lignes pour les défauts tout en ne connaissant pas réellement la langue dans laquelle il est écrit.

• Ce n'est pas vraiment modifiable (au sens Dart ou JS) cependant? C'est une structure. De plus, les magasins de style MobX/Vue (c'est-à-dire le support linguistique assez limité) ne sont pas le seul moyen de gérer la mutabilité

• @State est un attribut, autrement connu comme une annotation dans certains langages (par exemple Dart), autrement connu comme une chose très courante dans le code Swift. Si vous voulez dire ce qu'il fait, même sans regarder la documentation, il marque très probablement une propriété comme un état qui changera avec le temps.

• body est une propriété calculée, ce qui est évident pour les développeurs Swift. En ce qui concerne le moment où il est recalculé, est-ce que Widget build(BuildContext context) vous dit aussi quand il est appelé à nouveau ?

• Content (encore une fois assez clairement pour les développeurs Swift) étend/implémente View , où vous chercheriez des réponses à votre question (il a en fait une très belle page de référence API).

• C'est à peu près "pourquoi le mot-clé dans cette langue n'est-il pas la même chose que le mot-clé dans la langue que j'utilise", pas quelque chose de particulièrement "magique". Le mot-clé in ici n'est pas la même chose qu'une construction for...in - il indique que le corps d'une fermeture est sur le point de commencer. { item in ... } est un bloc fonctionnel passé au constructeur List ; a ListView 's itemBuilder , si vous voulez.

• Demandez-vous légitimement pourquoi une vue a ses propres règles de mise en page encapsulées ?

Sur SwiftUI :

1-Agréable à voir état déclaré dans la vue et non comme appendice latéral.

2-Belles méthodes individuelles pour définir les choses au lieu de devoir tout transmettre au constructeur (les méthodes permettent aux actions de prendre effet au lieu de simplement transmettre des données).

3-Très agréable de voir des graphiques vectoriels déclaratifs mélangés à tout ce qui est déclaratif (comme je l'ai suggéré dans le passé avec des widgets SVG déclaratifs) !!!
https://developer.apple.com/tutorials/swiftui/drawing-paths-and-shapes

4-Constructions d'animation et de transition très simples
https://developer.apple.com/tutorials/swiftui/animating-views-and-transitions

Outils de conception 5-Drag & Drop synchronisés avec l'éditeur de code dans les deux sens.

Il y a des verrues comme tout le reste mais je me concentre plutôt sur ce qu'ils ont très bien fait.

Ces "questions" existent juste pour mettre en évidence des points potentiellement déroutants. Ce ne sont pas des _questions réelles_.

C'est peut-être à cause de ton passé

Probable. Je ne dis pas que leur approche est mauvaise ou quoi que ce soit. Je dis que cela ne me semblait pas naturel comme c'était le cas avec Flutter.
Les widgets Flutter n'utilisent presque aucune "fonctionnalité de langage sophistiqué" et peuvent être implémentés dans presque toutes les langues (bien que le récent if/for pour les collections change cela).
Alors que leur vitrine de SwiftUI utilise largement les fonctionnalités spécifiques de Swift.

En ce qui concerne le moment où il est recalculé, Widget build (contexte BuildContext) vous indique-t-il également de manière inhérente quand il est à nouveau appelé ?

Mon point ici est le manque de relation entre State et l'acte de recalculer body .
React et Flutter sont très explicites à ce sujet : setState.
Vue/Mobx sont "magiques", utilisant la même fonctionnalité @State .

C'est vraiment bien, mais c'est un schéma différent.

Demandez-vous légitimement pourquoi une vue a ses propres règles de mise en page encapsulées ?

Non, c'est plus un "explicite" vs "implicite".
Il semble qu'ils se soient vraiment concentrés sur "faire le plus possible avec le moins de code possible", même si cela cache une partie de la logique (dans ce cas, la logique ltr vs rtl )

Flutter vous demandera d'utiliser un Row .

Flutter utilise et s'appuie sur de nombreuses "fonctionnalités linguistiques sophistiquées" (lire : fonctionnalités linguistiques auxquelles le locuteur n'est pas habitué et / ou avec lesquelles il n'est pas d'accord). Juste au sommet de ma tête, les constructeurs constants (et le style de Dart pour nommer les constructeurs en général), la surcharge d'opérateurs, les classes étant des interfaces implicites, @covariant et les mixins sont des fonctionnalités qui susciteraient des réactions de confusion à l'étiquetage pur et simple comme une odeur de code en fonction de l'expérience d'un développeur. Je pourrais probablement proposer une liste plus longue compte tenu d'une heure de réflexion. Et ce n'est pas plus une mise en accusation de Flutter que c'est une mise en accusation de SwiftUI - je ne vois pas pourquoi on penserait que c'est une vertu d'écrire un logiciel dans un langage particulier pour qu'il puisse être écrit de la même manière dans n'importe quel langage - quel est le point de langues différentes si nous sommes censés prétendre que les différences entre elles n'existent pas ?

De plus, je ne suis absolument pas d'accord avec le fait que setState ou @State soit explicite quant à sa relation avec l'acte de reconstruction d'une vue. Dans les deux cas, on vous dit simplement que si vous modifiez quelque chose qui a été marqué comme état, le framework déterminera ce qu'il faut construire. Dans les deux cas, le développeur n'a toujours aucun contrôle explicite sur ce qui se passe ou quand exactement. Vous trouvez un appel de fonction plus familier, les personnes qui travaillent dans d'autres langues trouvent les décorateurs plus familiers. Mais appeler une fonction ne rend pas les choses magiques.

Flutter vous demanderait d'utiliser un Row

Je suppose que vous n'avez jamais utilisé ListTile , qui a le même comportement que celui montré ici mais avec des paramètres nommés ? Devrions-nous également demander pourquoi un Scaffold place "magiquement" un bouton de menu à gauche de votre barre d'application alors que vous ne le lui avez pas demandé ?

La différence est que, dans l'état actuel, Dart est très similaire à la plupart des langues courantes.

C'est important.
La question "Ai-je besoin d'apprendre Dart ou puis-je simplement commencer à apprendre Flutter ?" revient assez souvent.
Pour le moment, la réponse est "apprenez simplement Flutter. Vous pouvez écrire une fléchette efficace après une seule journée".
Ce n'est pas garanti pour toujours, mais je pense que c'est l'une des forces de Flutter.

Le reste de la discussion est un peu hors sujet. Si vous le souhaitez, nous pouvons continuer cette partie par courrier (mon courrier github fonctionne).

Pourquoi n'est-il pas verrouillé ? Cela évolue déjà mal, et c'est exactement la même chose qu'un problème verrouillé plus tôt.

J'en ai fait un simple ici :
https://github.com/danialdezfouli/flutterjsx
https://www.npmjs.com/package/flutterjsx
https://www.youtube.com/watch?v=Oj1JMSurphA

Ce fil a été automatiquement verrouillé puisqu'il n'y a eu aucune activité récente après sa fermeture. Si vous rencontrez toujours un problème similaire, veuillez ouvrir un nouveau bogue, y compris la sortie de flutter doctor -v et une reproduction minimale du problème.