cc @lukechurch

@cbazza Pouvez-vous expliquer pourquoi vous voulez cela ? Peut-être montrer un exemple de ce à quoi cela ressemblerait par rapport à aujourd'hui ?

Ok, donc l'exemple "Basic widgets" sur ' https://flutter.io/widgets-intro/#basic -widgets' ressemblerait à ceci :

import 'package:flutter/material.dart';

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

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

  final Widget title;

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

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

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

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

Que diriez-vous de cette syntaxe ? :

import 'package:flutter/material.dart';

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

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

  final Widget title;

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

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

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

Huumm, une petite amélioration mais pas si bon...
Voici les choses qui sont accomplies en utilisant XML :
(1) Plus de trucs "enfant" et "enfants"
(2) facile à manipuler pour les outils tiers (parser, analyser et régénérer)
(3) notez que la commutation entre le balisage et la programmation est facilement détectée. Je veux dire à l'intérieur de XML, vous avez '{}' pour délimiter le code et dans le code, vous avez ' Séparez également tous les éléments de « style » de la structure principale.
Je sais que cela approuve fondamentalement la voie de React, mais vous êtes à mi-chemin de toute façon;)

cc @kasperl

(1) Plus de trucs "enfant" et "enfants"

Je ne comprends pas vraiment pourquoi c'est souhaitable. "enfant" et "enfants" ne sont pas spéciaux. Considérez ListTile par exemple. Comment feriez-vous celui-là ? Pourquoi "icon" dans IconButton, ou "home" dans MaterialApp, est-il quelque chose auquel vous voulez donner un nom, mais pas "child" dans Expanded ? Tous les trois ne sont que des arguments arbitraires qui prennent des objets Widget. Il n'y a rien de magique entre "enfant" et "maison".

(2) facile à manipuler pour les outils tiers (parser, analyser et régénérer)

Vous pouvez analyser, analyser et régénérer le code Dart. Mais je suis d'accord que nous devrions rendre cela plus facile. Espérons que dans les années à venir, l'équipe Dart fournira de meilleures API pour cela.

(3) notez que la commutation entre le balisage et la programmation est facilement détectée.

Pourquoi est-ce souhaitable ? Je veux dire, pourquoi tout cela compterait-il comme "programmation" ? Ce ne sont que des expressions.

Je veux dire à l'intérieur de XML, vous avez '{}' pour délimiter le code et dans le code, vous avez '

Je ne comprends pas vraiment la distinction.

Séparez également tous les éléments de « style » de la structure principale.

Vous pouvez le faire aujourd'hui dans Flutter si vous le voulez vraiment, il suffit de mettre le style dans une variable comme vous l'avez fait dans le cas XML.

Je ne comprends pas vraiment pourquoi c'est souhaitable. "enfant" et "enfants" ne sont pas spéciaux. Considérez ListTile par exemple. Comment feriez-vous celui-là ? Pourquoi "icon" dans IconButton, ou "home" dans MaterialApp, est-il quelque chose auquel vous voulez donner un nom, mais pas "child" dans Expanded ? Tous les trois ne sont que des arguments arbitraires qui prennent des objets Widget. Il n'y a rien de magique entre "enfant" et "maison".

Moins passe-partout, vous n'avez pas besoin de le dire car il est hérité dans la structure.

Pourquoi est-ce souhaitable ? Je veux dire, pourquoi tout cela compterait-il comme "programmation" ? Ce ne sont que des expressions.

Il est lié à (2) car il facilite la vie des fabricants d'outils, en particulier des constructeurs d'interfaces graphiques, car ils n'ont pas besoin d'analyser complètement Dart ; mais cela facilite également la lecture du code.

Je ne comprends pas vraiment la distinction.

Le format de XML est très simple, donc quand vous voyez '{}', vous savez qu'il calcule une expression dans Dart. Pareil pour le contraire, lors de la lecture du code de fléchette et que vous voyez ') vous savez qu'une hiérarchie d'objets est créée à partir du balisage XML.

Également dans le processeur XML final, j'éviterais de transmettre des objets aux attributs des parents et de créer à la place des balises enfants comme ci-dessous :

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

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

Moins passe-partout, vous n'avez pas besoin de le dire car il est hérité dans la structure.

Mais pourquoi seulement pour certaines propriétés ? Et comment gérez-vous les cas où il y a deux emplacements enfants, comme ListItem ? La syntaxe XML-ish ne semble tout simplement pas très bien gérer cela.

De plus, je ne suis pas vraiment sûr que ce soit moins passe-partout.

Comparer:

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

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

Il n'est pas du tout clair pour moi que la syntaxe XML-ish soit plus propre ou moins passe-partout. Il y a beaucoup plus de ponctuation et une certaine duplication de contenu (par exemple dans les balises fermantes). Et vous avez dû ajouter des noms, donc bien sûr, vous perdez "enfant", mais vous gagnez "nom" sur Icon.

De plus, avec XML, comment indiquez-vous clairement que Row peut prendre zéro, un ou plusieurs enfants, alors que Center doit avoir exactement un enfant ? Que se passerait-il si quelqu'un faisait ça ? :

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

Il est lié à (2) car il facilite la vie des fabricants d'outils, en particulier des constructeurs d'interfaces graphiques, car ils n'ont pas besoin d'analyser complètement Dart ;

Ils n'auraient pas besoin d'analyser complètement Dart si nous avions une API d'analyse Dart non plus, n'est-ce pas ? Je veux dire, vous analyseriez ce que vous voulez analyser et laisseriez le reste. De plus, je ne suis pas sûr que ce soit réellement plus facile à analyser, car ce n'est pas réellement du XML; voir ci-dessous.

mais cela facilite également la lecture du code.

Je ne suis pas du tout convaincu que la version XMLy ici soit plus facile à lire. Une fois que vous avez lu quelques fonctions de construction, vous vous habituez rapidement à la syntaxe des constructeurs imbriqués.

Le format de XML est très simple, donc quand vous voyez '{}', vous savez qu'il calcule une expression dans Dart.

Ce n'est pas réellement du XML, n'est-ce pas ? C'est une variante de XML. Existe-t-il des règles d'analyse bien définies pour cela? Par exemple, est-ce valable ?

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

Comment sait-il que le premier "}" n'est pas la fin de l'expression d'attribut, sans analyser Dart ?

Pareil pour le contraire, lors de la lecture du code de fléchette et que vous voyez ') vous savez qu'une hiérarchie d'objets est créée à partir du balisage XML.

Vous le savez aujourd'hui lorsque vous voyez également le mot-clé new , n'est-ce pas ? Ou bien dans la proposition de nouveau moins de balisage ci-dessus lorsque vous voyez un mot en majuscule. Est-ce vraiment un avantage de XML, ou êtes-vous plus familiarisé avec XML qu'avec Dart ?

Également dans le processeur XML final, j'éviterais de transmettre des objets aux attributs des parents et de créer à la place des balises enfants comme ci-dessous :

Je ne comprends vraiment pas ce que vous proposez ici. Ce n'est pas du tout du XML bien formé pour autant que je sache. Pouvez-vous préciser exactement quelle est la syntaxe que vous proposez et comment elle fonctionne ? Par exemple, le constructeur "Text" semble avoir disparu ; comment le processeur sait-il que

Écoute, tu mélanges tout ce que je dis et cette conversation ne mène nulle part. En termes juridiques, vous « harcelez le témoin ».

Si vous êtes vraiment intéressé à savoir pourquoi JSX est à la mode, recherchez simplement sur Google "tutoriel de réaction" et notez que depuis 2 ans, tous les articles sur React utilisent JSX. La manière originale de créer des hiérarchies de composants dans React (qui équivaut à la manière actuelle dans Flutter) n'est plus jamais mentionnée car JSX est devenu la méthode préférée (meilleure pratique).

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

Une autre chose intéressante est que Typescript a également adopté JSX :
https://www.typescriptlang.org/docs/handbook/jsx.html

Vous n'avez pas compris que l'analyse XML (avec du code supplémentaire pour ignorer '{}' correctement) est d'un ordre de grandeur plus simple que l'analyse complète d'un langage de programmation comme Dart. C'est un fait. Vous supposez que les constructeurs d'outils utiliseront Dart pour leur développement, ce n'est pas le cas, Intellij utilise très probablement Kotlin et Java sur leurs IDE qui prennent en charge Dart (ils sont un cas particulier car ils se spécialisent dans l'analyse de langage; tout le monde aura du mal à pleinement analyser Dart depuis une autre langue).

Ce que j'aime dans le fait de mettre XML dans un autre langage, c'est qu'il fournit une séparation cognitive entre les deux car XML est très distinct des langages de programmation. En faisant simplement défiler le fichier source, vous pouvez facilement voir ce qu'est le code et ce qu'est le balisage déclaratif. Impossible d'accomplir cela avec un code de fléchettes prétendant être un balisage.

Arrêtez de pinailler sur des choses qui ne sont pas entièrement spécifiées. Tous vos doutes ont répondu car il suffit d'en savoir plus sur la façon dont cela a été géré dans JSX. Je n'ai juste pas le temps pour ça ici.

Mes excuses si j'ai l'air défensif ou agressif. C'est un sujet qui a été soulevé plusieurs fois, mais je n'avais jamais eu quelqu'un qui était prêt à plaider l'affaire auparavant, alors je trouvais cette conversation très utile pour m'apprendre quel était le raisonnement derrière la demande. S'il vous plaît, ne prenez pas mon ton argumentatif comme dédaigneux, je suis très intéressé par votre contribution ici.

S'il vous plaît, ne vous sentez pas obligé de répondre. Je commente ici pour qu'il y ait de la transparence concernant les problèmes que nous aurions à résoudre avant de pouvoir prendre une décision ou concevoir dans un sens ou dans l'autre. Il s'agit essentiellement d'un dialogue socratique. Votre participation est la bienvenue, mais vous ne devez certainement pas penser qu'il est de votre responsabilité de défendre votre proposition.

Je n'ai aucun doute que JSX est "chaud". Dans React, la syntaxe non-JSX est bien pire que la syntaxe alternative proposée dans ce numéro (celle qui ressemble à notre code actuel mais sans les mots clés "new" et "const"). Ce que j'essaie de comprendre, c'est si les mêmes raisons pour lesquelles JSX est "chaud" dans React s'appliquent à Flutter.

En ce qui concerne TypeScript faisant JSX, en 2012, j'ai été impliqué dans des efforts pour spécifier E4H , et même avant cela, il y avait E4X . Les deux efforts sont morts. Il est donc important pour moi que nous comprenions exactement ce que les gens aiment à propos de JSX par rapport aux autres syntaxes.

Analyser XML n'est pas facile, analyser une sorte de XML-mais-avec-des-accolades-en quelque sorte n'est pas facile non plus. Parser une sorte de XML-mais-avec-des-accolades-en quelque sorte-qui-est-intégré-dans-une-autre-langue est encore moins facile. Cependant, la facilité d'implémentation n'est probablement pas un gros problème car elle sera implémentée une ou deux fois, puis la bibliothèque qui le fait sera réutilisée. (J'ai été fortement impliqué dans l'écriture des spécifications pour l'analyse HTML et j'ai été impliqué dans un travail similaire pour XML, et j'ai implémenté un analyseur pour Dart, donc j'ai une assez bonne idée de la difficulté d'analyser les langages de balisage par rapport aux langages de programmation en fait est.)

Ce que j'aime dans le fait de mettre XML dans un autre langage, c'est qu'il fournit une séparation cognitive entre les deux car XML est très distinct des langages de programmation. En faisant simplement défiler le fichier source, vous pouvez facilement voir ce qu'est le code et ce qu'est le balisage déclaratif. Impossible d'accomplir cela avec un code de fléchettes prétendant être un balisage.

Mais pourquoi est-il avantageux de pouvoir le faire ?

C'est assez évident lorsque vous faites défiler les applications Flutter où se trouvent les fonctions de construction (ce sont les expressions imbriquées géantes). Qu'y a-t-il dans le "balisage déclaratif" qu'il est important de séparer du "code" ?

Arrêtez de pinailler sur des choses qui ne sont pas entièrement spécifiées. Tous vos doutes ont répondu car il suffit d'en savoir plus sur la façon dont cela a été géré dans JSX. Je n'ai juste pas le temps pour ça ici.

Autant que je sache, JSX ne gère pas les choses que je demandais. Par exemple, React n'a pas le concept d'emplacements enfants. La chose la plus proche que j'ai pu trouver est quelque chose qu'ils font en revenant à JS puis à JSX à l'intérieur, vous devez donc pouvoir analyser à la fois le langage de programmation et le langage de balisage.

Ce que j'essaie de comprendre, c'est si les mêmes raisons pour lesquelles JSX est "chaud" dans React s'appliquent à Flutter.

Oui, exactement la même chose s'applique ici. La méthode actuelle vous semble bonne car c'est la seule option que vous avez. Donnez aux gens une deuxième option et la même chose se produira.

Que E4X soit mort ou non n'est pas pertinent car rien ne vit éternellement. J'ai beaucoup utilisé ActionScript avec E4X et j'ai pensé qu'Adobe avait fait un excellent travail là-bas. D'une certaine manière, Flutter n'est qu'une version plus récente d'Adobe Flash avec les applications Flex.

(J'ai été fortement impliqué dans l'écriture des spécifications pour l'analyse HTML et j'ai été impliqué dans un travail similaire pour XML, et j'ai implémenté un analyseur pour Dart, donc j'ai une assez bonne idée de la difficulté d'analyser les langages de balisage par rapport aux langages de programmation en fait est.)

Idéal pour que vous sachiez que l'analyse d'un langage de balisage est triviale par rapport à l'analyse d'un langage de programmation impératif.

Mais pourquoi est-il avantageux de pouvoir le faire ?

La lisibilité et la simplicité du code, qui à leur tour entraînent de nombreux autres avantages.

C'est assez évident lorsque vous faites défiler les applications Flutter où se trouvent les fonctions de construction (ce sont les expressions imbriquées géantes). Qu'y a-t-il dans le "balisage déclaratif" qu'il est important de séparer du "code" ?

Sur vos expressions imbriquées géantes pouvez-vous facilement voir la structure ? cette structure peut-elle être facilement manipulée par d'autres outils tels que les constructeurs d'interfaces graphiques de manière interchangeable? Je veux dire, comme Adobe Flex Builder le faisait, faites glisser et déposez des widgets, connectez-les sur l'interface utilisateur, puis passez en mode code et modifiez simplement tout ce que vous voulez, puis revenez en mode graphique et continuez à manipuler les widgets. Vous ne pouvez pas le faire facilement lorsque le programmeur entre dans vos "expressions imbriquées géantes" et écrit un code de fléchette valide qui ne suit pas la structure attendue par l'éditeur d'interface graphique. Avec une structure XML fixe qui n'est pas un problème.

Autant que je sache, JSX ne gère pas les choses que je demandais. Par exemple, React n'a pas le concept d'emplacements enfants

Il gère très bien, vous ne savez pas comment le faire. Donc, à l'avenir, mettez simplement l'exemple en question ici et je vous fournirai ce que je pense que la version JSX devrait être.

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

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

Il semble plus long que la version fléchette mais j'aurais pu tout placer dans le même nombre de lignes. La chose est qu'un IDE/éditeur peut fournir '+' & '-' pour développer et réduire ces nœuds XML de toute façon.

Rendez Flutter familier aux développeurs de React et vous avez une chance d'attirer un groupe de nouveaux utilisateurs vers Flutter.

Que E4X soit mort ou non n'est pas pertinent car rien ne vit éternellement.

Qu'il soit mort n'est pas le problème, c'est pourquoi il est mort. Est-il mort parce qu'il n'a pas fourni une solution que les gens voulaient? Est-il mort à cause de problèmes de mise en œuvre ? Est-il mort à cause de problèmes de brevet ? Était-ce trop tôt ? Trop tard? Je pense qu'il est important de tirer des leçons des expériences passées. Pourquoi E4X et E4H ont-ils échoué là où JSX a réussi ?

Ce que je trouve intéressant, c'est que les personnes qui découvrent Flutter demandent souvent deux choses : un langage de balisage et des GIF animés. Puis trois mois plus tard, ils demandent toujours des GIF animés, mais pas un langage de balisage. Il se peut que cela soit dû au fait que le langage de balisage n'est plus nécessaire une fois que vous avez l'habitude d'écrire des méthodes de construction dans Dart. Il se peut qu'ils veuillent toujours un langage de balisage mais qu'ils aient contourné l'omission et qu'ils ne pensent donc plus à demander. Cela vaut la peine de déterminer lequel, car sinon nous risquons de consacrer des efforts à quelque chose qui est le mauvais choix (dans les deux sens).

Sur vos expressions imbriquées géantes pouvez-vous facilement voir la structure ?

Oui, au moins aussi facilement qu'avec XML. Personnellement, je trouve que XML est très verbeux et qu'il obscurcit la structure. Mais je pense que c'est plus ce à quoi vous êtes habitué.

(Nous expérimentons également des IDE qui mettent des commentaires virtuels de "balise de fermeture" pour vous afin que vous puissiez voir la structure sans avoir à l'écrire.)

Idéal pour que vous sachiez que l'analyse d'un langage de balisage est triviale par rapport à l'analyse d'un langage de programmation impératif.

Mon expérience est que déclaratif vs impératif n'est pas la distinction qui compte lorsqu'il s'agit de déterminer la facilité d'analyse d'un langage. (Par exemple, HTML est "déclaratif", mais il peut être parmi les langages les plus compliqués à analyser que j'ai jamais traités.)

La lisibilité et la simplicité du code, qui à leur tour entraînent de nombreux autres avantages.

Si c'est le principal avantage, c'est quelque chose que nous pouvons tester. Nous pourrions prendre un mélange d'ingénieurs habitués à écrire du HTML, React, du code iOS, du code Android, Flutter, des applications en ligne de commande, etc., et leur présenter chacun différentes syntaxes, et leur demander de décrire ce qu'ils pensent du l'interface utilisateur résultante ressemblerait. Nous pouvons alors mesurer quelle syntaxe obtient les meilleurs résultats. @InMatrix est-ce quelque chose que nous pourrions examiner une fois le travail d'animation terminé, peut-être?

cette structure peut-elle être facilement manipulée par d'autres outils tels que les constructeurs d'interfaces graphiques de manière interchangeable?

Oui, en principe du moins. Il devrait être relativement simple de convertir mécaniquement des expressions Dart en XML ou JSON ou tout autre langage structuré que l'on pourrait utiliser. C'est juste une question de conversion de la syntaxe, l'information réelle est la même. Personnellement, je ne le convertirais pas dans une syntaxe différente si je faisais un éditeur graphique, je l'analyserais simplement dans une structure de données en mémoire directement à partir de Dart.

Vous ne pouvez pas le faire facilement lorsque le programmeur entre dans vos "expressions imbriquées géantes" et écrit un code de fléchette valide qui ne suit pas la structure attendue par l'éditeur d'interface graphique. Avec une structure XML fixe qui n'est pas un problème.

Le fait est que vous pouvez mettre exactement le même "tout code de fléchette valide" dans la structure XML que dans l'expression Dart. Ils sont littéralement interchangeables mécaniquement. Donc, je ne vois pas vraiment comment l'utilisation de XML aide à cela en particulier. Par exemple, comment transformeriez-vous cela en XML ? :

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

Il gère très bien, vous ne savez pas comment le faire.

Je voulais dire spécifiquement JSX. Je suis d'accord que la syntaxe que vous proposez serait une manière parfaitement valable d'aborder le problème.

J'ai travaillé sur le SDK Flex d'Adobe, qui combinait le balisage XML et ActionScript, pendant les deux dernières années que le produit existait chez Adobe. Je comprends l'attrait du balisage pour définir les interfaces utilisateur, mais je me souviens également de certains inconvénients :

• Les visuels des applications Flex peuvent être définis en termes de balisage et de code. Si je me souviens bien, le code avait tendance à dominer dans les grandes applications du monde réel. La lisibilité n'est pas nécessairement un avantage pour les applications définies comme des hybrides complexes de balisage et de code.
• L'IDE "Flex Builder" devait prendre en charge les applications définies par le balisage et le code. Cela a rendu l'IDE difficile à construire et à maintenir. Les développeurs avaient tendance à le considérer comme un outil ActionScript.
• L'évolution et la maintenance du "compilateur" XML représentaient une charge importante qui occupait une équipe d'ingénieurs à plein temps. Garder le compilateur et la boîte à outils en phase a ralenti l'évolution du SDK global.

Cela fait des années et je ne me souviens plus de tous les détails. Cependant, mon impression générale est que la définition des interfaces utilisateur avec une combinaison de balisage et de code est au mieux un sac mélangé.

Qu'il soit mort n'est pas le problème, c'est pourquoi il est mort. Est-il mort parce qu'il n'a pas fourni une solution que les gens voulaient ? Est-il mort à cause de problèmes de mise en œuvre ? Est-il mort à cause de problèmes de brevet ? Était-ce trop tôt ? Trop tard? Je pense qu'il est important de tirer des leçons des expériences passées. Pourquoi E4X et E4H ont-ils échoué là où JSX a réussi ?

Il est mort parce que E4X n'a ​​été implémenté que dans ActionScript qui n'était utilisé que dans Adobe Flash/Flex et Adobe a tué le projet. Au lieu de cela, Adobe a changé de direction vers des normes ouvertes où il n'y a pas de fournisseur de source unique avec possibilité de verrouillage et d'implosion de l'écosystème.

Ce que je trouve intéressant, c'est que les personnes qui découvrent Flutter demandent souvent deux choses : un langage de balisage et des GIF animés. Puis trois mois plus tard, ils demandent toujours des GIF animés, mais pas un langage de balisage. Il se peut que cela soit dû au fait que le langage de balisage n'est plus nécessaire une fois que vous avez l'habitude d'écrire des méthodes de construction dans Dart. Il se peut qu'ils veuillent toujours un langage de balisage mais qu'ils aient contourné l'omission et qu'ils ne pensent donc plus à demander. Cela vaut la peine de déterminer lequel, car sinon nous risquons de consacrer des efforts à quelque chose qui est le mauvais choix (dans les deux sens).

Bon, si je vous demandais 2 choses et que vous n'avez fait ni l'une ni l'autre en 3 mois et qu'il existe une alternative à la première chose, je ne vous demanderais également que ce qui est totalement impossible à faire compte tenu de votre réactivité et de vos performances de livraison précédentes.

(Nous expérimentons également des IDE qui mettent des commentaires virtuels de "balise de fermeture" pour vous afin que vous puissiez voir la structure sans avoir à l'écrire.)

Un peu drôle, mais c'est comme si mettre la balise de fermeture XML que vous avez mentionnée précédemment était trop verbeuse.

Si c'est le principal avantage, c'est quelque chose que nous pouvons tester. Nous pourrions prendre un mélange d'ingénieurs habitués à écrire du HTML, React, du code iOS, du code Android, Flutter, des applications en ligne de commande, etc., et leur présenter chacun différentes syntaxes, et leur demander de décrire ce qu'ils pensent du l'interface utilisateur résultante ressemblerait. Nous pouvons alors mesurer quelle syntaxe obtient les meilleurs résultats. @InMatrix est-ce quelque chose que nous pourrions examiner une fois le travail d'animation terminé, peut-être?

Bien sûr, vous pouvez le faire, je suis sûr que vous découvrirez que "Une fois que vous avez réagi (avec JSX), vous ne revenez tout simplement pas en arrière". Interrogez les développeurs expérimentés de React et demandez-leur s'ils pensent que JSX est mauvais et que cela n'aurait jamais dû être fait. Montrez votre chemin et demandez-leur s'ils veulent remplacer JSX par ce que vous avez. Avant de faire cela, fermez les portes et verrouillez l'endroit car ces développeurs vont juste saisir leurs affaires et sprinter vers la sortie la plus proche.

Le fait est que vous pouvez mettre exactement le même "tout code de fléchette valide" dans la structure XML que dans l'expression Dart.

Bien sûr, mais pour les constructeurs d'interfaces graphiques, il ne s'agit que d'un bloc d'octets qui n'a pas besoin d'être touché et peut être facilement ignoré. Rendre l'interchangeabilité conception/code pratiquement possible plutôt qu'en principe.

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

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

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

J'ai utilisé Adobe Flex Builder de manière extensive...

Les développeurs avaient tendance à le considérer comme un outil ActionScript.

Oui, mais je suis souvent passé du mode conception au mode code et vice-versa.
À partir d'un écran, j'irais en mode conception et j'utiliserais le glisser-déposer pour mettre en page les widgets et générer le premier écran statique. Ensuite, j'ajoutais du code et des données statiques pour remplir l'écran afin de pouvoir montrer aux gens quelque chose en cours d'exécution qui ressemblait à des éléments prêts pour la production. La productivité était incroyable. Au fur et à mesure que le développement progressait, j'ai connecté le front-end au back-end et la quantité de code ActionScript a augmenté et oui, il a dominé le code dans son ensemble, mais même à l'approche de la sortie, j'ai souvent utilisé la vue de conception pour modifier l'interface utilisateur sans avoir à creuser code.

Cependant, mon impression générale est que la définition des interfaces utilisateur avec une combinaison de balisage et de code est au mieux un sac mélangé.

Pas dans le monde d'aujourd'hui. Les langages impératifs ont évolué dans la philosophie de Python et sont parfaits pour le développement. Les techniques déclaratives avec balisage intégré (XML) sont devenues courantes avec l'avènement de React ; et JSON est devenu le format de données textuel préféré.

E4X n'a ​​été implémenté qu'en ActionScript

E4X était une norme ECMA. Mozilla l'a expédié pendant un certain temps, mais l'a ensuite supprimé (une décision très inhabituelle pour un fournisseur de navigateur). Les autres fournisseurs de navigateurs n'ont jamais voulu l'implémenter. (Ils ont cependant implémenté d'autres nouvelles fonctionnalités ECMA.) Avec E4H, les éditeurs de navigateurs n'ont jamais été intéressés à l'implémenter (bien qu'ils aient implémenté beaucoup d'autres choses que j'ai aidé à inventer).

Bon, si je vous demandais 2 choses et que vous n'avez fait ni l'une ni l'autre en 3 mois et qu'il existe une alternative à la première chose, je vous demanderais également uniquement ce qui est totalement impossible à faire compte tenu de votre réactivité et de vos performances de livraison précédentes.

C'est une théorie possible. Cependant, les gens ont tendance à demander beaucoup d'autres choses, et beaucoup de choses qu'ils demandent sont mises en œuvre, et il existe également des solutions de contournement pour les GIF animés, donc je ne suis pas sûr que cela explique complètement la situation.

Un peu drôle, mais c'est comme si mettre la balise de fermeture XML que vous avez mentionnée précédemment était trop verbeuse.

En effet. Il s'agit d'une fonctionnalité IDE facultative, et que vous n'avez pas à écrire dans le code, ce qui fait une grande différence pour savoir si la verbosité est un problème, cependant.

... ListView ...

Comment un éditeur graphique gérerait-il ce balisage ? Je ne comprends pas vraiment comment visualiser l'interface utilisateur pour cela.

Cela peut être un contre-argument à cette demande, et/ou peut-être une idée à garder à l'esprit si vous voulez un balisage. J'ai le sentiment que l'ajout de balisage crée des défis avec GWT. Je détesterais voir une autre API passer.

J'ai vu quelques autres frameworks passer par cette transition concernant la construction de l'interface utilisateur. Un balisage comme celui-ci fonctionne très bien pour l'outillage, dans la mesure où il est paradisiaque pour les développeurs IDE. Il est plus facile de séparer les responsabilités de qui fait quoi. Même si je pense qu'on peut faire mieux.

GWT a commencé de cette façon, en créant des interfaces utilisateur avec Java. Puis vint UiBinder, où vous pouviez créer l'interface utilisateur dans le balisage XML, avec une spécification. Ensuite, l'outil, Eclipse Plugin, a pu générer des interfaces utilisateur dans le balisage xml. Android le fait aussi, pas besoin d'insister. Donc, ce que j'ai vu se produire, le balisage fonctionne très bien pour les développeurs UI IDE. Mais vraiment, le balisage est un énorme investissement en temps et en outils de complexité supplémentaire pour le transformer en programme réel. Et l'outillage est toujours le dernier à venir. Ainsi, en attendant, alors que tout cela se manifeste dans la réalité, il y a deux mondes. Deux façons intéressantes de tout faire. Un dans la langue par défaut et un dans le balisage. Je soutiens donc GWT aujourd'hui. Lorsque j'écris de la documentation, je dois l'écrire deux fois, une fois pour Java et une fois pour UiBinder XML Markup. Donc la vraie question, si vous voulez emprunter la voie du balisage, je pense qu'il faut se poser la question, c'est la complexité supplémentaire qui vaut le déplacement !

Je pense que JSX vise à résoudre d'autres problèmes où vous souhaitez mélanger ce que vous faites avec HTML et javascript. Il ne semble vraiment pas que la complexité supplémentaire de la spécification de balisage réponde aux besoins d'écriture d'interface utilisateur avec balisage. Surtout lorsque vous n'avez pas vraiment de langage de balisage de document comme cible. Du moins pas pour l'utilisateur quotidien.

Sur une note positive. J'aime travailler sur l'outillage. Je peux donc voir qu'un langage de balisage est très utile. Il est beaucoup plus facile d'écrire et de modifier AST lorsque vous utilisez le balisage.

Mais encore une fois, si vous avez suffisamment d'esprit au travail, peu importe ce que vous faites. En fin de compte, si le développeur peut écrire son application plus rapidement avec votre API, vous obtiendrez de la traction. Mais à quel prix pour l'équipe d'ingénierie.

Je pense que la vraie question est de savoir comment l'interface utilisateur peut être construite plus rapidement. Je pense que l'outillage pourrait écrire la fléchette, ignorer tout balisage intermédiaire. Et mon but n'est pas vraiment de dire que ça n'en vaut pas la peine, mais vraiment de compter sur tous les fronts si la route est prise !

E4X était une norme ECMA. Mozilla l'a expédié pendant un certain temps, mais l'a ensuite supprimé (une décision très inhabituelle pour un fournisseur de navigateur). Les autres fournisseurs de navigateurs n'ont jamais voulu l'implémenter.

Je dirais que seul Adobe a pleinement défendu E4X et a eu un bon suivi auprès des développeurs. Les fournisseurs de navigateurs ajoutent et suppriment constamment des éléments de leurs navigateurs ; Google n'a-t-il pas supprimé le support MathML ?

C'est une théorie possible. Cependant, les gens ont tendance à demander beaucoup d'autres choses, et beaucoup de choses qu'ils demandent sont mises en œuvre, et il existe également des solutions de contournement pour les GIF animés, donc je ne suis pas sûr que cela explique complètement la situation.

Voici la chose à propos de React et JSX. vous n'appréciez vraiment pas pleinement ce que React apporte à la table jusqu'à ce que vous développiez avec lui pendant un certain temps, puis ça devient nuit et jour contre tous les autres cadres.

Comment un éditeur graphique gérerait-il ce balisage ? Je ne comprends pas vraiment comment visualiser l'interface utilisateur pour cela.

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

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

Je représenterais le \comme un rectangle et si son enfant/ses enfants étaient d'autres widgets, je mettrais des rectangles pour cela à l'intérieur.
Étant donné que l'enfant dans ce cas est une fonction, vous pouvez simplement mettre un rectangle indiquant "uneditable/code" pour dire aux utilisateurs que ce widget est créé à partir de code ou dans ce cas en déduire facilement que la fonction est un wrapper superficiel pour lewidget et présentez-le simplement ; Je veux dire un rectangle qui dit que la fonction est un wrapper de fonction peu profond et à l'intérieur le rectangle du widget d'élément de liste (\dans ce cas).

Mais vraiment, le balisage est un énorme investissement en temps et en outils de complexité supplémentaire pour le transformer en programme réel.

Tout ce que je demande, c'est d'ajouter ces extensions simples sur le compilateur Dart afin que, si les développeurs le souhaitent, ils puissent écrire en utilisant cette structure XML. L'ancienne méthode continuerait à fonctionner et la quantité de travail nécessaire pour le faire n'est pas énorme du tout. Vous pouvez en fait voir combien de lignes de code il faut au compilateur babel.js pour faire JSX et je parle de centaines et non de milliers de lignes (je viens de le vérifier).

Et l'outillage est toujours le dernier à venir. Donc en attendant, pendant que tout cela se manifeste dans la réalité, il y a deux mondes. Deux façons intéressantes de tout faire. Un dans la langue par défaut et un dans le balisage

Bien sûr, mais React a été comme ça et ce n'est pas du tout un problème.

Lorsque j'écris de la documentation, je dois l'écrire deux fois, une fois pour Java et une fois pour UiBinder XML Markup.

Pas dans React car le balisage vit à l'intérieur du code.

est la complexité supplémentaire vaut le voyage!

Absolument, c'est comme l'argument de savoir si vous devez former vos développeurs aux dernières techniques et risquer qu'ils quittent votre entreprise. Le plus grand risque est de les garder sans formation. Vous devez donc adopter les dernières techniques ou risquer d'être laissé pour compte.

React mène le voyage avec les dernières techniques pour développer UI/UX. Il a une traction énorme avec les développeurs. Votre plus grand risque est de ne pas atteindre la barre de réaction.

Je pense que JSX vise à résoudre d'autres problèmes où vous souhaitez mélanger ce que vous faites avec HTML et javascript

JSX n'est pas seulement pour HTML, React Native génère des vues (comme Flutter Widgets) à partir du balisage XML.

Je pense que la vraie question est de savoir comment l'interface utilisateur peut être construite plus rapidement.

Plus comme la façon dont l'interface utilisateur/UX peut être mieux construite. Meilleur sens : plus rapide, meilleure qualité (code et UI/UX), interaction concepteur-développeur fluide, etc.

Au fait, très beau travail fait sur les outils de développement ; 'docteur flutter' était génial !!!
Je cuisine maintenant au gaz et je peux être dangereusement créatif ;)

Je voulais juste répondre à la question de lisibilité soulevée ici, bien que je comprenne que la lisibilité n'est qu'un des nombreux facteurs que nous devons prendre en compte.

La lisibilité et la simplicité du code, qui à leur tour entraînent de nombreux autres avantages.

Si c'est le principal avantage, c'est quelque chose que nous pouvons tester. Nous pourrions prendre un mélange d'ingénieurs habitués à écrire du HTML, React, du code iOS, du code Android, Flutter, des applications en ligne de commande, etc., et leur présenter chacun différentes syntaxes, et leur demander de décrire ce qu'ils pensent du l'interface utilisateur résultante ressemblerait. Nous pouvons alors mesurer quelle syntaxe obtient les meilleurs résultats. @InMatrix est-ce quelque chose que nous pourrions examiner une fois le travail d'animation terminé, peut-être?

Il existe certainement des moyens d'étudier empiriquement la lisibilité du code, et nous pourrons avoir une discussion plus sérieuse au moment de la planification du quatrième trimestre. Pour rendre une telle étude utile, nous devons définir quels types de tâches de lecture sont importants pour les développeurs dans le contexte de la programmation Flutter. En plus de lire une méthode de construction entière et d'imaginer ce que pourrait être l'interface utilisateur résultante, la lisibilité affecte également des tâches plus petites telles que l'identification de la méthode de construction dans un fichier Dart, la correspondance des accolades, la lecture des commentaires en ligne, etc.

Pour prendre en charge certaines de ces tâches plus restreintes, nous pouvons d'abord expérimenter des améliorations de l'interface utilisateur dans l'éditeur, ce qui est généralement moins cher que l'introduction et la maintenance d'un langage de balisage. La fonctionnalité d'étiquette de fermeture dans le code VS est l'une de ces améliorations de l'interface utilisateur, et nous devons comprendre dans quelle mesure elle résout le problème de correspondance des accolades qu'elle vise à résoudre. Il existe de nombreuses autres options dans cet espace que nous n'avons pas encore essayées. Par exemple, une police ou une couleur d'arrière-plan différente peut être utilisée pour afficher la méthode de génération afin d'aider le développeur à la séparer mentalement du reste de son code.

Une autre chose qui me semble importante est la façon dont nous pouvons encourager les gens à ne pas écrire de méthode de construction géante et à tirer parti de la nature de composition du framework. Si la méthode de construction est plus haute que la hauteur de votre écran, elle sera difficile à lire, qu'il s'agisse de Dart ou de XML.

Une autre chose qui me semble importante est la façon dont nous pouvons encourager les gens à ne pas écrire de méthode de construction géante et à tirer parti de la nature de composition du framework. Si la méthode de construction est plus haute que la hauteur de votre écran, elle sera difficile à lire, qu'il s'agisse de Dart ou de XML.

Ce n'est pas seulement la méthode de construction. Ce sont toutes les autres méthodes que la méthode build appelle pour construire l'arborescence des widgets. Il est très courant dans React d'utiliser des méthodes plus petites pour créer des sous-arborescences, puis de les appeler dans l'arborescence plus grande.

Toujours dans WebStorm avec JSX, chaque nœud XML a +/- qui peut être utilisé pour développer/réduire le nœud et les enfants afin de faciliter la lecture de structures plus grandes que la hauteur de l'écran.

Une chose que nous avons trouvée dans Flutter est que les grandes méthodes de construction ne sont pas excellentes pour les performances, et nous essayons d'encourager les gens à décomposer leurs méthodes de construction en petits widgets réutilisables. En particulier, dans Flutter, avoir une méthode de construction construite à partir des résultats d'autres méthodes est en quelque sorte un anti-modèle que nous préférons décourager plutôt que de faciliter. (Il s'agit d'une réalisation assez récente, donc beaucoup de nos exemples et widgets ne le font pas encore bien.)

nous essayons d'encourager les gens à décomposer leurs méthodes de construction en petits widgets réutilisables.

Devient-il vraiment un widget réutilisable ou simplement un widget wrapper/composite ? Je veux dire que pour être réutilisable, vous devez avoir au moins 2 instances d'utilisation.

L'AppBar sur https://flutter.io/catalog/samples/basic-app-bar/ est si unique que vous ne pouvez pas vraiment l'appeler un composant réutilisable ; c'est un composant wrapper/composite et dans ces cas pourquoi ne pas simplement utiliser une méthode locale pour construire cette partie de l'interface utilisateur ? Je suppose que s'il faisait plus de choses, il serait logique de le placer dans un composant wrapper/composite.

Une chose que nous avons trouvée dans Flutter est que les grandes méthodes de construction ne sont pas idéales pour les performances

Puisque vous avez mentionné les performances, le fait que la boucle d'animation pilote la méthode de construction entraînera des problèmes de performances pour une animation fluide. Vous ne voulez pas que votre méthode de construction soit appelée 60 fois par seconde ou plus, surtout si l'on considère que la méthode de construction est du code utilisateur (par exemple, elle pourrait avoir une boucle très longue qui prendrait une éternité et entraînerait le saut des animations). Étant un débutant Flutter, je me suis peut-être trompé.

L'AppBar sur https://flutter.io/catalog/samples/basic-app-bar/ est si unique que vous ne pouvez pas vraiment l'appeler un composant réutilisable

C'est aussi relativement petit, donc ça va.

En ce qui concerne les performances, c'est quelque peu hors sujet pour ce problème, veuillez donc créer un nouveau problème si vous souhaitez en discuter (ou envoyez un e-mail à flutter-dev ou postez sur le débordement de la pile, comme vous préférez).

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

C'est fou de voir ce problème enterré. À mon avis, ce sera un succès ou un échec pour Flutter d'implémenter une syntaxe de type JSX pour composer des widgets.

Je ne comprends tout simplement pas le public cible, de nombreux développeurs iOS et Android se déplacent pour réagir en natif, cela semblerait être l'occasion idéale de récolter des parts de marché.

J'encourage les personnes impliquées à donner un tour à Rea ​​Native et à voir de quoi nous parlons.

JSX ne me manque pas du tout dans Flutter. Cela ne ferait que gonfler le cadre et les outils pour quelques petits gains ici et là.

@birkir Je suis à 100% avec vous sur cette question. Le manque de JSX, qui convient parfaitement à Flutter, donne à Flutter un aspect vieux et rouillé, ressemble à la technologie des années 1990. En fait, il semble que tout le monde, d'une manière ou d'une autre, adopte JSX ; le dernier en date étant le framework populaire Vue.js.

+1

@zoechi Quelle est votre expérience précédente avec JSX, l'avez-vous vraiment utilisé ou juste regardé ? Je pense que vous sous-estimez JSX en disant qu'il donnera de petits gains ici et là. Si vous n'avez pas d'utilisateurs, vous n'avez pas de produit.

@birkir Je vois beaucoup d'enthousiasme à propos de JSX ici, mais personne ne semble prendre la peine d'expliquer exactement ce que Flutter gagnerait à avoir un tel DSL, sauf peut-être une meilleure lisibilité qui est principalement subjective.

Plus de fonctionnalités ne font généralement que monopoliser un framework au lieu de l'améliorer.
Leur mise en œuvre consomme également beaucoup de ressources qui manquent dans d'autres domaines où les fonctionnalités manquantes empêchent en fait les gens de mettre en œuvre certaines applications.

Donc, si vous êtes enthousiaste à l'idée que Flutter obtienne quelque chose comme JSX, vous devriez investir votre temps et votre énergie dans la rédaction d'arguments convaincants.
Le simple fait d'ajouter quelque chose parce que d'autres l'ont aussi est probablement l'argument le plus faible qui soit.

Il est également prévu d'améliorer Dart pour rendre l'écriture du code de l'interface utilisateur Flutter moins verbeuse, ce qui affaiblit encore plus le cas de JSX.

Alors, quels sont vos arguments convaincants ?

Vraiment !!! "personne ne semble prendre la peine d'expliquer exactement ce que Flutter gagnerait... bla bla bla".
Vous n'avez pas lu entièrement ce fil ? Votre capacité d'attention est-elle supérieure à vos connaissances JSX ?

Vous souffrez du syndrome NIH (Not-invented-here). « Les bons artistes copient ; les grands artistes volent », les artistes médiocres, eh bien, faites comme vous.

Le simple fait que la prise en charge de JSX soit relativement simple et qu'elle aidera énormément à attirer de nouveaux clients (développeurs mobiles React Native) sur la plate-forme en fait une évidence que vous ne voyez pas. Cela ne va pas bien pour la plate-forme.

Pouvons-nous s'il vous plaît garder un ton constructif lors du débat.

Ajouter des fonctionnalités parce que d'autres l'ont est un argument faible. D'accord.
Pourquoi le flottement a-t-il un rechargement à chaud ? D'où vient cela? Jésus mec.

Comment avons-nous échoué à vous fournir des arguments solides ? La traction du projet et l'attraction des développeurs sont notre principale raison.

Raison numéro deux, la lisibilité :

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

Raison numéro trois, GUI Builders . Je citerai la première ligne du README.

Un nouveau SDK d'application mobile pour aider les développeurs et les concepteurs à créer des applications mobiles modernes pour iOS et Android.

Je détesterais voir Flutter descendre dans le même terrier que Polymer avant même qu'il n'atteigne la version bêta.

Traction du projet et attirer les développeurs

La relation n'est toujours pas claire.

Raison numéro deux, la lisibilité :

Rendre le code Dart plus lisible me semble un meilleur objectif

Raison numéro trois, GUI Builders. Je citerai la première ligne du README.

Autant que je m'en souvienne, il a déjà été mentionné ci-dessus qu'il n'y a aucune raison pour laquelle l'utilisation du code Dart empêcherait cela.

Vos contre-arguments ne peuvent pas vraiment rejeter l'idée, n'est-ce pas ?

1. La relation est assez claire. A moins que ce ne soit pas un objectif pour que le projet soit populaire ?
2. Super! Sera-t-il proche de la lisibilité JSX ? Quelle est la proposition actuelle pour une telle chose?
3. Il a été dit que cela pouvait être fait . L'adaptation de la prise en charge de JSX pour les constructeurs d'interfaces graphiques actuellement disponibles sera beaucoup plus simple.

Il est également prévu d'améliorer Dart pour rendre l'écriture du code de l'interface utilisateur Flutter moins verbeuse

C'est bien de voir la reconnaissance que la méthode actuelle pourrait utiliser certaines améliorations.
Veuillez fournir des détails sur cette proposition. Votre meilleur pari est d'interagir avec la communauté React Native pour obtenir des commentaires.

Plusieurs demandes de fonctionnalités du langage Dart pourraient rendre le code plus court/lisible :

• Optionnel new et const pour Dart 2
• Méta-problème pour la discussion de la proposition d'autoriser les arguments nommés partout - - cela pourrait permettre au widget avec l'argument child d'ignorer l'argument nommé.
  
  
  
  • Nombre variable d'arguments - cela pourrait permettre aux widgets avec l'argument children (comme Row et Column) d'ignorer cet argument nommé et sa déclaration de liste.
  
  

Avec ces modifications, le code pourrait ressembler à :

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

De plus selon votre IDE vous pouvez éventuellement avoir des commentaires synthétiques en fin de parenthèse et vous pourriez voir quelque chose comme ça dans votre IDE :

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

Cette conversation s'échauffe. Je voudrais encourager tout le monde à lire notre code de conduite :
https://flutter.io/design-principles/#conflict-resolution
Je vais clore cette conversation pendant quelques jours pendant que chacun considère comment il peut contribuer de manière respectueuse et productive.

Nous savons tous que la syntaxe de création d'interface utilisateur est une partie très importante de l'expérience de développement mobile. Pour l'instant, la syntaxe est un peu verbeuse, je dois new quelque chose juste dans le but d'ajouter une marge : margin: new EdgeInsets.symmetric(horizontal: 4.0) , je pense qu'il peut y avoir un moyen plus simple.

Serait-il possible de construire un DSL comme ce que l'équipe Kotlin a fait pour les développeurs Android ? C'est ce qu'on appelle Anko , un DSL pour créer une interface utilisateur Android :

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

Une syntaxe concise aide à garder le code lisible et maintenable, peut également rendre le travail de construction agréable, c'est important. S'il vous plaît, l'équipe Flutter l'estime sérieusement avant de prendre la décision. Nous aimons tous voir Flutter connaître un plus grand succès dans les années à venir.

Veuillez ne pas introduire de syntaxe de type XML dans Flutter.

J'ai programmé en Android Java pendant plus d'un an, puis j'ai commencé à chercher un ensemble d'outils multiplateformes à essayer.
J'ai commencé avec React Native puis j'ai essayé React. Je n'ai pas vraiment aimé la syntaxe JSX car ce n'est pas tout à fait javascript et pas tout à fait html, donc juste une autre chose à apprendre.
Lorsque j'ai essayé Flutter, j'ai trouvé qu'il était beaucoup plus facile de démarrer (probablement principalement en raison de mon expérience Java).

Je pense que certaines des raisons pour lesquelles je ne voudrais pas voir une syntaxe XML ajoutée à flutter :

1. Une autre chose à apprendre - pourrait être dépensée pour apprendre Futures à la place ;P
2. Changement de contexte - vous changez de contexte entre XML et le code, ce qui n'est qu'une charge cognitive inutile.
3. Il y a eu des jours où j'ai programmé en Java le matin et en Python l'après-midi. Avec React, vous devrez peut-être comprendre Javascript, Babel, JSX, HTML, CSS et plus encore dans une seule base de code.
4. La raison pour laquelle XML n'est pas nécessaire dans Flutter est que Dart a des arguments nommés qui remplacent assez bien les attributs XML.
5. Dart a le très cool dartfmt qui indente très bien le code sans effort.

Comparé à Android

1. Vous devez apprendre la manière programmatique de toute façon, pourquoi ajouter une autre façon de faire les choses ?
2. La mise en page XML dans Android est plus rapide pour afficher les modifications sur l'appareil, mais l'exécution dans Flutter est pratiquement instantanée de toute façon, donc l'ajout de XML ne fournirait pas cet avantage.
3. La combinaison Android XML + programmatique ajoute de la complexité, comme le gonflement des extraits XML et l'injection dans l'arborescence XML par programmation.
4. L'exécution instantanée est si rapide dans Flutter que vous n'avez pas besoin du modèle XML pour vous aider à visualiser son apparence, vous pouvez simplement appuyer sur une touche et voir le changement immédiatement.
5. Les erreurs des problèmes de mise en page programmatique sont différentes des problèmes de mise en page dans XML, c'est donc deux ensembles de choses que vous devez comprendre.

J'irais plus loin et supprimerais pubspec.yaml et le remplacerais par pubspec.dart et j'aurais la configuration dans le code de fléchette.

Si les développeurs se plaignent de la difficulté de disposer visuellement les pages, une idée serait de créer un concepteur de mise en page qui vous permette de définir visuellement vos thèmes et de concevoir des pages par glisser-déposer. Ensuite, il générerait du code Flutter qui n'est pas destiné à être modifié - mais crée plutôt des classes qui peuvent être utilisées pour composer votre application.

Il n'aurait pas besoin d'être une édition bidirectionnelle (XML/mise en page) comme Android XML, mais vous enregistrez simplement votre mise en page pour plus tard. Si vous avez besoin de le modifier, vous pouvez régénérer le code et (espérons-le) simplement modifier certains arguments.

Je sais que cette conversation est ancienne et oui, elle devenait assez chaude, mais j'aimerais laisser tomber quelques lignes sur ce que je considère se passer ici.

Flutter est NOUVEAU. C'est une toute NOUVELLE façon de faire les choses. Oui, il a emprunté au paradigme de réaction. Mais cela ne signifie pas qu'il doit suivre les mêmes étapes. Je ne pense pas que ce soit l'objectif de l'équipe Flutter d'attirer les développeurs de React Native à venir flutter, c'est seulement pour créer quelque chose de nouveau qui pourrait intéresser les développeurs. Google l'utilise en interne avant de le partager avec le monde et ils ont été productifs avec ce. Je partage les commentaires avec @Hixie selon lesquels ce n'est pas différent de JSX pour construire l'interface utilisateur. Oui, c'est un peu plus verbeux à la fléchette pure droite. Mais cela facilite en fait le débogage de votre code.

La raison pour laquelle je suis contre un langage de balisage ou JSX ou tout ce qui se trouve au-dessus d'une technologie est qu'il nécessite des tonnes de travail supplémentaires de la part de la plate-forme. Vous pouvez être heureux de composer un langage de balisage pour une interface utilisateur, mais vous aurez tellement de développeurs travaillant sur la plate-forme qui pleurent et s'arrachent les cheveux pour que cela fonctionne pour vous. Un autre point de vue est que JSX a travaillé pour une communauté Javascript, où, comme toujours, son objectif principal est de faciliter les choses pour le développeur et de ne pas se soucier des compromis. Ne vous méprenez pas, React (JSX) pour le Web était un match parfait car HTML est de toute façon un balisage. Mais pour React Native, regardez tout le code dans le référentiel qu'ils ont dû faire pour le faire fonctionner. L'ajout de JSX au flottement nécessiterait des tonnes de travail et 2 choses à penser lors de l'ajout de nouvelles fonctionnalités. Et encore une fois juste pour pouvoir supprimer le paramètre enfant et les const et new Keywords?. Je préfère savoir ce qui se passe réellement dans le code et avoir le contrôle sur ce qui se passe plutôt que d'avoir une syntaxe magique qui ne fait qu'ajouter une surcharge.

Eh bien c'est mon avis. Je ne veux pas lancer une nouvelle discussion gigantesque. Juste pour mentionner le fait que JSX est génial pour une communauté de réaction/javascript parce que cela a fonctionné pour eux, mais pour Dart/flutter, je trouve un peu exagéré d'ajouter JSX juste pour attirer les développeurs de React Native.

Wow, j'aurais pu écrire un article de blog xD

@Rockvole ,

Une autre chose à apprendre - pourrait être dépensée pour apprendre Futures à la place ;P

La chose à apprendre rend la monstruosité actuelle de la construction d'objets récursifs plus simple et familière aux développeurs React Native de tous les jours, donc je suppose que les gens préféreront apprendre cela.

Changement de contexte - vous changez de contexte entre XML et le code, ce qui n'est qu'une charge cognitive inutile.

Pas un problème, il n'y a pas de changement de contexte, c'est juste une partie de l'environnement qui rend la programmation UI/UX plus propre.

Ensuite, cela générerait du code Flutter qui n'est pas destiné à être modifié

Pourquoi pas? Pas très utile alors.

@franzsilva

Je ne pense pas que ce soit l'objectif de l'équipe de Flutter d'attirer des développeurs de React Native à venir flutter

Vraiment !!! React Native domine et étant donné que le nombre total de développeurs mobiles utilisant des outils multiplateformes est limité, pensez-vous vraiment que Flutter peut devenir un succès sans attirer les React Native ?

Oui, c'est un peu plus verbeux à la fléchette pure droite. Mais cela facilite en fait le débogage de votre code.

Ce n'est pas une déclaration correcte. Le débogage du code JSX, qui n'est que du code javascript, n'est ni plus facile ni plus difficile, c'est la même chose.

La raison pour laquelle je suis contre un langage de balisage ou JSX ou tout ce qui se trouve au-dessus d'une technologie est qu'il nécessite des tonnes de travail supplémentaires de la part de la plate-forme.

Qui se soucie de la quantité de travail placée sur la plate-forme ? Les développeurs veulent juste les dernières techniques qui améliorent la lisibilité du code et la productivité. Aucun développeur ne veut utiliser des techniques anciennes et obsolètes alors que des éléments plus récents offrent une meilleure alternative.

Je préfère savoir ce qui se passe réellement dans le code et avoir le contrôle sur ce qui se passe plutôt que d'avoir une syntaxe magique qui ne fait qu'ajouter une surcharge.

C'est un non-sens, je sais exactement ce qui se passe avec JSX, c'est une toute petite couche qui se transforme presque un à un mais offre beaucoup d'avantages. Temps de compilation négligeable si vous me demandez.

Juste pour mentionner le fait que JSX est génial pour une communauté de réaction/javascript parce que cela a fonctionné pour eux, mais pour Dart/flutter, je trouve un peu exagéré d'ajouter JSX juste pour attirer les développeurs de React Native.

JSX devrait également fonctionner parfaitement pour Dart/Flutter. Ce n'est en aucun cas exagéré. Y a-t-il une bonne raison pour laquelle JSX ne fonctionnerait pas pour Dart/Flutter ? Si je devais le coder et le publier, pourquoi ne conviendrait-il pas au développement de Dart/Flutter ?

Prenons l'exemple concret de @xinthink :

Pour l'instant, la syntaxe est un peu verbeuse, je dois new quelque chose juste dans le but d'ajouter une marge : margin: new EdgeInsets.symmetric(horizontal: 4.0) , je pense qu'il peut y avoir un moyen plus simple.

Si vous souhaitez ajouter une marge à gauche et à droite, comment voudriez-vous l'exprimer ? Plus précisément, prenons un exemple simple et voyons à quoi il ressemblerait dans diverses syntaxes.

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

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

Comment recommanderiez-vous que nous exprimions cette sémantique _exacte_ ?

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

Babel.js a ce petit site Web soigné, où vous pouvez taper JSX et le convertir en Javascript simple :
https://babeljs.io/repl/# ?babili=false&evaluate=true&lineWrap=false&presets=es2015%2Creact%2Cstage-0&code=function%20hello()%20%7B%0A%20%20return%20%3Cdiv%3EHello% 20monde !%3C%2Fdiv%3E%3B%0A%7D

Je ferai un équivalent pour DSX to Dart. Juste une preuve de concept, voyons combien de temps cela me prend...

Voici le dernier exemple de @Hixie dans "DSX", en utilisant le guide de style d'Airbnb et en supposant que tous les éléments enfants peuvent automatiquement être mappés aux propriétés child .

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

Si l'intention est d'améliorer la lisibilité, je pense que le futur Dart gagne à la pelle.

Vous devez consulter la documentation pour savoir ce qui peut se transformer en balises (vraisemblablement Widget s uniquement), ou combien d'éléments enfants sont requis/autorisés.

Si votre objectif est de générer du HTML à partir de JavaScript, JSX a beaucoup de sens en tant que terrain d'entente. Parce que quand vous voulez des balises à la fin de la journée, React.createElement('div', null, 'foo') est bien pire que <div>foo</div> .

Si votre objectif est de générer un arbre d'objets Dart à partir de ... Dart, et qu'un arbre bien formaté de constructeurs Dart est parfaitement (sans doute plus) lisible, je ne vois pas l'intérêt de faire un détour par XML. Et je ne manque pas ces XML provenant d'Android.

C'est ce que l'utilisation de XML permet... Écoutez, cela fait 5 mois que je parle, maintenant je fais quelque chose à ce sujet, alors donnez-moi du temps (j'ai un travail à plein temps et je ne peux épargner qu'environ 4 heures le week-end).

Je viens de trouver ce fil, intéressant des deux côtés. En tant que développeur React intéressé par Flutter, il y a quelques autres arguments que je n'ai pas vus mentionnés (bien que je n'aie fait que parcourir brièvement tous les commentaires.)

1. La déclaration de balise de fermeture améliore la compréhension des enfants par rapport aux propriétés. L'interface utilisateur peut malheureusement être profondément imbriquée, et avoir une balise claire par rapport à un unknown ) aide à clarifier et à analyser les enfants. Cela me permet également de déplacer le code entre les composants et de voir de manière très déclarative quand quelque chose n'est pas à sa place (une balise de fermeture avant un par exemple.) C'est plus délicat avec plusieurs ) imbriqués.

2. Ma réaction instinctive initiale à la vue de plusieurs composants imbriqués dans les constructeurs me donne des flashbacks sur "l'enfer des rappels" . C'était une époque très douloureuse de JS qui commence à s'améliorer, y revenir ressemble un peu à un pas en arrière.

3. Lié au #2, le fait malheureux est que nous devons convaincre les gens de changer (ou au moins de l'essayer). Beaucoup de gens utilisent React/React Native et encore plus en utilisant HTML/JS. Créer un didacticiel / guide simple et principalement familier sur le plan syntaxique qui cible spécifiquement certains des points faibles de React pourrait être extrêmement convaincant pour ceux qui sont un peu fatigués.

L'une des principales raisons pour lesquelles React est devenu populaire dans la communauté des développeurs Web était le support de JSX.

C'est vraiment décevant de voir des "votes négatifs" sur une si belle demande de fonctionnalité. Il améliore la lisibilité et accélère l'adoption.

Je pense que c'est une différence majeure entre Open JavaScript et Dart. JavaScript est vraiment open source alors qu'une demande sur Dart entre dans une conversation comme celle-ci et, finalement, vous êtes démotivé par les votes négatifs.

Faites plus de place aux nouvelles idées !

@jayjun Ça a l'air incroyable ! Puis-je essayer quelque part ?

@sanketsahusoft Ne vous inquiétez pas très bientôt vous pourrez essayer ma version et elle est encore meilleure que @jayjun.

Mise à jour rapide : il y a 2 week-ends, l'interface utilisateur fonctionnait très bien. Le week-end dernier, l'analyseur fonctionnait parfaitement et la moitié du transpileur fonctionnait. Ce week-end j'espère en finir si j'évite le Superbowl ;)

J'ai la peau épaisse et l'entêtement comme une mule, donc je ne remarque même pas ces votes négatifs, merci de les avoir signalés cependant.

Carlos.

Cela aiderait-il à résoudre le problème de la perte de trace des balises de fermeture ?
Idée : Balises de fermeture générées automatiquement

Voici une syntaxe de balisage proposée pour l'exemple de @Hixie :

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

@abarth , la chose intéressante que vous avez faite a été d'ajouter une troisième possibilité d'attribut qui simplifie l'apparence des expressions lorsqu'elles sont une autre balise.
JSX a :
1 - <tag attrib=""/> ou <tag attrib=''/>
2 - <tag attrib={}/>
Vous en proposez une autre :
3 - <tag attrib=<anotherTag.../>/>
avec JSX, vous devez l'écrire comme suit :
<tag attrib={<anotherTag.../>}/>

@cbazza Ouais, le troisième cas est assez courant dans Flutter, il est donc logique d'ignorer l'imbrication supplémentaire { .

@abarth Ah mais je rends la plupart de ces choses inutiles en utilisant des styles de type css !!! Le transpileur étend ces styles de type css en appels Flutter appropriés. Désormais, la structure de marquage est beaucoup plus propre et les styles peuvent être facilement importés à partir d'outils de conception tels que InVision, Figma, Atomic, etc.

@cbazza Cool, j'utilise de nombreux widgets avec des fermetures comme FutureBuilder . J'espère que votre transpiler peut générer quelque chose comme,

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

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

@jayjun , oui, ce n'est pas un problème. Le transpileur est un simple processeur XML et lorsqu'il s'agit d'analyser des expressions (tout ce qui se trouve à l'intérieur de {}), il devient simplement un blob de texte et l'écrit textuellement.

@xinthink

Serait-il possible de construire un DSL comme ce que l'équipe Kotlin a fait pour les développeurs Android ?

On dirait que beaucoup de gens aimeraient utiliser Kotlin avec Flutter. Honnêtement, je ne comprends pas, pourquoi les développeurs ont-ils décidé de réinventer les roues de Dart ?

À mon humble avis, Flutter n'a pas besoin de JSX. Flutter aurait dû choisir Kotlin au lieu de Dart. Kotlin nous permet d'écrire une logique d'interface utilisateur complexe avec une belle syntaxe prête à l'emploi, possède une énorme communauté, des outils prêts pour la production, testés au combat dans le développement Android...

Juste dire.

Kotlin est sympa, je suis un fan mais il ne fonctionne pas sur iOS ..... en fait, il le fait mais il n'est pas encore sorti (étape de pré-version en ce moment).
Pour le développement UI/UX, je préfère toujours JSX au lieu d'Anko DSL. J'aime le fait de pouvoir séparer visuellement le balisage déclaratif du code impératif et de pouvoir mélanger et assortir les composants assez facilement.

Dart, Kotlin et Swift ont tous des points communs :
https://sethladd.github.io/swift-is-like-kotlin-and-kinda-like-dart/

J'aime ça :

1. Dart est plus familier si vous venez de Java.
2. Vous pouvez prendre vos compétences Dart et les utiliser pour créer des pages Web - ce qui est précieux lors de la création d'applications, vous pouvez créer des fonctionnalités sur le Web (et les afficher dans une WebView) là où cela a plus de sens (peut-être des pages d'administration rapides ou des listes de produits qui doivent être indexés google).
3. Dart a été conçu dès le départ pour compiler en javascript, ce qui, je suppose, n'est pas facile à ajouter ultérieurement à un langage.

Ce sont essentiellement les raisons pour lesquelles j'ai choisi Dart plutôt que Kotlin / Swift / React.

_Bien que la décision de prendre en charge Dart et Swift dans le nouveau système d'exploitation Fuchsia de Google me déroute._

Je ne suis pas sûr que Dart soit plus familier si vous venez de Java. Je viens de Java et je n'ai aucun problème avec Kotlin ou Swift ; fondamentalement, la déclaration de type est inversée, rien de vraiment nouveau car elle était utilisée dans Pascal et ActionScript.

Oui, vous pouvez créer des pages Web avec Dart, mais je ne vois pas d'intérêt majeur pour cela. Le seul autre langage qui fonctionne bien sur le Web est TypeScript, car il s'intègre bien avec les 3 meilleurs frameworks Web les plus populaires.

Jetez un œil aux différentes syntaxes disponibles pour React sur le Web :
https://github.com/Workiva/over_react#fluent-style-component-consumption
Les deux versions de Dart n'ont aucune chance contre JSX !!!

TypeScript a été conçu pour compiler en Javascript et il est meilleur que Dart pour cela. Il prend également en charge JSX.
Dart est pressé de tous les côtés. Swift a de l'élan, il est donc sage de le prendre en charge sur Fuchsia OS avec votre bébé.

Combien de temps jusqu'au prototype ? J'aimerais l'utiliser !

J'ai utilisé React pendant un certain temps et JSX a décuplé ma productivité. Ce n'est pas une question controversée : d'autres équipes ont décidé, à juste titre, que ce serait mieux, alors pourquoi pas Flutter ? (Rhétorique : j'ai lu le fil... (facepalm))

J'y travaille ce week-end mais je continue d'augmenter la portée avec de nouvelles idées, alors j'espère pouvoir sortir quelque chose ce week-end.

Certaines des choses intéressantes que j'expérimente:
1) en utilisant l'espace de noms xml sur les balises enfants afin qu'elles soient insérées avec le bon argument Dart nommé dans le parent.
2) opérateur de propagation pour mieux organiser le style comme des propriétés afin qu'elles puissent être définies/regroupées en dehors de xml dans une carte, puis importées et réparties sur une balise comme des éléments typiques de React.
3) propriété styleCSS qui génère des styles flottants à partir de CSS.

(1) et (2) sont génériques et fonctionnent donc pour tous les codes Dart Flutter.
(3) est spécialisé par Flutter Widget (Container, Text, etc.) et je ne fais que ces 2 pour l'instant.

@yuriy-manifold ce n'est pas parce que quelque chose a fonctionné pour JS que c'est une bonne idée pour Dart.
Si vous aviez lu les discussions ci-dessus, vous auriez vu qu'en fait c'est controversé.
Je ne vois pas pourquoi 2 langues valent mieux qu'une.

ce n'est pas parce que quelque chose a fonctionné pour JS que c'est une bonne idée pour Dart.

JSX est une idée incroyable pour le développement UI/UX dans un cadre réactif quelle que soit la langue. Si j'avais plus de temps libre je sortirais LSX qui est JSX pour Logo ;)

Je ne vois pas pourquoi 2 langues valent mieux qu'une.

Vous pouvez programmer iOS avec Objective-C et Swift (2 langues)
Vous pouvez programmer Android avec Java et Kotlin (2 langages)
...

Je n'ai pas encore vu d'argument en faveur de JSX.
Les discussions ci-dessus ne contiennent que des arguments tels que "c'est mieux", "cela augmente la productivité", ou similaires, mais aucun argument sur pourquoi ou comment ce serait réellement mieux que le code Dart pur, en particulier compte tenu des changements de langage prévus qui réduiraient la différence entre JSX-like et
pur code Dart encore plus.

@cbazza

Vous pouvez programmer iOS avec Objective-C et Swift (2 langues)
Vous pouvez programmer Android avec Java et Kotlin (2 langages)

Comment est-ce lié à la discussion JSX? Comment cela peut-il être considéré comme un avantage ?
Vous pouvez utiliser Swift sur iOS car c'est le successeur d'Objectiv-C.
Vous pouvez utiliser Kotlin sur Android car il est considéré comme une amélioration astucieuse de Java.
On dirait que vous soutenez que JSX devrait remplacer Dart. Cela n'a pas beaucoup de sens pour moi.

@zoechi

Comment est-ce lié à la discussion JSX? Comment cela peut-il être considéré comme un avantage ?
Vous pouvez utiliser Swift sur iOS car c'est le successeur d'Objectiv-C.
Vous pouvez utiliser Kotlin sur Android car il est considéré comme une amélioration astucieuse de Java.
On dirait que vous soutenez que JSX devrait remplacer Dart. Cela n'a pas beaucoup de sens pour moi.

Vous l'avez réellement dit (JSX est une amélioration par rapport à la méthode actuelle) mais vous êtes arrivé à la mauvaise conclusion (JSX pour remplacer Dart).

@cbazza c'est juste plus la même chose

quel est l'avantage réel par rapport à Dart ordinaire ?

"JSX est une amélioration subtile" n'est tout simplement pas convaincant et n'est pas un argument.
C'est juste un avis personnel sans (encore) aucun argument pour l'étayer,
similaire avec d'autres arguments pro-JSX ci-dessus.

Vous ne pouvez pas vous attendre à ce que quiconque considère vos suggestions si vous n'êtes pas disposé à fournir de bons arguments.

L'ajout de quelque chose comme JSX à Dart entraîne énormément de travail et de complexité dans les outils Flutter et l'IDE. Vous devez fournir des arguments appropriés pour que les autres envisagent même de le regarder.

@zoechi sonne comme un disque rayé demandant de "bons" arguments, beaucoup ont été donnés auparavant mais vous ne l'avez tout simplement pas compris; ce qui est OK, "chacun son propre".

L'ajout de quelque chose comme JSX à Dart entraîne énormément de travail et de complexité dans les outils Flutter et l'IDE. Vous devez fournir des arguments appropriés pour que les autres envisagent même de le regarder.

Pas vraiment, mon travail est presque prêt et cela m'a pris très peu de temps étant donné que je n'y travaillais que le week-end.

Encore une fois, DSX n'est qu'une amélioration astucieuse que les gens peuvent choisir d'utiliser ou non, car il ne change pas la manière actuelle, il fournit simplement une alternative que d'autres (développeurs React) connaîtront instantanément.

@cbazza

beaucoup ont été donnés

pas vraiment. Juste des affirmations générales qui peuvent être vraies ou non.
Aucun détail supplémentaire n'a été fourni qui permettrait à d'autres de vérifier.

Pas vraiment, mon travail est presque prêt

Super. Ensuite, l'équipe Flutter n'a plus besoin de faire quoi que ce soit et le problème peut être clos ;p
Cela inclut-il la prise en charge de la saisie semi-automatique et des vérifications de syntaxe dans tous les IDE pris en charge par Flutter ?

Super. Ensuite, l'équipe Flutter n'a plus besoin de faire quoi que ce soit et le problème peut être clos ;p

;)

Cela inclut-il la prise en charge de la saisie semi-automatique et des vérifications de syntaxe dans tous les IDE pris en charge par Flutter ?

La plupart des IDE prennent déjà en charge XML et JSX, il ne leur serait donc pas difficile d'ajouter mes ajouts mineurs.

Je me demande si la syntaxe JSX pourrait être plus appréciée dans angular Dart ? Il semble que ce soit plus une situation à laquelle vous êtes habitué plutôt que "mieux". La syntaxe JSX semble probablement plus naturelle pour les développeurs Web.

Je sais que la programmation me semble gênante, même en utilisant différentes couleurs de surbrillance de code pendant une journée.

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

Oui, les gens d'Angular seront très à l'aise avec JSX, mais les développeurs React Native aussi et c'est pour le développement mobile. JSX ne sera certainement pas pris par les développeurs actuels de Flutter mais cette deuxième alternative attirera de nouveaux développeurs vers Flutter et c'est certain.

L'article ci-dessus s'est tellement trompé, React sans JSX est fondamentalement inexistant et tous les frameworks Web réactifs permettent de mélanger le balisage et la programmation sur leur DSL.

Le temps est venu...
C'est avec grand plaisir que je vous annonce le transpileur DSX en ligne
https://spark-heroku-dsx.herokuapp.com/index.html

Beau travail avec le transpiler cbazza
Une chose que je dirais est plus facile à suivre avec JSX, ce sont les balises de fermeture. L'idée que j'évoquais précédemment :
Idée : Balises de fermeture générées automatiquement

Dans votre premier exemple, donnerait le code flutter de (suppression du nouveau facultatif dans le futur Dart) :

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

@cbazza J'apprécie votre travail pour la communauté et les personnes qui veulent créer des interfaces utilisateur de cette façon, mais j'espère vraiment que je ne serai jamais obligé d'utiliser quelque chose comme ça dans Flutter :-(((

En tant que nouveau venu dans Flutter mais assez familier avec React, quelques points m'ont marqué :

• Le modèle de gestion de l'État est à peu près le même
• L'arbre de rendu virtuel du widget/composant est à peu près le même
• Connaissant l'état et le modèle de composants, je me sens fondamentalement prêt à écrire une application maintenant, à l'exception de certaines spécificités de Dart et des API de la plate-forme, mais...
• Le langage de style est une pierre d'achoppement. Je fais référence à https://flutter.io/web-analogs/ mais il n'est pas facile de déterminer quelles importations sont nécessaires pour que les choses fonctionnent (EdgeInset ? Couleur ?) ou quand je dois utiliser des primitives au lieu d'instances de classe.
• L'analyseur CSS du convertisseur DSX de @cbazza est vraiment utile pour déterminer les équivalents de mise en page dans le modèle Flutter.

Concernant JSX :

• Je ne pense pas qu'il soit nécessaire d'inventer une nouvelle syntaxe JSX pour prendre en charge les modèles Flutter. Certains des problèmes de syntaxe dans ce fil pourraient être résolus à l'aide de certains des modèles React les plus récents, tels que les composants d'ordre supérieur (fonctions qui créent des classes de composants) et les accessoires de rendu (composants qui prennent des fonctions comme arguments ; les fonctions renvoient des éléments). Par exemple, des "emplacements enfants" nommés pourraient se traduire par quelque chose comme ceci dans JSX :

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

• Le meilleur argument contre JSX que j'ai vu était que Dart a nommé des arguments.
• Pourquoi est-il important qu'un élément sache s'il a plusieurs enfants ou un enfant ? Peut-être qu'une construction "fragment" pourrait lever l'ambiguïté de cette API.

Je pense toujours, en tant que nouveau venu dans Flutter avec une certaine expérience avec Angular, React, etc., que la manière habituelle de Dart, et plus encore dans le Dart 2.0, est meilleure que ce DSX. Cela a simplement plus de sens que certains paramètres XML et CSS. 🤷‍♂️

@cbazza votre deuxième exemple de démonstration a 466 caractères par rapport aux 391 de fléchettes (les deux sans espaces). Pour moi, il semble visuellement gonflé. Je devrais apprendre sa sémantique, ce que je n'ai pas à faire avec le code Dart normal. Et je ne sais pas comment utiliser des paradigmes de programmation à usage général avec (if, forEach, etc.).

Si j'avais le choix, je resterais sur le modèle actuel.

Tout le monde donne juste son opinion subjective sur la comparaison des deux syntaxes, mais nous devons nous mettre d'accord sur un fait : c'est une fonctionnalité très controversée. Il y a de l'amour et de la haine, mais la plupart des opinions divergent sur l'utilité de JSX par rapport à Dart ordinaire.

Dans tous les cas, je pense qu'il est totalement déraisonnable de demander à l'équipe Flutter de s'engager à prendre en charge cette fonctionnalité avant la version 1.0. Bien que la façon actuelle de créer une interface utilisateur ne semble pas géniale pour tout le monde, cela fonctionne (et cela fonctionne très bien selon certains avis).

Si les gens veulent vraiment une syntaxe de type JSX maintenant, un effort communautaire semble être la voie à suivre. Et cela aiderait à faire le cas (ou non) lorsque l'équipe Flutter le considère dans la version post 1.0.

Personnellement, je suis tout à fait d'accord avec l'argument suivant : ce n'est pas parce que JSX fonctionne pour React (où vous construisez déjà l'interface utilisateur à l'aide d'un langage de balisage) qu'il fonctionne automatiquement pour Flutter.

@tehfailsafe

La bonne nouvelle est que même si cela a été adopté par l'équipe Flutter (qui n'est probablement pas basée sur ce fil), personne ne serait FORCÉ de l'utiliser. C'est une OPTION. Je ne comprends pas pourquoi c'est si chargé émotionnellement que certaines personnes pourraient aimer écrire du code avec une syntaxe que vous n'aimez pas...

Je me fiche de ce que les autres aiment ou n'aiment pas. Mais je me soucie des fonctionnalités qui m'aident à progresser dans mon application. Les ressources sont limitées et je préférerais avoir un bon lecteur vidéo/flux, des vues enfant natives et un format graphique vectoriel.

Par exemple, en ce moment dans React et React Native, vous pouvez écrire toute votre application sans JSX, c'est juste une option. Voici à quoi ressemble React sans JSX :
[...]
C'est beaucoup plus désordonné que la version JSX, et presque personne ne l'utilise. C'est probablement pourquoi certains d'entre nous qui viennent de React apprécieraient la possibilité d'éviter d'avoir à refaire ce style.

C'est parce que le Web n'a pas été conçu pour un tel système. Si vous avez un langage de balisage statique comme HTML et que vous voulez le "dynamiser", vous devez inventer un système qui doit fonctionner en plus de cela. Vous vous retrouverez avec une construction contrainte par la plate-forme sous-jacente.
(voir : https://gbracha.blogspot.de/2014/09/a-domain-of-shadows.html)

Flutter, d'autre part, n'a pas de langage de balisage. Je n'ai pas encore vu de raison d'investir des ressources dans quelque chose de moins dynamique et moins expressif.

J'aimerais savoir si les personnes qui ne sont pas d'accord avec cela ont utilisé React avec et sans JSX. J'encourage tout le monde à l'essayer, donc cette discussion serait moins théorique. Après la courbe d'apprentissage initiale peu profonde, cela devient très naturel (et ce n'est pas seulement une question de nombre de caractères, car les balises de fermeture vous permettent de le lire plus facilement). Ce n'est pas différent d'apprendre autre chose de nouveau, comme Flutter, qui à long terme augmente la productivité. Et je suis d'accord que ce n'est pas pour tout le monde, c'est pourquoi ce serait facultatif.
Je pense qu'il est important de garder à l'esprit que nous avons les meilleurs intérêts de chacun à l'esprit - ce qui facilite la construction de choses. Je pense que ce transpiler aiderait, et il serait plus facile à adopter s'il bénéficiait d'un soutien officiel.

Aussi, merci @cbazza :)

@yuriy-manifold

Je ne pense pas que quiconque ici doute que JSX React soit une amélioration par rapport à React classique. Mais comme je l'ai dit, cette solution a été créée en raison de problèmes liés aux propriétés de la plate-forme sous-jacente. Flutter n'a pas ces propriétés.

La question n'est pas "JSX est-il utile pour React?" la question est "est-ce que quelque chose comme JSX est utile pour Flutter?".

Je pense que la réponse est non.

Il y a quelques autres choses à considérer :

• Séparer les spécifications de mise en page du code d'application peut rendre le code plus évolutif ; par exemple, cette proposition de syntaxe Dart 2 n'affecterait pas les méthodes build si elles étaient transformées selon un pragma évolutif en code Dart à partir d'un format agnostique comme JSX.
• Définir la mise en page en tant que balisage permet de séparer le moteur de rendu du moteur de widget (avec état/virtualisé) selon la relation de React avec ReactDOM et React Native, ce qui facilite potentiellement le portage des widgets vers de nouvelles plates-formes.
• La définition du format de balisage facilite le portage des mises en page existantes vers Flutter, par exemple à partir de Sketch ou d'autres outils de conception

Beau travail avec le transpiler cbazza

@Rockvole , merci.

J'apprécie votre travail pour la communauté et les personnes qui veulent créer des interfaces utilisateur de cette façon, mais j'espère vraiment que je ne serai jamais obligé d'utiliser quelque chose comme ça dans Flutter :-(((

@zoechi , merci. Oui, c'est juste une autre option pour les personnes qui aiment JSX à utiliser. Si ce n'est pas votre truc, continuez à faire comme vous le faites, rien ne change là-bas.

Je ne pense pas qu'il soit nécessaire d'inventer une nouvelle syntaxe JSX pour prendre en charge les modèles Flutter.

@alexkrolick , oui, vous pouvez utiliser des accessoires de rendu pour les paramètres nommés, mais vous ne pouvez rien faire à propos des paramètres positionnels. La clé était que je ne voulais rien coder en dur dans le transpiler pour que cela fonctionne pour tout.

Je pense toujours, en tant que nouveau venu dans Flutter avec une certaine expérience avec Angular, React, etc., que la manière habituelle de Dart, et plus encore dans le Dart 2.0, est meilleure que ce DSX. Cela a simplement plus de sens que certains paramètres XML et CSS.

@tenhobi , grande utilisation alors, évidemment DSX n'est pas pour tout le monde.

Si j'avais le choix, je resterais sur le modèle actuel.

@b-strauss, ce n'est pas un remplacement, c'est une option pour les personnes qui aiment JSX.

Il y a de l'amour et de la haine, mais la plupart des opinions divergent sur l'utilité de JSX par rapport à Dart ordinaire.

@lukaspili , DSX est pour les natifs de React qui aiment JSX, si vous ne voyez pas ses avantages, ne l'utilisez pas. Ce n'est pas DSX contre Dart ordinaire. C'est DSX contre JSX, plus les 2 sont proches, mieux c'est.

La bonne nouvelle est que même si cela a été adopté par l'équipe Flutter (qui n'est probablement pas basée sur ce fil), personne ne serait FORCÉ de l'utiliser. C'est une OPTION. Je ne comprends pas pourquoi c'est si chargé émotionnellement que certaines personnes pourraient aimer écrire du code avec une syntaxe que vous n'aimez pas...

@tehfailsafe , merci d'avoir écouté !!! Vous avez mis le doigt sur la raison pour laquelle une telle résistance à quelque chose qui rendra les autochtones de React vraiment heureux.

Je me fiche de ce que les autres aiment ou n'aiment pas. Mais je me soucie des fonctionnalités qui m'aident à progresser dans mon application. Les ressources sont limitées et je préférerais avoir un bon lecteur vidéo/flux, des vues enfant natives et un format graphique vectoriel.

@b-strauss, Une fois que les fans de React Native passeront à Flutter, il y aura des tonnes de personnes pour aider sur ces autres choses nécessaires. La priorité 1 est de voler la part d'esprit de React Native et de rendre aussi simple que possible le déplacement des personnes de React Native.

Flutter, d'autre part, n'a pas de langage de balisage. Je n'ai pas encore vu de raison d'investir des ressources dans quelque chose de moins dynamique et moins expressif.

@b-strauss, En quoi le DSX est-il "moins dynamique" et "moins expressif" que le Dart ordinaire ? DSX est Dart n'avez-vous pas essayé le transpiler.

@yuriy-manifold, merci.

La question n'est pas "JSX est-il utile pour React?" la question est "est-ce que quelque chose comme JSX est utile pour Flutter?".

@b-strauss, bien sûr que oui. ce n'est pas utile pour les développeurs Flutter actuels, mais c'est très utile pour les concepteurs qui peuvent produire du CSS à partir de leurs outils, c'est très utile pour les personnes investies dans la plate-forme React Native.

@alexkrolick , très bonnes observations.

@cbazza

ce n'est pas un remplacement, c'est une option pour les personnes qui aiment JSX.

Je comprends... Cela ne m'affecterait pas de cette façon, mais comme je l'ai déjà dit, il manque actuellement des fonctionnalités dont j'ai besoin pour créer une application flottante.

Une fois que les fans de React Native auront migré vers Flutter, il y aura des tonnes de personnes pour aider sur ces autres choses nécessaires. La priorité 1 est de voler la part d'esprit de React Native et de rendre aussi simple que possible le déplacement des personnes de React Native.

Vous proposez donc à l'équipe Flutter de suspendre les fonctionnalités pour quelque chose qui est discutable et qui peut ou non attirer une fraction d'un sous-ensemble spécifique de développeurs Web ?

En quoi le DSX est-il "moins dynamique" et "moins expressif" que le Dart ordinaire ? DSX est Dart n'avez-vous pas essayé le transpiler.

Chaque DSL est par définition moins expressif qu'une GPL. Avec DSX, comment masquer conditionnellement un widget ? Comment parcourir une collection et mapper chaque élément sur un widget ? Comment utiliser un interrupteur ? Vous devez maintenant créer une syntaxe et une sémantique pour les constructions que vous avez déjà dans votre GPL. Alors pourquoi inventer le DSL en premier lieu ?

bien sûr que c'est le cas. ce n'est pas utile pour les développeurs Flutter actuels, mais c'est très utile pour les concepteurs qui peuvent produire du CSS à partir de leurs outils, c'est très utile pour les personnes investies dans la plate-forme React Native.

Ce n'était pas la question… Quels problèmes un DSL résoudrait-il que vous ne pouvez pas résoudre en ce moment ? Tu n'arrêtes pas de dire que c'est mieux, pourquoi c'est mieux ? Je n'ai aucun doute que DSX attirerait des gens de JSX. Je sais que les gens n'aiment pas les choses qui sont différentes. Et la familiarité semble être le seul argument. Alors pourquoi ne pas utiliser CSS ?
Pourquoi ne pas utiliser JavaScript ? Plus de gens savent comment les utiliser que Dart.

Si vous concevez votre système en vous basant sur quelque chose d'autre dans le seul but d'être familier, vous n'innovez pas vraiment.

@b-strauss pour être clair, JSX compile en appels de fonction (dans les appels React à createElement(ComponentClass) , dans Dart, il devrait s'agir de constructeurs).

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

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

Les seules constructions sont les transformations entre les noms d'éléments+attributs et les appels de fonction+arguments, et les expressions échappées ( {...} ).

• Avec DSX, comment masquer conditionnellement un widget ?

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

• Comment parcourir une collection et mapper chaque élément sur un widget ?

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

• Comment utiliser un interrupteur ?
  Pour autant que je sache dans Dart comme dans JS, vous ne pouvez pas utiliser un commutateur en ligne car ce n'est pas une expression. Si vous êtes en dehors de l'arborescence des widgets, vous pouvez simplement utiliser un commutateur normalement.

Vous proposez donc à l'équipe Flutter de suspendre les fonctionnalités pour quelque chose qui est discutable et qui peut ou non attirer une fraction d'un sous-ensemble spécifique de développeurs Web ?

@b-strauss, React Native n'est pas du développement Web, c'est du développement mobile multiplateforme qui est le principal concurrent de Flutter ; et oui JSX est comme une source de lumière, il attirera beaucoup de développeurs React Native. J'ai demandé cette fonctionnalité en août 2017, trop parlant trop peu d'action.

Chaque DSL est par définition moins expressif qu'une GPL. Avec DSX, comment masquer conditionnellement un widget ? Comment parcourir une collection et mapper chaque élément sur un widget ? Comment utiliser un interrupteur ? Vous devez maintenant créer une syntaxe et une sémantique pour les constructions que vous avez déjà dans votre GPL. Alors pourquoi inventer le DSL en premier lieu ?

Vous avez complètement tort. La bonne nouvelle est que je me suis trompé une fois aussi. La plupart (mais pas tous) des DSL essaient de recréer des constructions de programmation dans le balisage (et ce n'est pas très puissant), JSX introduit le balisage dans la programmation (en tirant pleinement parti du langage hôte). La différence est transformationnelle. La réponse à toutes vos questions est essentiellement d'utiliser la façon dont vous le faites dans Dart parce que c'est Dart. Tout ce qui se trouve entre '{}' est du code Dart à l'exception de l'opérateur de propagation. Ce sont toutes des expressions de fléchettes, mais vous pouvez également utiliser des fonctions anonymes qui renvoient une expression. Comme vous le voyez dans le transpiler une balise (\) est juste un nouveau sur un widget (new Text()).

Quels problèmes un DSL résoudrait-il que vous ne pouvez pas résoudre en ce moment ?

Pourquoi utiliser Dart quand on peut utiliser des zéros et des uns, n'est-ce pas tout ce qu'il faut pour résoudre n'importe quel problème informatique ?

Tu n'arrêtes pas de dire que c'est mieux, pourquoi c'est mieux ?

J'ai déjà donné mes raisons et je ne les répéterai pas ici. Les gens de JSX seront d'accord avec moi mais "chacun à soi".

Je n'ai aucun doute que DSX attirerait des gens de JSX. Je sais que les gens n'aiment pas les choses qui sont différentes. Et la familiarité semble être le seul argument. Alors pourquoi ne pas utiliser CSS ?
Pourquoi ne pas utiliser JavaScript ? Plus de gens savent comment les utiliser que Dart.

Oui, l'utilisation de CSS est logique pour faciliter le flux de travail concepteur-développeur. DSX prend en charge cela. L'avantage de Dart sur Javascript est la vitesse d'exécution (performance).

Si vous concevez votre système en vous basant sur quelque chose d'autre dans le seul but d'être familier, vous n'innovez pas vraiment.

Vous êtes tellement plein de mauvais préjugés qui vous empêchent très probablement d'atteindre votre plein potentiel. Ouvrez votre esprit, essayez différentes choses.

@alexkrolick , merci pour les détails.

@cbazza

Vous êtes tellement plein de mauvais préjugés qui vous empêchent très probablement d'atteindre votre plein potentiel. Ouvrez votre esprit, essayez différentes choses.

Je vais me désabonner de ce numéro maintenant. S'il vous plaît, ne me mentionnez plus jamais ici ou ailleurs, merci.

@b-strauss

Désolé mec, je ne voulais pas te blesser... J'essayais juste de te guider doucement tout en essayant de gérer mes propres frustrations. Nous sommes tous des humains après tout.

@cbazza Pouvez-vous m'envoyer un e-mail s'il vous plaît ? [email protected]

Déjà fait cette proposition dans l'ancien fil mais je pense toujours que c'est un point important

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

Je suis d'accord dans le but de simplifier le flottement qui ne veut pas utiliser la syntaxe de type JSX, et je soutiens également le concept de division en plusieurs widgets, mais maintenant cela me donne l'impression que l'ère MVC est de retour dans jquery. Un tel scénario qu'il y avait un widget simple, avec un rembourrage, une bordure et une mise en page centrale pour plus tard, de nombreux symboles "}" affectent sérieusement la lisibilité. Cependant, c'est un widget intégral, je ne veux pas le diviser, tout utile Solution? Bien que mon anglais soit médiocre, je m'efforce d'exprimer mes pensées.

Seigneur aide nous tous.

Ok, ça ne va nulle part. Il ne semble pas que quelqu'un soit sur le point de changer de camp de si tôt. Nous devons absolument parvenir à une sorte de compromis ici. Bien sûr, "pro-DSX" vs "anti-DSX" n'a pas vraiment de compromis satisfaisant à distance, ce qui est une réalisation frustrante. Pourrions-nous éventuellement recadrer nos positions pour qu'elles soient plus compatibles?

@naiveaiguy "ils" peuvent avoir leur DSX.
Si l'équipe Flutter ne l'implémente pas, il peut s'agir d'une initiative open source.
Cela ne signifie pas que l'approche pure-Dart telle qu'elle est maintenant ne fonctionnera plus.
Les deux mondes peuvent coexister.

Je suis tellement d'accord avec @zoechi qu'ils peuvent coexister ... c'est tout et je pensais que cela avait été réglé sur l'ancien fil

@lrhn

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.

Bravo, c'est tout à fait ça.

Dans React, vous pouvez le faire de 4 façons (et je viens de découvrir les 2 autres façons aujourd'hui !!!)

(1) Vous pouvez utiliser JSX (c'est ce que j'aime)
https://reactjs.org/docs/introducing-jsx.html

(2) Vous pouvez utiliser la manière originale (qui est similaire à Flutter)
https://reactjs.org/docs/react-without-jsx.html

À la fin du lien ci-dessus, ils mentionnent même 2 projets communautaires prometteurs

(3) Syntaxe hyperscript pour le balisage React.js
https://github.com/mlmorg/react-hyperscript

(4) Syntaxe concise pour l'hyperscript.
https://github.com/ohanhi/hyperscript-helpers

Avoir des alternatives est une bonne chose, il est révolu le temps où vous pouviez obtenir une Ford dans n'importe quelle couleur que vous aimiez tant qu'elle était noire :)

@naiveaiguy pourquoi est-ce un problème pour vous s'il y a l'approche actuelle et DSX ?
(c'est ce que je déduis de vos votes négatifs)

@naiveaiguy "ils" peuvent avoir leur DSX.
Si l'équipe Flutter ne l'implémente pas, il peut s'agir d'une initiative open source.
Cela ne signifie pas que l'approche pure-Dart telle qu'elle est maintenant ne fonctionnera plus.
Les deux mondes peuvent coexister.

Je suis entièrement d'accord avec cela. Bien que je pense que cela devrait être une solution enfichable plutôt qu'une solution prête à l'emploi. Avoir une norme qui fonctionne mais être capable de personnaliser l'expérience avec des choses supplémentaires est un excellent paradigme. De cette façon, l'équipe Flutter peut rester concentrée sur (ce que je pense être) des problèmes plus pertinents, la communauté peut expérimenter différents outils/solutions, puis nous pouvons avoir une discussion avec plus de données et d'expérience avec DSX ou toute autre alternative au courant méta.

Avoir des alternatives est une bonne chose, le temps où vous pouviez obtenir une Ford dans n'importe quelle couleur est révolu.
aimé tant qu'il est noir :)

Vrai que. Cependant, je pense que nous pouvons tous convenir que nous ne voulons pas que Dart/Flutter devienne un autre écosystème JS/Web Frontend. Flutter n'est même pas encore sorti de la version bêta et nous voulons déjà qu'il ait 2 normes pour quelque chose d'un peu subjectif.

Dans React, vous pouvez le faire de 4 façons (et je viens de découvrir les 2 autres façons aujourd'hui !!!)

La plupart sont axés sur la communauté bien que React s'y réfère. Bon à mi-chemin. Désormais, seuls 2 d'entre eux sont officiellement pris en charge : le mode React.createElement et le mode JSX, qui est un wrapper sur l'autre. La valeur de JSX est notoire dans ce contexte, mais ce n'est pas si clair ici. Dans cet esprit, pouvons-nous atteindre le milieu en n'ayant qu'une seule norme officielle et les documents faisant référence à DSX chaque fois que cela est pertinent ?

Je pense que l'équipe Flutter devrait se concentrer sur les fonctionnalités manquantes qui empêchent vraiment les développeurs de créer des applications. Je ne peux pas recommander Flutter à mes responsables si nous ne pouvons même pas ajouter le support de Maps et que le développement d'une fonctionnalité de caméra prend 2 semaines.

Gardez à l'esprit que je ne ferme pas la porte à DSX pour toujours. Peut-être que cela deviendra la solution pour la construction d'interfaces utilisateur, mais nous avons besoin que la communauté l'expérimente pour prendre cette décision.

@zoechi Personnellement, je ne crois pas que les deux idées puissent coexister dans l'état actuel de Flutter - nous ne devrions vraiment pas encourager une scission de cette nature si tôt - mais à ce stade, cela semble être le seul compromis.

@naiveaiguy

Personnellement, je ne crois pas que les deux idées puissent coexister dans l'état actuel de Flutter - nous ne devrions vraiment pas encourager une scission de cette nature si tôt

Pourriez-vous être plus précis quant à la raison pour laquelle ils ne peuvent pas coexister ? (étant donné que DSX n'est que du sucre syntatique ; ou comme le dit @emalamela "juste un emballage de la manière actuelle").

Aussi pourquoi est-il trop tôt pour fournir une syntaxe différente pour exactement la même chose ? Je demande essentiellement pourquoi est-il nécessaire de retarder cela, qu'est-ce qui serait différent à l'avenir qui n'est pas encore là en ce moment ?

@emalamela

Cependant, je pense que nous pouvons tous convenir que nous ne voulons pas que Dart/Flutter devienne un autre écosystème JS/Web Frontend.

Personnellement, je préfère ne pas mettre de limites à ce que les gens peuvent faire avec Dart/Flutter. Laissez le marché/la communauté décider. Fondamentalement, si ce qui est créé n'ajoute pas de valeur, les gens ne l'utiliseront pas et il mourra. S'il devient populaire, c'est parce que la communauté l'a trouvé utile et l'a apprécié. Pas besoin de choisir les gagnants et les perdants pour le moment.

La seule chose qui m'empêche d'essayer Flutter est le fait qu'ils ont choisi de ne pas utiliser JSX.
IMHO JSX est le meilleur choix pour exprimer la hiérarchie des composants

J'ai entendu parler de Flutter, j'ai voulu essayer, j'ai immédiatement arrêté même en considérant que la minute où j'ai vu la syntaxe, ce qui est dommage car il y a de fortes chances que ce soit une excellente technologie. pour fabriquer des produits.

Je fais du développement React/React Native depuis 2,5 ans, sacrifier l'effet de levier de productivité offert par la syntaxe JSX lorsqu'il s'agit de décrire l'interface utilisateur, c'est beaucoup demander. J'envisagerais sérieusement de passer du temps à tout savoir sur Flutter et à étudier s'il vaut la peine de passer à une telle fonctionnalité lorsqu'elle est prise en charge par défaut.

Je ne peux même pas imaginer le nombre d'adoptants/utilisateurs/devs potentiels que Flutter perd à cause de cela, reviendra dans les prochains mois.

Je ne peux même pas imaginer le nombre d'adoptants/utilisateurs/devs potentiels que Flutter perd à cause de cela, reviendra dans les prochains mois.

Ouais, 44 Mio l'ont trouvé assez important pour voter :D

Ouais, 44 l'ont trouvé même assez important pour voter :D

Lorsqu'elle est triée par "upvote", cette demande de fonctionnalité est répertoriée 7ème sur la liste des 3131 tickets ouverts.

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

@cbazza Je ne veux pas m'opposer à la fonctionnalité mais des commentaires comme "si vous ne faites pas x alors horriblement y arrivera" sont tout simplement ridicules.

Je fais du développement React/React Native depuis 2,5 ans, sacrifier l'effet de levier de productivité offert par la syntaxe JSX lorsqu'il s'agit de décrire l'interface utilisateur, c'est beaucoup demander. J'envisagerais sérieusement de passer du temps à tout savoir sur Flutter et à étudier s'il vaut la peine de passer à une telle fonctionnalité lorsqu'elle est prise en charge par défaut.

@sonaye

Puisque vous avez mentionné la productivité, pouvez-vous fournir un exemple qui montre clairement la perte de productivité liée à l'utilisation de Flutter's Pattern au lieu de JSX ? L'exemple doit être construit sur la base d'une connaissance suffisante de JS et de Dart pour pouvoir coder ledit exemple. Je crois que si nous ne tenons pas compte de cela, nous comparons également des langages de programmation, ce qui n'est pas la même discussion.

Lorsqu'elle est triée par "upvote", cette demande de fonctionnalité est répertoriée 7ème sur la liste des 3131 tickets ouverts.

@cbazza

C'est aussi celui qui a été le plus dévalorisé. C'est assez controversé.

@emalamela ,

C'est aussi celui qui a été le plus dévalorisé. C'est assez controversé.

Étant donné que cette demande de fonctionnalité est une alternative à la méthode actuelle et qu'elle ne change pas la méthode actuelle, il ne devrait y avoir aucune controverse ; si vous n'aimez pas JSX/DSX, continuez à programmer comme vous le faites aujourd'hui.

La soi-disant controverse n'existe que parce que l'équipe Flutter doit travailler pour permettre à la communauté de faire DSX correctement. Si les outils Flutter (compilateur, analyseur, support ide, etc.) prenaient en charge le prétraitement avec des cartes source, DSX aurait été fait il y a longtemps, et très probablement d'autres innovations/idées de langage, de développeurs tiers, se seraient également produites.

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

Devient:

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

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

@emalamela L'argument pour et contre JSX a été épuisé par la discussion, il y a beaucoup de matériel que vous pouvez rechercher. Je ne fais que partager mon avis personnel.

Tout d'abord, la lisibilité du code. Je peux immédiatement avoir une idée claire et nette de la structure de l'interface utilisateur dans JSX (prend quelques secondes), le modal mental est très visuel. Deuxièmement, la convivialité. Je dirais que JSX peut être utilisé même sans connaître JS/Dart ou quoi que ce soit sur l'API sous-jacente. C'est très approprié pour quelqu'un qui vient d'apprendre la programmation, ou pour quelqu'un qui fait partie de mon équipe, les concepteurs peuvent désormais coder l'interface utilisateur.

La description de l'application est complètement déclarative (pas seulement expressive), lorsque vous travaillez sur un gros projet avec des centaines de composants, cette façon de décrire l'UI fait une énorme différence (il faut l'essayer pour vraiment l'apprécier). Je n'aimais pas JSX quand je l'ai vu pour la première fois, une fois que je l'ai utilisé, je me sentais bien, c'est ainsi que je veux décrire l'interface utilisateur à partir de maintenant, c'était une percée claire dans la façon dont j'aborde la construction d'interfaces.

Il ne s'agit pas d'écrire moins de lignes de code, il ne s'agit pas d'avoir un "sucre de syntaxe", il s'agit de construire des outils pour les humains. Je suis également contre l'argument selon lequel tout le monde devrait utiliser JSX, c'est ridicule. Vous utilisez l'outil qui vous permet de faire votre travail plus rapidement avec moins de confusion, dans le cas de beaucoup (y compris moi-même), ce serait JSX (ou DSX dans le cas de Flutter), c'est tout.

Je viens de React et j'essaie Flutter pour la première fois. C'est vraiment étrange que l'équipe Flutter n'ait pas la syntaxe JSX, je veux dire sérieusement ! Dans le monde JS, JSX est extrêmement répandu dans toutes les alternatives React de nos jours ! JSX est super convivial pour les développeurs. S'il vous plaît implémentez ceci dès que possible, afin que vous puissiez aider à développer la communauté.

Vous pouvez dire que JSX (ou DSX dans ce cas) est un gros problème simplement en recherchant le nombre de commentaires dans ce numéro.

JSX est quelque chose que vous ne savez pas que vous aimez jusqu'à ce que vous l'essayiez. C'est bizarre au début d'avoir du balisage dans votre code mais ensuite ça devient génial.

Cela semble inutile pour les gars qui connaissent déjà le flutter/dart, je comprends. Mais pour quelqu'un qui n'a jamais touché aux fléchettes (comme moi), JSX est beaucoup plus facile à démarrer et c'est le but. Si vous voulez que plus de gens viennent et commencent à construire beaucoup plus de choses géniales, l'outillage doit être plus facile.

Et, comme @eseidelGoogle (https://youtu.be/h7HOt3Jb1Ts?t=2m41s) l'a dit à l'autre gars "Flutter est un moyen d'écrire sur iOS et Android dans une seule base de code. Nous essayons de rendre cela rapide et facile [. ..] Flutter parle jusqu'au matériel [...] Nous avons une approche très stratifiée, vous pouvez donc en prendre aussi peu ou autant que vous le souhaitez. [...] Nous avons beaucoup investi dans l' outillage ."

Implémentez JSX, s'il vous plaît.

Je suis un fan de Dart et aussi un gros utilisateur de React. Je trouve toujours Dart plus clair et plus maintenable que JSX. Donc, je pense que JSX/DSX pourrait et devrait peut-être être implémenté de manière communautaire.

@rajaraodv Ce n'est pas parce que Flutter est promu en tant que framework de style réactif que c'est juste une saveur de ReactJS.
D'après la plupart des commentaires, j'ai l'impression que les gens ont du mal à accepter que quelque chose de nouveau ne soit pas la même chose que ce qu'ils connaissent déjà.

Vous pouvez essayer de travailler avec Flutter pendant un certain temps tel qu'il est actuellement, puis fournir des arguments appropriés expliquant pourquoi vous pensez que JSX/DSX serait mieux que Dart ordinaire de manière factuelle au lieu de simplement "par préférence personnelle" ou "parce que c'est mieux" .

@zoechi , il vous manque quelque chose : flutter a été inspiré de React, selon la doc Flutter.
Peut-être que ce n'est que mon problème. J'ai vraiment l'impression d'avoir du mal à lire le code de l'interface utilisateur, même s'il est en syntaxe Dart 2.

flutter a été inspiré de React Native

Je ne vois pas en quoi cela dit "tout est pareil sauf que le langage s'appelle Flutter au lieu de JS".

J'ai vraiment l'impression d'avoir du mal à lire le code UI

et vous prétendez que la seule solution imaginable à cela est DSX ?

Avez-vous pensé que Flutter n'est même pas 1.0 et que le support IDE peut s'améliorer avec le temps ?

Il n'y a eu que les premières petites étapes prises récemment pour obtenir une meilleure prise en charge de Flutter IDE dans l'éditeur de code, comme des correctifs rapides ("wrap xxx") et des étiquettes de fermeture.

Il existe des possibilités illimitées pour améliorer l'expérience des développeurs et la plupart de cette discussion est comme
"Le flutter n'est pas encore parfait et nous avons donc besoin de DSX"
généralement sans arguments concrets sur comment ou pourquoi DSX résoudrait ou améliorerait cela.

@zoechi ,

Vous pouvez essayer de travailler avec Flutter pendant un certain temps tel qu'il est actuellement, puis fournir des arguments appropriés expliquant pourquoi vous pensez que JSX/DSX serait mieux que Dart ordinaire de manière factuelle au lieu de simplement "par préférence personnelle" ou "parce que c'est mieux" .

Encore une fois, Plain Dart ou DSX est simplement une question de style, inutile de discuter de ce qui est le mieux. C'est juste une préférence personnelle et les gens ont leurs raisons de choisir l'un ou l'autre.

Ce qui s'est passé dans le monde React, c'est qu'une fois que vous utilisez JSX, vous ne revenez tout simplement pas en arrière. Comme d'autres l'ont indiqué ci-dessus, vous devenez accro à JSX après l'avoir utilisé pendant un certain temps. JSX a été adopté par d'autres en dehors du monde de React (Typescript, Vue) et convient parfaitement à Flutter.

et vous prétendez que la seule solution imaginable à cela est DSX ?

Ce dont la communauté a besoin, ce sont des capacités de prétraitement génériques avec prise en charge de la carte source intégrée dans les outils Dart (compilateur, analyseur, IDE, etc.) afin que DSX ou quoi que ce soit de mieux puisse être développé par la communauté et entièrement intégré à Flutter (débogueur, auto- complet, etc.).

Il existe des possibilités illimitées pour améliorer l'expérience des développeurs et la plupart de cette discussion est comme
"Le flutter n'est pas encore parfait et nous avons donc besoin de DSX"
généralement sans arguments concrets sur comment ou pourquoi DSX résoudrait ou améliorerait cela.

Bien sûr, ce ticket ne concerne pas une chose générique "améliorer l'expérience du développeur". C'est très spécifique et il s'agit d'obtenir le support JSX dans Flutter. La communauté veut que DSX soit une alternative à la méthode classique de Dart.

Je ne me vois pas l'utiliser (mais je suis prêt à l'essayer). Je ne pense pas que ce soit une solution miracle, mais il y a tellement d'enthousiasme que cela en vaut la peine.

Je pense que Google devrait supprimer les obstacles linguistiques pour permettre à la communauté de construire ce qu'elle veut.

Je ne suis au courant d'aucun obstacle empêchant quelqu'un en dehors des équipes Flutter/Dart de Google d'écrire un truc de type JSX pour Dart/Flutter. J'aimerais voir des bugs sur ceux-ci si quelqu'un essaie. (Il est aussi possible que je les ai ratés dans les commentaires ci-dessus, puisque j'avoue ne pas avoir lu chaque mot de ce très long bug.) :)

Merci! Content de voir un tel engouement !

@eseidelGoogle ,

Comment Intellij et/ou VS Code (avec Dart-Code) pourraient-ils définir des points d'arrêt et parcourir le code à partir d'un fichier .dsx ? (Je veux dire que ce n'est pas un fichier .dart). Qu'en est-il de la fonctionnalité d'auto-complétion à partir du fichier .dsx (comme avec un fichier .dart) ?

Vous avez beaucoup investi dans l'outillage, mais l'outillage ne prend pas en charge le prétraitement (avec des cartes source) d'un nouveau langage (comme DSX) qui transpile en Dart/Flutter de manière transparente.

Un transpileur est disponible mais il n'y a pas de moyen facile de l'intégrer complètement :
https://spark-heroku-dsx.herokuapp.com/index.html

PS Ce billet n'est que la moitié des commentaires !!!
https://github.com/flutter/flutter/issues/15922

@cbazza y a-t-il un dépôt avec ce compilateur quelque part ? Ce serait formidable de partager le code et d'impliquer la communauté dans le piratage, même s'il n'est pas parfait.

@jonahwilliams , non le code du transpiler DSX n'a ​​pas été publié car il est bien trop tôt pour cela.
Vous pouvez simplement utiliser 2 fichiers équivalents écrits à la main (.dsx et .dart) pour tester les capacités de prétraitement telles que les points d'arrêt, la progression, la saisie semi-automatique, etc.

Une fois que les outils prennent en charge le prétraitement avec une sorte de cartes source, je peux l'ajouter au transpiler et être débloqué. Cela permettrait également aux autres d'expérimenter selon leurs désirs.

Je ne travaille pas sur Flutter, mais il semble en quelque sorte déraisonnable d'exiger certains outils pour en faire profiter les autres, mais aussi de refuser de publier tout code source précoce ou des exemples de ce que vous souhaitez intégrer à l'outil.

Pour ce que ça vaut, je ne connais aucun langage ou boîte à outils qui fournisse des crochets de prétraitement de quelque sorte que ce soit - probablement parce que ce n'est tout simplement pas facile, il y a beaucoup de cas et d'hypothèses autour du langage et de la syntaxe.

Si vous avez généré des cartes source (https://pub.dartlang.org/packages/source_maps), j'imagine qu'obtenir au moins un support de base dans un IDE est assez trivial, indépendant de Dart/Flutter. Mais encore une fois, ce ne sont que des conjectures sans savoir ce que fait votre outillage et comment vous vous attendez à ce qu'il fonctionne.

@matanlurey , la prise en charge du prétraitement via les cartes source est un mécanisme générique qui ne dépend d'aucun transpileur spécifique. C'est une fonctionnalité destinée à prendre en charge n'importe quel futur langage imaginable. Le navigateur/débogueur Chrome le supporte assez bien et je peux déboguer n'importe quel langage qui transpile en JS.

Pour les tests, vous pouvez proposer n'importe quel type de transpileur simple pour montrer comment utiliser les cartes source. Par exemple, écrivez un transpileur trivial qui génère du code Dart/Flutter avec une ligne vide entre chaque ligne du fichier d'origine. (.d2 => .dart, .d2 est un fichier Dart/Flutter, le fichier .dart contiendra une ligne vide entre chaque ligne du fichier d'origine).

Oui, je peux travailler sur la génération d'une carte source pour un fichier de test.

Flutter est actuellement réticent à essayer de plaire à NativeScript, ReactNative, Android, Web et autres développeurs habitués à des mises en page XML similaires. Ils ont des choses plus importantes à faire, alors dissolvons-nous et allons nous coucher.

Je souhaitais à Amy, partisane de la syntaxe JSX, de passer quelques jours à vraiment travailler avec Flutter avant de continuer à se lamenter. Je viens d'un système basé sur Xaml, mais je m'y suis rapidement habitué. Essayez-le vraiment.

@escamoteur
Hé, escamoteur. Pensez-vous que je n'ai pas passé beaucoup de temps à apprendre le flutter ?
Dans le flutter.io/tutorials/layout/, à la fin de la section "Packing widgets", le code que le tutoriel a donné ne fonctionne pas.
J'ai mentionné le problème sous le bloc de problème de flottement, mais personne ne veut s'en soucier.

• Code de fléchette : main.dart
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/main.dart

• Pubspec : pubspec.yaml
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/pubspec.yaml

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

@JonathanSum y a-t-il un lien entre votre commentaire et le sujet de ce problème ?

@zoechi
escamoteur a déclaré qu'il espère que le promoteur de JSX Syntax passera quelques jours à vraiment travailler avec Flutter avant de continuer à se lamenter.
Ce commentaire montre que nous avons vraiment passé de nombreuses journées à travailler avec Flutter, et la demande de JSX est vraiment notre sentiment du fond du cœur.

Group Dart : "La syntaxe Dart est bien meilleure et JSX/DSX n'est tout simplement pas bon"
Groupe JSX/DSX : "La syntaxe JSX/DSX est bien meilleure et Dart n'est tout simplement pas bon"

Je ne peux pas être le seul à voir ça ? Les deux parties font valoir des points valables en faveur et contre leur position. Je pense que ce qui est perdu ici, c'est que @cbazza a non seulement eu des critiques MAIS AUSSI A FAIT QUELQUE CHOSE À CE SUJET. Essayer de combler le fossé entre les développeurs Web/réagir/réagir-natif et Flutter afin de bénéficier de Flutter.

Et mes 2 cents... En tant que développeur full stack, j'ai une expérience avec un large éventail de langages et d'approches... JSX est l'une de mes façons préférées d'écrire du code et j'espère qu'il y aura une syntaxe alternative à Darts... Et je ne dis pas que la syntaxe actuelle est mauvaise, c'est juste que je préfère le style JSX.

Je ne suis pas d'accord avec cette citation du groupe JSX/DSX

Dart n'est tout simplement pas bon

Dart est un langage très bon et robuste, personne ne dissipe le langage. La discussion ne porte pas sur Dart, mais sur une couche synthétique que la plupart des développeurs d'interface utilisateur utilisent déjà aujourd'hui, et nous proposons que Flutter incorpore quelque chose comme ça.

• Android a des mises en page XML.
• iOS a Storyboard XIB (XML)
• GTK + a XML pour Pango etc.
• Qt a QML (comme YAML)
• Xamarin a XAML

La plupart de ces frameworks et langages ont des langages de balisage d'interface utilisateur qui séparent la logique de la vue de la logique du contrôleur. Ensuite, React propose une approche différente (que nous proposons ici) et je pense que nous devons convenir que RN vole en ce moment en termes de croissance et de popularité des utilisateurs, et je me trompe peut-être, mais principalement à cause de JSX.

...

Est-ce vraiment une proposition si folle que nous devions obtenir ce genre de retour de la part de l'équipe/des utilisateurs de Flutter ?

@birkir et tous apportent une foule de problèmes que Flutter n'a pas \o/
Il n'y a pas besoin d'une autre langue.
Vous pouvez également séparer la vue dans Flutter, même avec la même langue.

@birkir ce fil est à 100% sur Dart et la syntaxe.

La discussion ne porte pas sur Dart, mais sur une couche synthétique que la plupart des développeurs d'interface utilisateur utilisent déjà aujourd'hui, et nous proposons que Flutter incorpore quelque chose comme ça.

Il ne s'agit donc pas de Dart... mais Flutter doit utiliser autre chose que Dart pour les mises en page ? On dirait que vous dites que Dart n'est pas assez bon tout en affirmant que cela n'a rien à voir avec Dart ?

Je ne pense pas que cela importe à ce stade, l'équipe Flutter a vu ces commentaires (sur la demande d'une approche JSX/DSX) et ils veulent continuer sur leur chemin initial. Je pense que cela pourrait être mieux géré, mais il ne semble pas qu'ils soient opposés à ce que la communauté crée des solutions.

Je suis content qu'il existe une autre option multiplateforme... Apple sera-t-il le prochain à proposer quelque chose ? Et peut-être verront-ils ce que beaucoup d'entre nous aiment à propos de react/react-native ? IDK s'ils ont quelque chose à cuisiner.

l'équipe Flutter a vu ces commentaires (sur la demande d'une approche JSX/DSX) et ils

Ce bogue est toujours ouvert car nous n'avons pas compris ce que nous voulons faire ici. Nous regardons avec impatience les expériences (par exemple celles de cbazza) pour voir comment les gens les utilisent. Nous prévoyons, à un moment donné, de fournir un crochet dans le système de construction pour des outils codegen tels que celui-ci, même si ce n'est pas quelque chose que nous sommes susceptibles de faire dans un avenir proche. À long terme, nous espérons utiliser ce que nous apprenons ici pour influencer le développement de Dart en tant que langage. Cela pourrait signifier ajouter quelque chose comme E4X/H4X/JSX/DSX à Dart lui-même. Ou peut-être apprendrons-nous que personne ne finit vraiment par l'utiliser, alors nous ne ferons rien. Ou peut-être que tout le monde a besoin de quelque chose de différent, alors les crochets codegen et les packages personnalisés comme ceux de cbazza sont la réponse. Nous ne savons pas encore.

@jstansbe - Apple pense que multiplateforme signifie IPhone, IPad et Mac OS. Ils sont plus susceptibles d'ajouter des tourelles au-dessus du jardin clos que de construire quelque chose de multiplateforme :)

Je pense que s'il serait possible d'indenter et de formater le widget d'une autre manière, ce serait plus similaire à jsx et convivial pour les utilisateurs qui ont de l'expérience avec xml et html (presque tous les développeurs Android) ... vérifiez ce code dans codelab

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

vérifier cette fléchette au code jsx

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

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

et comparer avec cet autre format plus htmlish

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

c'est un peu plus similaire et maintenant vous n'avez plus qu'à voir de gauche à droite pour remarquer les différents widgets similaires à html/xml/jsx

les attributs de l'élément (widget) ont plus d'indentation que les nouveaux widgets, ce qui rend plus clair la possibilité de comprendre et de vérifier le code

ce serait super si je pouvais avoir une indentation automatique pour ce format sur les différentes ides, en ce moment je le fais à la main....

Après avoir lu tous les commentaires ici et discuté en privé avec mes amis (développeurs d'applications mobiles natives, java/kotlin/objective-c/swift), mon observation :

Les gens demandent deux choses,

• __Meilleure lisibilité et écriture plus facile__. L'imbrication profonde mélangée à certains bruits de syntaxe (parenthèses, point-virgule, new , child , children ) est ennuyeuse dans la manière actuelle de coder.
• __Séparez le style/design du code__. La séparation visuelle est bonne pour la lecture (différencier le style du code impératif d'un coup d'œil) et une vraie séparation est bonne pour l'outillage (par exemple, IDE avec Layout Editor).

Il y a aussi principalement deux groupes avec des opinions différentes,

• Améliorer la syntaxe actuelle sans introduire une autre complexité pour résoudre le problème.
  Il y a déjà virtual "closing tag" comments new const dans cette direction.
• Introduction de langages de balisage supplémentaires (comme JSX ou XML) pour résoudre le problème.

Vous ne pouvez pas facilement conclure lequel est le meilleur actuellement. Alors laissez la communauté faire ses expériences d'abord et prendre la décision finale (accepter ou rejeter) plus tard.

Les commentaires de balise de fermeture virtuelle @hooluupog fonctionnent déjà dans IntelliJ, AS, VSCode depuis un certain temps

@Hixie

Ce bogue est toujours ouvert car nous n'avons pas compris ce que nous voulons faire ici. Nous regardons avec impatience les expériences (par exemple celles de cbazza) pour voir comment les gens les utilisent.

Les gens ne peuvent pas utiliser mes expériences car elles ne peuvent pas être intégrées de manière transparente dans Flutter ; cela reste donc une expérience extérieure/en ligne où les gens ne peuvent que voir le potentiel.

Nous prévoyons, à un moment donné, de fournir un crochet dans le système de construction pour des outils codegen tels que celui-ci, même si ce n'est pas quelque chose que nous sommes susceptibles de faire dans un avenir proche. À long terme, nous espérons utiliser ce que nous apprenons ici pour influencer le développement de Dart en tant que langage.

Pouvez-vous être plus précis quant au moment où pouvons-nous nous attendre à un mouvement sur les modifications du système de construction pour prendre en charge le prétraitement ? Parlons-nous d'un mois, d'un quart, de six mois, d'un an, de 2 ans, d'une décennie, d'un jubilé, etc.

Cela pourrait signifier ajouter quelque chose comme E4X/H4X/JSX/DSX à Dart lui-même.

Veuillez lire les premiers paragraphes de la spécification JSX pour voir qu'il n'est pas nécessaire de modifier le langage Dart car JSX/DSX n'a ​​pas de sémantique et n'est pas destiné à être implémenté par des moteurs ou incorporé dans des langages. Il est destiné à être utilisé dans un préprocesseur (transpiler). DSX pourrait être utilisé avec Flutter & on Web pour faire de React-Dart exactement comme React.js mais avec le langage Dart.

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

Ou peut-être apprendrons-nous que personne ne finit vraiment par l'utiliser, alors nous ne ferons rien.

Comment les gens peuvent-ils utiliser quelque chose qui n'est pas disponible pour eux en premier lieu et ensuite conclure que rien ne doit être fait parce que les gens ne l'utilisent pas ? Cela me rappelle tellement l'imitation de Sean Spicer de Melissa McCarthy sur SNL à propos de "l'interdiction de voyager"... "l'utilisation circulaire du mot" :)

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

Ou peut-être que tout le monde a besoin de quelque chose de différent, alors les crochets codegen et les packages personnalisés comme ceux de cbazza sont la réponse. Nous ne savons pas encore.

Les capacités de prétraitement sont indispensables pour permettre l'expérimentation. Sans cela, rien n'avance et vous n'apprendrez rien de nouveau.

Les gens ne peuvent pas utiliser mes expériences

Je pense que vous sous-estimez à quel point les gens sont disposés à essayer des choses, même lorsqu'elles ne sont pas complètement polies. Par exemple, quelqu'un pourrait facilement écrire un script shell qui encapsule flutter run pour effectuer le prétraitement en premier, puis appeler flutter run . J'ai moi-même un script qui encapsule le rechargement à chaud pour faire quelque chose de similaire (je lance d'abord l'analyseur, puis seulement s'il réussit, j'envoie le signal de rechargement à chaud au script flutter ).

Pouvez-vous être plus précis dans le temps pour savoir quand pouvons-nous nous attendre à un mouvement sur les changements du système de construction

Pas vraiment (voir par exemple https://en.wikipedia.org/wiki/Forward-looking_statement pour savoir pourquoi il pourrait être difficile de faire de telles déclarations), mais probablement pas dans les semaines à venir.

il n'est pas nécessaire de changer la langue Dart

C'est tout à fait possible, en effet. Je dis simplement que sur la base de ces expériences, nous pouvons tirer un certain nombre de conclusions, allant de "ne rien faire" à "ajouter de nouvelles fonctionnalités radicales à la syntaxe du langage" et tout ce qui se trouve entre les deux. Le fait est que nous n'avons pas encore pris de décision et sommes très ouverts à apprendre ce qui doit être fait sur la base de toutes ces discussions et expériences.

Ajouter JSX au backlog et le laisser rivaliser, à la manière d'un gladiateur, avec les plus d'un million d'autres besoins urgents ?

React est écrit pour le Web et a donc besoin d'une solution simple pour écrire du HTML. JSX n'est pas devenu populaire parce que c'est la meilleure solution pour écrire des interfaces utilisateur, mais parce que c'est la meilleure solution pour écrire du HTML.

Flutter n'a pas cette contrainte, nous ne devrions donc pas nous contenter d'une solution médiocre et verbeuse pour les mauvaises raisons.

Si nous voulons réduire la verbosité, je préfère m'inspirer par exemple d'Anko (https://github.com/Kotlin/anko/wiki/Anko-Layouts). Là, vous pouvez définir de nouvelles variables locales n'importe où et utiliser des boucles for normales pour construire dynamiquement la liste des enfants, ce qui peut rendre le code plus facile à suivre. De plus, le LayoutBuilder deviendrait plus facile à regarder puisque chaque niveau d'imbrication est déjà une fonction lambda de toute façon (pas besoin de passer un lambda de constructeur supplémentaire). Quoi qu'il en soit, c'est juste pour l'inspiration et je ne pense pas que Flutter devrait copier ce 1:1.

React est écrit pour le Web et a donc besoin d'une solution simple pour écrire du HTML. JSX n'est pas devenu populaire parce que c'est la meilleure solution pour écrire des interfaces utilisateur, mais parce que c'est la meilleure solution pour écrire du HTML.

React Native n'est pas un développement Web et n'utilise pas HTML. Demandez aux développeurs React expérimentés (ou lisez entièrement ceci et l'autre fil JSX) et vous verrez que JSX est considéré par de nombreux développeurs React comme le meilleur moyen d'écrire des interfaces utilisateur.

Là, vous pouvez définir de nouvelles variables locales n'importe où et utiliser des boucles for normales pour construire dynamiquement la liste des enfants, ce qui peut rendre le code plus facile à suivre.

Cette déclaration démontre clairement que vous ne connaissez pas JSX. JSX (comme dans DSX) utilise toutes les constructions de programmation (boucles for, etc.) du langage d'hébergement (Javascript/Dart).

Ce ticket ne s'intéresse qu'aux fonctionnalités de type JSX, pour d'autres approches (comme Anko), veuillez créer votre propre ticket pour en discuter.

React Native n'est pas un développement Web et n'utilise pas HTML. Demandez aux développeurs React expérimentés (ou lisez entièrement ceci et l'autre fil JSX) et vous verrez que JSX est considéré par de nombreux développeurs React comme le meilleur moyen d'écrire des interfaces utilisateur.

React est sorti bien avant React Native. La conception originale de JSX est basée sur le rendu HTML, et non sur les interfaces utilisateur natives. Personne n'a été en mesure de montrer un seul argument convaincant pour ce que JSX fait mieux. En comparant

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

à

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

vous n'avez pas fait de comparaison à jour et vous mettez simplement plus de choses sur une seule ligne. Vous devez le comparer à :

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

Remarquez comment toutes les vilaines balises {<{<>} />} et fermantes </...> ont disparu.

Cette déclaration démontre clairement que vous ne connaissez pas JSX. JSX (comme dans DSX) utilise toutes les constructions de programmation (boucles for, etc.) du langage d'hébergement (Javascript/Dart).

Non, vous ne pouvez pas utiliser d'instructions if ou de boucles for (ou switch ou toute autre instruction) dans JSX :

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

Seules les expressions sont autorisées. Vous devez donc utiliser des opérateurs conditionnels ( c ? x : y , ce qui rend else if très moche) et Array.map etc. (qui peut aussi être très moche) ou déplacer des parties de votre code vers le en haut de la fonction de rendu ou dans une fonction d'assistance distincte. C'est la même chose avec Flutter, bien sûr. Anko n'a pas cette limitation et rend l'écriture de (certains) codes d'interface utilisateur plus naturelle.

Je pense que dans une discussion sur l'introduction de JSX, il est tout à fait valable et nécessaire de demander si c'est réellement la meilleure solution ou si nous pouvons trouver quelque chose de mieux. Sinon, nous gaspillerons des ressources sur les mauvaises tâches.

React est sorti bien avant React Native. La conception originale de JSX est basée sur le rendu HTML, et non sur les interfaces utilisateur natives.

La conception originale de JSX concerne une manière familière de créer/manipuler des structures arborescentes qui apparaissent spécialement lors du travail sur l'interface utilisateur ; pensez aux hiérarchies de composants (https://facebook.github.io/jsx/) qui apparaissent dans le développement Web, le développement natif, tout développement d'interface utilisateur, etc.

Personne n'a été en mesure de montrer un seul argument convaincant pour ce que JSX fait mieux.

C'est le point, nous ne cherchons pas à remplacer la méthode actuelle, nous cherchons à ajouter une méthode alternative familière aux développeurs de React.

Votre proposition Anko serait familière aux développeurs Android Kotlin, alors allez-y et proposez une spécification qui fonctionne avec la hiérarchie Flutter actuelle dans un ticket séparé. Une fois que j'aurai vu (ou essayé une version en ligne de votre spécification), je serais en mesure de voir si elle peut générer/interagir avec la hiérarchie actuelle des widgets Flutter.

Non, vous ne pouvez pas utiliser d'instructions if ou de boucles for (ou switch ou toute autre instruction) dans JSX :

Non pas que je vous recommande de le faire mais c'est possible : créez une fonction anonyme et appelez-la.

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

Je pense que dans une discussion sur l'introduction de JSX, il est tout à fait valable et nécessaire de demander si c'est réellement la meilleure solution.

Il n'y a pas de meilleure solution, il s'agit d'avoir le choix, d'avoir le choix d'utiliser quelque chose de familier qui correspond directement aux widgets Flutter et n'ajoute aucune surcharge.

Au fait, essayez ce qui suit sur mon transpiler en ligne à :
https://spark-heroku-dsx.herokuapp.com/index.html

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

et vous obtenez :

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

DSX est similaire à JSX mais pour Dart & Flutter, il a donc ses propres fonctionnalités qui sont décrites sur le lien ci-dessus.

quand je vois cela, j'obtiens des flashbacks à partir de mises en page xml d'Android. Je ne pense pas que ce soit une bonne idée de l'implémenter. Maintenant que vous n'avez même plus besoin d'écrire new et const , c'est encore mieux.

@charafau Pouvez-vous partager un exemple/img/lien de "mises en page xml d'Android" auxquelles vous faites référence ?

Non, @wkornewald. Si "JSX n'est pas devenu populaire parce que c'est la meilleure solution pour écrire des interfaces utilisateur, mais parce que c'est la meilleure solution pour écrire du HTML", pourquoi React utilise-t-il toujours JSX pour créer une application mobile et une application de bureau ? Même votre application de bureau Github, l'application mobile multiplateforme Walmart, l'application Tesla et Skype sont également conçues par RN.

React ne met pas de boucle for dans la balise JSX car le concept de React concerne le composant. La partie supérieure est la logique et la partie inférieure est le JSX, et c'est toujours comme ça. Tout est séparé en plusieurs composants et relié entre eux dans un grand composant.

En fait, la plupart des gens ici qui, contre JSX, ne peuvent que deviner que JSX est une sorte de HTML, XML ou une solution moins verbeuse.

@JonathanSum

la plupart des gens ici qui, contre JSX, ne peuvent que deviner que JSX est une sorte de HTML

Je pense que c'est plutôt parce qu'il n'y avait pas d'autres arguments en faveur de JSX/DSX autres que les préférences personnelles. C'est bien sûr, comme nous l'avons déjà mentionné ci-dessus, mais s'il vous plaît, n'impliquez pas que les gens sont contre JSX parce qu'ils ne le comprennent pas, alors qu'il n'y a pas de liste de bons arguments factuels qui montrent où JSX est meilleur que Dart.

Je pense que c'est plutôt parce qu'il n'y avait pas d'autres arguments en faveur de JSX/DSX autres que les préférences personnelles.

Pas vraiment, beaucoup ont été donnés avant, il suffit de lire entièrement les deux discussions. J'ai déjà mentionné ces 2 choses:
(1) Plus de trucs "enfant" et "enfants"
(2) facile à manipuler pour les outils tiers (parser, analyser et régénérer)

Avec (2), vous pouvez améliorer le balisage pour faire des choses impossibles avec juste Dart ; par exemple l'opérateur de propagation de DSX ou la génération de nombreux paramètres de fonction à partir d'un ensemble plus petit.

D'autres ont fourni beaucoup de bons points, mais je ne le creuse pas pour vous ;)

(1) comme mentionné, de telles choses peuvent également être modifiées/améliorées dans Dart et il y a déjà eu des discussions. Cela n'arrivera tout simplement pas avant la sortie de Dart 2.
Le simple fait de supposer que DSX permet toutes sortes de nouvelles fonctionnalités et que Dart ne le fait pas n'est pas vraiment un argument juste à mon avis.
(2) Je suis à peu près sûr que cela peut aussi bien être fait avec Dart et il existe bien sûr déjà un analyseur pour Dart.

D'autres ont fourni beaucoup de bons points, mais je ne le creuse pas pour vous ;)

Il n'est pas nécessaire de les creuser pour moi , mais cela revient fréquemment et vous pourrez peut-être convaincre les autres que vous avez réellement des arguments valables.
J'ai suivi la discussion et je ne me souviens pas de bons arguments factuels et c'est peut-être la même chose pour d'autres. Si vous les résumez, vous pouvez simplement poster un lien vers le suivant qui remet cela en question.

Comme discuté précédemment, je peux accepter la préférence personnelle comme un argument valable, mais si vous prétendez également avoir de nombreux arguments factuels, alors je pense qu'il est valable de demander à les faire remarquer.

Vous continuez à demander des "arguments valides" et quand ils vous sont donnés, vous les rejetez comme "le futur Dart aura ceci" ou "ce n'est pas un argument valable".

Le fait est qu'à l'heure actuelle, Dart/Flutter a des enfants bruyants partout lors de la construction d'un widget, contrairement à XML/DSX. À l'heure actuelle, c'est un argument très valable pour utiliser DSX pour supprimer ce bruit enfant/enfants. Pouvez-vous simplement accepter cela comme un argument valable? (juste parce que vous dites que Dart aura cela à l'avenir, cela ne rend pas l'argument invalide).

C'est aussi un fait que l'analyse XML est beaucoup plus simple que l'analyse du langage Dart complet et chaque langue a un analyseur XML, alors que seul Dart a un analyseur de langage Dart complet et complet. Pouvez-vous voir que c'est aussi un argument valable?

Il y a beaucoup d'arguments valables, ils ne sont tout simplement pas valables pour vous et c'est pourquoi j'ai arrêté d'en discuter. Si les gens sont intéressés par ce qui a été dit, il suffit de lire entièrement les 2 discussions sur JSX. Je n'ai aucun intérêt à vous convaincre d'utiliser DSX, vous êtes satisfait de Dart ordinaire, qu'il en soit ainsi ; Je ne suis pas.

Arguments pour une syntaxe DSX facultative :

1) Intégrer et attirer plus de développeurs venant de React (web et natif)
2) Meilleure expérience de portage des composants React Native dans les widgets Flutter
3) Pilote la cohérence des propriétés enfant/enfants dans les widgets
4) Lisibilité du code (argument d'opinion)
5) Afficher le peluchage logique séparé du peluchage des fléchettes
6) Ouvre un monde pour les outils de création d'interface utilisateur
7) Ouvre l'écosystème pour les pré-processeurs

DSX +1

DSX +1

J'aurais adoré écrire un tas de pour/contre, mais après avoir lu tous ces commentaires, j'ai l'impression que je vais tout répéter encore et encore.
Arrêtez d'être si naïf et ignorant, personne ne dit que vous serez FORCÉ d'écrire des interfaces utilisateur en utilisant DSX, c'est simplement une option (meilleure alternative).
Il y a une raison pour laquelle vous pouvez écrire JS de 101203103 manières différentes.

Eh bien, il y a toujours la possibilité d'écrire un plugin d'analyseur qui analyse DSX et les convertit en appels de fonction Dart réguliers, de sorte que le compilateur n'ait pas à faire de travail supplémentaire.

La vraie question est de savoir si les plugins d'analyseur s'appliquent dans le contexte du compilateur.

Si vous me demandez, DSX ne devrait être opt-in, idéalement via une sorte de plug-in. Je pense qu'il est extrêmement inutile de l'ajouter au langage lui-même, car les utilisateurs côté serveur et Web de Dart doivent s'adapter aux changements, pas seulement les utilisateurs de Flutter. La grande majorité du code écrit dans Dart n'a même pas besoin de syntaxe XML, donc l'appliquer à tout le monde est une mauvaise décision.

TLDR ; si vous voulez que DSX soit si mauvais, écrivez un plug-in d'analyseur et apportez-le vous-même à Dart. Internet vous aimera, vous obtiendrez des milliers d'étoiles Github et vous vous sentirez comme si c'était React. Gagnant-gagnant.

PS je vais même te faire la course pour le faire

Eh bien, il y a toujours la possibilité d'écrire un plugin d'analyseur qui analyse DSX et les convertit en appels de fonction Dart réguliers, de sorte que le compilateur n'ait pas à faire de travail supplémentaire.

Il n'y a actuellement aucun moyen dans le langage de fléchettes d'implémenter cela sans aucun hack (pensez aux conditions de concurrence, aux importations récursives et autres). Cela doit être intégré au niveau où tout fonctionnera comme prévu, rechargement à chaud, analyse statique, etc.

Si vous me demandez, DSX ne devrait être opt-in, idéalement via une sorte de plug-in. Je pense qu'il est extrêmement inutile de l'ajouter au langage lui-même, car les utilisateurs côté serveur et Web de Dart doivent s'adapter aux changements, pas seulement les utilisateurs de Flutter. La grande majorité du code écrit dans Dart n'a même pas besoin de syntaxe XML, donc l'appliquer à tout le monde est une mauvaise décision.

Si vous lisez le fil, c'est l'idée depuis le premier jour. Nous voulons juste le support de flutter/dart pour faire un transpiler.

TLDR ; si vous voulez que DSX soit si mauvais, écrivez un plug-in d'analyseur et apportez-le vous-même à Dart. Internet vous aimera, vous obtiendrez des milliers d'étoiles Github et vous vous sentirez comme si c'était React. Gagnant-gagnant.

Lisez le fil, cela a déjà été fait par @cbazza (le plugin d'analyse ne va pas le couper)

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

PS je vais même te faire la course pour le faire

Super! Même une théorie sur la façon dont cela fonctionnerait serait intéressante à voir.

SGTM. Je suppose que nous attendons tous une sorte de support de pré-traitement, alors.

Je préfère la syntaxe du constructeur que de passer des paramètres via le constructeur

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

comme dans https://fblitho.com/

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

DSX +1

Je comprends les arguments pour JSX, mais je pense qu'il y a tout autant de gens (y compris eux-mêmes) qui détestent l'idée de brouiller XML dans un langage de programmation. Je me sens mal (mais je comprends totalement que les autres ne ressentent pas la même chose).

Étant donné qu'il est pratiquement impossible de supprimer des fonctionnalités une fois implémentées, je suggérerais le principe de précaution. Voyons comment certaines des nouvelles fonctionnalités de syntaxe de Dart 2 se déroulent avant de s'engager dans une modification substantielle de la façon dont les applications Flutter sont construites.

@wstrange
Je peux vous comprendre. J'avais l'habitude d'être contre JSX et de mélanger js avec xml/html... puis j'ai essayé. Après quelques mois passés avec react, je suis tombé amoureux de JSX. Deux avantages tueur sont :

1. pas de nouvelle syntaxe et d'utilitaires
2. plus de passage de variables, de fonctions etc.

@wétrange ,

Étant donné qu'il est pratiquement impossible de supprimer des fonctionnalités une fois implémentées,

Ce n'est pas évident, qui aurait pensé que Google supprimerait MathML de Chrome ?

Voyons comment certaines des nouvelles fonctionnalités de syntaxe de Dart 2 se déroulent avant de s'engager dans une modification substantielle de la façon dont les applications Flutter sont construites.

Ce n'est pas du tout un changement dans la façon dont les applications Flutter sont construites, c'est juste une méthode alternative qui ne change pas la façon actuelle, et le plus important, c'est simplement une syntaxe différente de la bibliothèque de classes. Un transpileur simple fait le mappage sans avoir besoin d'informations des classes Flutter, donc cela fonctionne très bien pour le code de n'importe qui, ainsi que Flutter maintenant et à l'avenir.

@Bessonov ,

Oui, vous ne connaissez pas React tant que vous n'avez pas passé quelques mois à travailler dessus, puis vous réalisez à quel point c'est une bibliothèque phénoménale pour gérer les hiérarchies de composants.

@cbazza Je pourrais dire exactement la même chose à propos de Flutter. Passez quelques semaines à l'utiliser et vous ne manquerez pas JSX.

La réaction nous dit tout.

Comme maintenant, +1 est presque le double -1

@escamoteur ,
Oui, une déclaration très juste à dire, mais j'ai passé beaucoup de temps avec Flutter et je peux certainement voir la valeur que DSX y ajouterait. Comme @leedstyh l' a remarqué, les fans de DSX mènent la course de près de 2 contre 1, ce qui est assez étonnant étant donné que les gens de ce forum sont des gens de Flutter.

J'ai une question:

Lors de l'utilisation de la syntaxe DSX, nous supposons implicitement que le ou les enfants imbriqués sont de type Widget. Que se passe-t-il si nous voulons déclarer explicitement que nous voulons que l'enfant/les enfants imbriqués soient un sous-type spécifique de Widget ?

par exemple, lorsque je veux que les enfants de mon widget personnalisé n'acceptent qu'une liste de conteneurs, je peux annoter les enfants avec List<Container> et IDE donnera une erreur dès que je mettrai quelque chose de différent de Container. Comme je le sais, il n'y a aucun moyen d'appliquer un type sûr comme celui-ci lors de l'utilisation de dsx. Peut-être que nous pouvons avoir une erreur lors de la compilation de l'application, mais je pense que l'erreur qui se produit lorsque je tape est toujours une meilleure expérience.

Je pense que nous devrions donner à chacun le temps d'essayer et de se familiariser avec la façon de déclarer l'interface utilisateur flottante, au moins après la sortie de la v1. Ensuite, nous pourrions avoir un meilleur aperçu de cette fonctionnalité.

@sandangel ,

Très bonne prise !!! Je vous lance mon chapeau virtuel. Mon prototype initial a eu quelques trous depuis le début dont j'étais conscient et j'attendais juste que les gens les trouvent et se manifestent. J'espérais juste que les gens seraient intéressés à discuter de la technologie au lieu de se battre pour elle.

La solution que j'ai à cela est de fournir le type de tableau comme autre paramètre sur l'espace de noms. Au fur et à mesure que l'espace de noms devient grand, nous pouvons définir la forme courte de 'enfants' sur '*'.

Dans l'exemple 2 sur https://spark-heroku-dsx.herokuapp.com/index.html , si les actions étaient un tableau de 'Container' au lieu de 'Widget' par défaut, cela ressemblerait aux alternatives suivantes :

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

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

salut @cbazza , merci pour votre réponse.

Je m'interroge sur votre solution. Utilisons-nous à mauvais escient l'espace de noms xml comme décrit dans w3shool-XML Namespaces ?

Comme il est indiqué que l'espace de noms est principalement utilisé pour résoudre le conflit de nommage dans le document XML.

Ainsi, lorsque quelqu'un lit le XML ci-dessus, il peut penser que vous déclarez une balise Container sous l'espace de noms 'children' de l'espace de noms 'actions', et non que vous appliquez que chaque enfant imbriqué doit être un conteneur. Cela me confond quand je lis pour la première fois la syntaxe de votre proposition sans lire l'explication ci-dessus.

Pourrait-on avoir quelque chose de mieux ?

DSX n'est pas XML, c'est comme XML, donc il n'a pas besoin de suivre la sémantique XML, un peu comme le langage de modèle angulaire ;) Quoi qu'il en soit, je suis toujours ouvert à de meilleures alternatives ou suggestions et j'aimerais avoir une discussion ici.

Venant de React-native, j'ai d'abord pris en charge l'implémentation de type JSX et je n'aimais pas les objets imbriqués, mais je commence à apprécier la POO et à tout voir comme un objet !

Pour les personnes venant de React-native, je recommande vivement ce plugin ! https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer

@clarktank
Pouvez-vous développer votre expérience avec react-native (JSX), Flutter (OOP) et votre voyage de l'un à l'autre ?

@cbazza Je pense que la syntaxe du modèle angulaire suit la sémantique xml et, comme je le sais, il n'y a pas de cas d'utilisation de conflit entre la syntaxe angulaire et le document xml.

En tapuscrit, nous prenons en charge le composant générique .
Donc je pense qu'on pourrait avoir quelque chose comme ça :

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

Mais encore une fois, le composant générique est utilisé pour la vérification de type de l'entrée de propriété. Je ne sais pas si la syntaxe ci-dessus a une bonne signification sémantique dans ce cas d'utilisation.

J'ai vraiment l'impression que l'équipe Flutter a créé l'API actuelle spécifiquement pour la nouvelle façon de déclarer l'interface utilisateur qu'ils supposaient être meilleure que JSX et tout effort que nous essayons de lier la syntaxe JSX à l'API actuelle la rend simplement peu naturelle/inconfortable à utiliser.

La réaction nous dit tout.

Comme maintenant, +1 a presque doublé fois -1

Cela ne veut rien dire.

Sauf ceux qui regardent tous les problèmes de Flutter doublent celui qui atterrit sur ce problème car ils sont déjà habitués à JSX (et le recherchent explicitement). Cela signifie donc plutôt que _les personnes qui veulent une expérience de type JSX doublent les personnes qui regardent tous les problèmes qui ont voté -1_. (à mon humble avis, une partie des personnes votant +1 n'a même pas vraiment essayé le flottement)

@sandangel ,

Je pense que la syntaxe du modèle angulaire suit la sémantique xml et, comme je le sais, il n'y a pas de cas d'utilisation de conflit entre la syntaxe angulaire et le document xml.

Bien sûr, mais JSX n'utilise pas d'espace de noms, ce n'est donc pas une fonctionnalité XML intéressante.

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

Puisque vous avez divisé les "enfants" hors d'action dans leur propre balise, cela me rappelle en quelque sorte la nouvelle balise Fragment de React. C'est un équilibre entre verbosité et concision, c'est certain.

J'ai vraiment l'impression que l'équipe Flutter a créé l'API actuelle spécifiquement pour la nouvelle façon de déclarer l'interface utilisateur qu'ils supposaient être meilleure que JSX et tout effort que nous essayons de lier la syntaxe JSX à l'API actuelle la rend simplement peu naturelle/inconfortable à utiliser.

Il n'y a rien de nouveau dans la façon dont Flutter déclare l'interface utilisateur dans le code. Peut-être que l'utilisation de DSX n'est pas naturelle/inconfortable pour vous, mais pour les développeurs JSX, ce n'est pas le cas. JSX/DSX est parfait pour Flutter, il va comme un gant et si vous n'aimez pas les gants, allez-y mains nues ;)

@a14n ,

Cela ne veut rien dire.

c'est sûr !!! vous pouvez discuter avec 'sentiment', 'pensée', 'suspect', 'à mon humble avis', 'opinion' mais ce sont des données, un point de données concret. Si les données sont inutiles, elles ne doivent pas être collectées. Je suppose que les données sont inutiles car elles ne peignent pas votre image.

@cbazza Je veux dire que lorsque nous essayons de répondre à la question que j'ai ci-dessus sur l'application d'un sous-type de widget pour enfant/enfants, je pense que le code Dart fait un meilleur travail que JSX.

DSX n'est pas XML, c'est comme XML donc il n'a pas besoin de suivre la sémantique XML

Bien sûr, mais JSX n'utilise pas d'espace de noms, ce n'est donc pas une fonctionnalité XML intéressante.

Je ne suis pas sûr, mais j'ai lu certains de vos commentaires ci-dessus et je pense que vous avez mentionné le nœud JSX/XML de manière interchangeable. Quoi qu'il en soit, personnellement, je pense que l'utilisation de l'espace de noms comme solution n'est pas idéale.

Il suffit de comparer

<actions:children:Container>

</actions:children:Container>

et

actions: <Container>[]

syntaxe.

@sandangel ,

Oui, la syntaxe de balisage est plus détaillée pour ce cas et c'est pourquoi j'ai mentionné la forme abrégée pour les enfants étant '*'. Quoi qu'il en soit, ce cas est l'exception et non la règle. La plupart du temps, vous n'avez même pas besoin de spécifier 'enfants', encore moins 'Container'; mais la fonctionnalité doit être là pour couvrir tous les cas d'utilisation possibles.

@ a14n voter c'est voter, ça veut dire.

Je respecte ton sentiment, c'est peut-être vrai. Mais même avec un ratio inverse (1 à 2), cela signifie toujours 33 % de base d'utilisateurs. Pouvez-vous dire que 33 % est une petite part ?

les personnes qui veulent une expérience de type JSX

Oui, certaines personnes regardent. Cela signifie également que _l'absence de JSX-like est l'une des raisons qui empêchent les gens de choisir flutter_.

Flutter vise plus de développeurs, pas seulement ceux qui lisent tous les problèmes.

@jstansbe
Je suis un programmeur autodidacte, et comme la plupart des gars autodidactes, j'ai commencé avec Javascript.
Ensuite, j'ai commencé à apprendre React et React-Native. Je pense que ces dernières années, spécialement après ES6, le style OOP a été ajouté à Javascript.

Donc, les gens comme moi ne sont pas habitués au style de programmation OOP. Même si React natif Component sont des classes comme Widgets dans Flutter.

JSX cache en quelque sorte l'image POO pure. En gros, il cache ce qui se passe sous le capot. Remarque : React a été conçu pour les développeurs Web et les développeurs Web sont habitués à la syntaxe HTML. C'est pourquoi JSX est si populaire parmi les développeurs Web.

Personnellement, je pense que la POO pure a plus de sens pour les grands projets.

@clarktank ,

Lorsque vous discutez de langages informatiques, vous devez être conscient de :
(1) Syntaxe - les caractères et les mots qui composent la langue
(2) Sémantique - la signification de ces caractères et mots

Par exemple, les appels de fonction dans de nombreux langages ressemblent à ce qui suit (c'est-à-dire qu'ils ont la syntaxe suivante) :

a = someFunction(param1, param2)

Imaginez maintenant qu'un autre langage décide d'utiliser des crochets au lieu de crochets arrondis pour les appels de fonction ; cela ressemblerait à ceci :

a = someFunction[param1, param2]

La chose ici est que la syntaxe est différente mais la sémantique est la même. Je veux dire que les deux font essentiellement des appels de fonction mais avec une syntaxe différente.

JSX cache en quelque sorte l'image POO pure. En gros, il cache ce qui se passe sous le capot.

Pas vrai du tout. JSX/DSX est juste une syntaxe différente pour exactement la même chose (la sémantique est la même). Dans le cas de JSX, les balises XML créent simplement des composants React (tout comme vous pouvez le faire en Pure Javascript). Dans le cas de DSX, les balises XML créent simplement des widgets Flutter (tout comme vous pouvez le faire dans Pure Dart). La syntaxe est différente mais elle génère exactement la même chose donc elle est identique sous le capot.

Remarque : React a été conçu pour les développeurs Web et les développeurs Web sont habitués à la syntaxe HTML. C'est pourquoi JSX est si populaire parmi les développeurs Web.

JSX est populaire car c'est un excellent moyen de gérer les hiérarchies des arborescences de composants, que ce soit pour le développement Web, mobile ou tout autre interface utilisateur. Remarquez dans le code ci-dessous que vous ne savez pas si le composant déroulant est pour le Web ou le mobile par exemple.

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

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

render(dropdown);

Personnellement, je pense que la POO pure a plus de sens pour les grands projets.

Comment c'est? (considérant que l'utilisation de JSX/DSX ou Pure Javascript/Dart génère exactement la même chose sous le capot).

@cbazza

J'ai utilisé react-native pendant près d'un an et je n'avais aucune idée que les éléments JSX sont des objets qui sont instanciés, jusqu'à ce que je commence avec Flutter/Dart. De mon point de vue, cela cache l'image OOP, même si, comme vous l'avez dit, sémantiquement, cela fait la même chose sous le capot !

Dans les grandes applications, JSX pourrait également devenir aussi moche que des objets fortement imbriqués. Donc, syntaxiquement, je préfère rester cohérent plutôt que d'introduire un autre style qui pourrait être aussi déroutant.

@clarktank ,

Dans les grandes applications, JSX pourrait également devenir aussi moche que des objets fortement imbriqués. Donc, syntaxiquement, je préfère rester cohérent plutôt que d'introduire un autre style qui pourrait être aussi déroutant.

Pour moi, le fait qu'il soit différent du reste du code est en fait un avantage.

(Je m'excuse d'avance pour le mur de texte.)

En tant que personne qui n'a pas utilisé React-Native ou Flutter assez longtemps pour me considérer comme une source définitive, que Dart brut ou JSX/DSX soit "meilleur", ce fil de discussion a été plutôt fascinant à lire. Il y a quelques choses sur lesquelles j'aimerais mettre mes 0,02 $ de moins.

Pour commencer, je suis d'accord avec diverses personnes sur la nature de ce qu'est réellement JSX et sur la manière dont il profite aux développeurs. D'abord et avant tout, JSX a été conçu comme une forme de "HTML dynamique" qui pourrait être intégré dans le code Javascript existant. Il est indispensable pour les plates-formes Web basées sur JS comme React en ce sens qu'il permet aux développeurs Web d'interagir proprement et efficacement avec le DOM sans avoir à lutter avec la méthode native horrible (ou la méthode jQuery légèrement meilleure). De plus, de par sa nature même, JSX encourage le développement d'une interface utilisateur qui peut être facilement dissociée des données sous-jacentes, favorisant une structure de projet bien organisée. Dans cet environnement, JSX est un outil permettant une plus grande productivité, et je pense qu'il serait pratiquement impossible de discuter avec cela.

Le lien entre ce paragraphe et React-Native est que, même s'il s'agit d'une plate-forme de développement mobile, elle descend directement de React. En tant que tel, presque toute la syntaxe et les paradigmes ont encore été créés à l'origine avec le développement Web à l'esprit. C'est par conception - tout le shtick de RN est que vous pouvez "créer des applications mobiles multiplateformes à l'aide de React", il est donc _supposé_ de se sentir comme du développement Web lors de son utilisation. Les applications RN sont également principalement écrites en Javascript, de sorte que l'inclusion de JSX est naturelle. JSX aide le développement RN pour presque toutes les mêmes raisons qu'il aide au développement Web. (Je pense vraiment que c'est l'une des principales raisons pour lesquelles, dans RN au moins, l'approche JSX est utilisée beaucoup plus fréquemment que l'approche native. RN lui-même _se sent_ comme une plate-forme Web, donc l'approche plus naturelle du Web va inévitablement devenir prédominant.)

Flutter, en revanche, n'a pas une telle philosophie de conception. Il est destiné à être une solution multiplateforme purement native, et bien qu'il indique qu'il a été inspiré par React-Native, il écrit beaucoup plus comme une application de bureau ou mobile native qu'une application Web. Il fonctionne également en utilisant Dart et non Javascript, ce qui, du point de vue de l'intégration de quelque chose comme JSX, est une considération majeure. D'une part, alors que les fonctions JS DOM peuvent être horriblement verbeuses (à la fois en raison de la conception de la fonction et du langage JS lui-même), Dart en tant que langage facilite beaucoup plus le code déclaratif d'interface utilisateur propre tandis que Flutter fait pour la plupart un bon travail de garder les constructeurs d'interface utilisateur concis. Pour un autre ( comme @sandangel l' a souligné ), Dart est un langage à typage statique, donc la nature de JSX étant conçu pour un langage à typage dynamique comme JS va se heurter à des accrocs dans les cas où, par exemple, un constructeur d'interface utilisateur nécessite un Widget d'un type spécifique, la seule solution à laquelle ne fait qu'ajouter à la verbosité. Personnellement, cela ressemble à une solution qui, avec le temps, se traduira inévitablement par un DSL gonflé et difficile à maintenir car il doit tenir compte d'un nombre croissant de cas d'utilisation inhérents à un système qu'il n'était pas destiné à être utilisé pour.

En tant que tel, je ne vois vraiment pas comment JSX/DSX bénéficierait à la productivité du développement Flutter au-delà d'être simplement une question de préférence personnelle. Dans l'ensemble, les deux syntaxes sont à peu près équivalentes en termes de verbosité, et là où l'on perd de la verbosité dans des cas spécifiques, cela se rattrape en clarté (les balises XML de fermeture, par exemple). Cela se résume en grande partie à savoir si quelqu'un vient à Flutter à partir d'un arrière-plan orienté Web (React/RN, Angular, etc.) ou d'un arrière-plan natif (Java/Kotlin/Swift, WPF/UWP, etc.) qui déterminera quel approche qu'ils préféreraient. Même sur ce seul fil, il y a beaucoup d'histoires d'utilisateurs qui disent qu'ils étaient extrêmement sceptiques à l'égard de JSX au début, mais après l'avoir utilisé pendant quelques mois, ils ont changé d'avis en "ne peut pas s'en passer". (Bien que la partie cynique de moi veuille souligner que la même chose pourrait très bien leur arriver pour l'approche Dart native s'ils lui donnaient une chance.)

Cela étant dit, je ne me vois pas vraiment d'accord pour que DSX soit officiellement pris en charge par l'équipe Flutter comme alternative aux constructeurs d'interface utilisateur natifs. Bien que ce soit parfaitement bien en tant que solution tierce (et tous les accessoires de @cbazza pour l'implémenter réellement), cela ne correspond pas vraiment à la nature fondamentale de Flutter en tant que plate-forme non basée sur la technologie Web. En tant que tel, plus de pouvoir pour quiconque souhaite utiliser DSX dans ses propres projets, mais je serais d'accord avec l'idée qu'il y a beaucoup d'autres choses plus importantes sur lesquelles l'équipe Flutter pourrait et devrait passer son temps.

Cela étant dit, bien que je ne sois pas vraiment d'accord avec le fait que DSX soit officiellement pris en charge, je pense qu'il devrait y avoir un format d'interface utilisateur officiel de quelque sorte. Comme @birkir l' a souligné , presque toutes les principales plates-formes d'interface utilisateur natives, qu'elles soient de bureau ou mobiles, ont un format d'interface utilisateur en plus de l'approche directe basée sur le code (et la plupart d'entre elles sont de toute façon prétraitées dans l'approche basée sur le code). Avoir des fichiers d'interface utilisateur séparés des fichiers logiques a toujours été la méthode recommandée pour adopter le modèle MVVM (ce qui, soit dit en passant, est une chose qui m'a toujours déplu à propos de JSX). Ce que je dirais, par conséquent, c'est que Flutter a quelque chose de similaire - au lieu d'un format DSL d'interface utilisateur en ligne, il devrait avoir un format d'interface utilisateur distinct destiné à entrer dans son propre fichier, loin du code Dart.

Dans le cadre de cette ligne de pensée, j'ai en fait fait du travail le week-end dernier dans ce sens. Si je pouvais me permettre de flâner un instant, j'ai développé un projet que j'ai appelé "FLUI" qui est ma tentative de montrer à quoi un tel format pourrait ressembler . Plutôt que d'utiliser un DSL existant (ou une version modifiée), j'en ai développé un entièrement nouveau qui s'inspire de YAML et j'ai fait de mon mieux pour rester proche de la "sensation" de la disposition de l'approche Flutter-constructeur. Certes, il s'agit d'une implémentation _très_ précoce, donc je ne m'attends pas vraiment à ce qu'elle n'ait pas une multitude de problèmes, mais j'ai inclus la source du script du processeur (écrit en C#/.NET Standard) afin que les gens puissent jouer avec s'ils le veulent. :)

En tant qu'utilisateur de React/RN et de Flutter, je suis fortement en désaccord avec l'idée de "DSX".

DSX n'apporterait rien . JSX est utilisé en réaction car la syntaxe JS est horrible. Mais dans le cas de Flutter, la création de widgets est super facile.

Le classique :

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

il est déjà prêt à l'emploi, lisible, facile à écrire, compatible type/générique et sans aucune duplication inutile.

La seule plainte que vous pourriez avoir avec la syntaxe actuelle est "Il est difficile de savoir où se trouve la parenthèse fermante d'un widget"

Mais là encore, le plugin Dart des IDE officiellement pris en charge résout ce problème. Ainsi, lorsque nous ouvrons le code d'avant dans disons vscode, nous verrons

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

Quant au "It's hard to differenciate casual code from UI code", les règles de réaction s'appliquent également au flutter :

Les widgets doivent être stupides ou intelligents. Le widget intelligent n'a pas de logique d'interface utilisateur. Les widgets stupides n'ont rien d'autre qu'une logique d'interface utilisateur.

Si vous suivez ce modèle, vous ne devriez jamais tomber dans une situation où vous ne parvenez pas à différencier l'interface utilisateur du reste.
C'est encore plus vrai lorsque vous suivez quelque chose comme le modèle BLoC ; qui imposent fortement la séparation des affaires et de l'interface utilisateur.

JSX est utilisé en réaction car la syntaxe JS est horrible

Déclaration très opiniâtre et tout simplement fausse.

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

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

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

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

Déclaration très opiniâtre et tout simplement fausse.

Il y a beaucoup de caractères inutiles dans la syntaxe de réaction par défaut.
Comparons la répétition des mots et le nombre de caractères pour chaque syntaxe (hors définition de fonction, indentation et 'retour')

Réagissez sans JSX :

• 133 caractères, dont 3 parenthèses, 3 crochets, 3 : , 4 , et 11 espaces
• React.createElement écrit deux fois

JSX :

• 104 caractères, avec 2 parenthèses, 3 crochets, 1 : , 4 <> et 5 espaces
• Container et Text écrits deux fois

Dard:

• 99 caractères, avec 2 parenthèses, 4 : , 3 , et 4 espaces
• Pas de répétition

En termes de caractères, le gagnant évident ici est la syntaxe des fléchettes.

Maintenant, nous devons également prendre en compte d'autres spécificités des fléchettes.

Types de fléchettes enfant unique vs multi-enfant, a des constructeurs const et autorise les génériques et même les paramètres positionnés. JSX ne prend en charge aucun de ceux-ci.

Quelques exemples qui convertiraient mal en JSX :

Pas toujours children :

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

OR

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

Constructeur const sur le widget lui-même

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

génériques

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

accessoires positionnés :

Text("foo")

Constructeur nommé

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

constructeurs (dart ne prend pas en charge le type d'union, donc children ne peut pas être à la fois un widget et une fonction)

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

@rrousselGit

Comme mentionné à plusieurs reprises avant DSX est simplement un autre
syntaxe et c'est un sur-ensemble de Dart, donc tout ce que vous pouvez faire avec
Dart, vous pouvez le faire dans DSX. Vous pouvez également mélanger et assortir les deux
syntaxes comme bon vous semble. Visiblement tu n'as même pas pris la peine de vérifier
quelles sont certaines des fonctionnalités DSX qui ont été conçues pour prendre en charge
Dard:
https://spark-heroku-dsx.herokuapp.com/index.html

-1---------------------------------------
Dans Dart :

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

OR

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

Dans DSX :

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

OR

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

-2--------------------------------------------------
Dans Dart :

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

Dans DSX :

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

-3-------------------------------------------
Dans Dart :

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

Dans DSX :

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

  }}
  child={child}
/>

-4--------------------------------------------------
Dans Dard :

Text("foo")

Dans DSX :

<Text ["foo"]/>

-5----------------------------------------------------
Dans Dard :

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

Dans DSX :

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

-6--------------------------------------------------
Dans Dart :

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

Dans DSX :

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

Mais alors l'argument d'avoir une conversion plus facile de réagir en flottement est invalide. Comme JSX est radicalement différent de votre prototype :

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

Et aucun de vos exemples ici ou à partir de votre lien ne simplifie réellement le code ou n'améliore la lisibilité

Autant que je peux m'identifier à votre sentiment de manquer de JSX (j'ai eu la même chose au démarrage du flutter), après une certaine expérience, la syntaxe native se sent plutôt bien en fait

En passant, il existe une bien meilleure solution à votre séparation des préoccupations. C'est un fichier modèle
Vous pourriez avoir un fichier xml/yaml à côté de votre widget. Et puis utilisez les outils de génération de code impressionnants fournis par Dart.

Je préfère un :

// main.dart
import 'package:flutter/material.dart';

part 'main.g.dart';

class MyState extends StatefulWidget {
  <strong i="14">@override</strong>
  _MyStateState createState() => _MyStateState();
}

class _MyStateState extends State<MyState> {
  <strong i="15">@override</strong>
  Widget build(BuildContext context) {
    return $myStateStateTemplate(theme: Theme.of(context));
  }
}

combiné avec un

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

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

qui utilise ensuite un code-gen personnalisé pour générer le fichier fléchette suivant :

part of 'main.dart';

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

Le résultat final est encore meilleur qu'un "DSX" pour la séparation de l'interface utilisateur/logique. C'est aussi mieux pour les générateurs d'interface utilisateur potentiels. Et c'est beaucoup plus facile à implémenter en utilisant built .

Comme JSX est radicalement différent de votre prototype :

Vraiment !!! La seule chose radicale dans ces discussions a été la réaction des opposants.

Comme il est indiqué dans le titre de ce ticket, DSX est similaire à JSX, il n'est pas identique à JSX, sinon il aurait été appelé JSX ; et les ajouts sont mineurs et offrent des options aux développeurs.

Vous pourriez l'écrire comme suit :

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

or

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

or

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

or

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

Hummmm, vous semblez confondre « séparation des préoccupations » et « séparation de la technologie ». Ces choses sont très différentes; vous séparez le code de fléchette et le code de balisage dans différents fichiers, est simplement une "séparation de la technologie" et n'offre aucun des avantages de la "séparation des préoccupations". Une préoccupation ici serait un composant/widget qui encapsule proprement du code réutilisable, peu importe qu'à l'intérieur de ce composant/widget il utilise différentes technologies.

De plus, la séparation des technologies que vous recommandez est très inférieure à JSX/DSX qui utilise le langage hôte pour toutes ses constructions impératives (boucles for, appels de fonction, instructions if, etc.).

Après beaucoup de code et d'exemples postés ici ( en particulier ), j'arrive à la conclusion que JSX ajoute beaucoup plus de valeur à JS contrairement à DSX et Dart. Mais une fonctionnalité est très importante de mon point de vue : les balises de fermeture. Comme:

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

réduit BEAUCOUP de complexité cognitive dans les structures profondes comme ici contrairement à :

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

Mais bon, si vous l'utilisez comme ceci :

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

il y a un petit bénéfice.

Comme il est indiqué dans le titre de ce ticket, DSX est similaire à JSX, il n'est pas identique à JSX

Vous avez manqué mon "Mais alors l'argument d'avoir une conversion plus facile de réagir en flottement n'est pas valide."

La moitié des arguments pour DSX est "JSX est populaire en réaction, nous en avons besoin ici aussi". Mais vous proposez quelque chose de différent (et plus complexe) de JSX.
L'autre moitié consiste à séparer l'interface utilisateur du code ; ce qu'un fichier modèle peut faire aussi.

De plus, la séparation des technologies que vous recommandez est très inférieure à JSX/DSX qui utilise le langage hôte pour toutes ses constructions impératives (boucles for, appels de fonction, instructions if, etc.).

Pas vrai. Vous pouvez faire if et d'autres choses dans votre fichier de modèle. Regardez cshtml ou des modèles angulaires.

La chose est un fichier de modèle, tant que vous avez déjà un analyseur pour celui-ci, pourrait être implémenté pour le flutter en moins d'une semaine de travail complet.
Que ce soit yaml, xml, cshtml ou html avec des directives.

Alors qu'un DSX demanderait beaucoup de travail.

@Bessonov Ils ont récemment ajouté des commentaires virtuels sur les IDE pris en charge pour simuler la balise de fermeture.

Ainsi dans votre vscode vous verrez ceci :

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

Les avantages des balises fermantes. Sans avoir à les taper

@rrousselGit

Ils ont récemment ajouté des commentaires virtuels sur les IDE pris en charge pour simuler la balise de fermeture.

Ouais, j'ai vu ça dans le commentaire cité. Mais ce n'est pas pareil. Cela introduit un décalage d'alignement et perturbe le flux de lecture. Et cela ne m'aide pas dans d'autres IDE et processeurs de texte.

La chose est un fichier modèle

Les modèles IMHO souffrent du syndrome NIH. Je ne dis pas que cette approche consistant à mélanger PHP et HTML est la bonne façon de le faire. Mais réagir montre avec JSX comment cela peut être mieux fait.

@rrousselGit

Vous avez manqué mon "Mais alors l'argument d'avoir une conversion plus facile de réagir en flottement n'est pas valide."

Non, je n'ai pas du tout raté le commentaire, cela n'a aucun sens que vous me disiez que les personnes venant de JSX trouveront DSX trop complexe.

La moitié des arguments pour DSX...

Il existe de nombreuses raisons de choisir DSX, mais avec des alternatives, les gens choisiront ce qu'ils préfèrent pour quelque raison que ce soit.

Pas vrai. Vous pouvez faire si et des choses dans votre fichier de modèle. Regardez les modèles cshtml ou angulaires.

La chose est un fichier de modèle, tant que vous avez déjà un analyseur pour celui-ci, pourrait être implémenté pour le flutter en moins d'une semaine de travail complet.
Que ce soit yaml, xml, cshtml ou html avec des directives.

Alors qu'un DSX demanderait beaucoup de travail.

Totalement opposé, DSX n'implémente que 2 transformations xml et gagne tout le reste gratuitement à partir du langage d'hébergement. Imaginez l'effort déployé pour réimplémenter la puissance de Dart dans votre nouveau langage de modèles. Non merci, je vais prendre Dart.

Non, je n'ai pas du tout raté le commentaire, cela n'a aucun sens que vous me disiez que les personnes venant de JSX trouveront DSX trop complexe.

La même chose s'applique à la mise en œuvre actuelle des fléchettes.

Quoi qu'il en soit, je ne pense pas que nous puissions nous convaincre ici. Je vais donc énumérer quelques raisons supplémentaires pour lesquelles je n'aime pas JSX en flottement, puis "attendre et voir".

1. La création de widget est différente de React

Dans react, c'est la librairie qui gère la création des composants. JSX est bien parce qu'il dit "Ne vous souciez pas de la façon dont les choses fonctionnent. Nous faisons les choses pour vous".

En flottement ce n'est pas le cas. Nous instancions manuellement un nouveau widget à chaque appel de build. C'est vraiment important à comprendre, et JSX le rendrait moins clair.

Et, dans la continuité de cette logique :

2. Les gens peuvent penser que <Foo /> fait quelque chose de spécial que new Foo() ne fait pas

<Foo /> dans une méthode semble spéciale. Il semble que cela fasse quelque chose d'étranger intégré dans le cadre. Ce qui est vrai dans react, où les composants sont enveloppés dans un React.Element .
Cela se traduit par réagir en <Foo /> != new Foo() et n'a pas d'accès direct à Foo .

Cela ne s'applique pas au flottement et peut prêter à confusion.

Aussi :

<Foo>
  <Bar />
</Foo>

En réaction, si Foo n'utilise jamais son fils alors Bar n'est jamais instancié. Et Foo est instancié après le retour de la méthode render .
Alors qu'en flottement c'est le contraire. Bar et Foo sont créés immédiatement

Cela conduirait potentiellement les développeurs de React à créer du code flutter non optimisé.

3. En général, Dart/flutter n'est pas JS/react

Si nous ajoutons JSX dans Dart, je peux déjà voir les problèmes concernant l'union de type ou être capable de faire
return foo && <Component /> ou le prochain rendu asynchrone en réaction.
Justifié par un "nous avons déjà JSX donc nous pouvons l'avoir aussi !"

Je préférerais une syntaxe propriétaire ou pas de syntaxe du tout, pour ne pas avoir à implémenter la dernière fonctionnalité JSX/react dans dart

4. JSX rend certaines spécificités des fléchettes peu claires

Un petit exemple, Scaffold nécessite pour appbar un PrefferedSizeWidget .
Si nous créions Scaffold en utilisant JSX, les gens s'attendraient à ce que vous puissiez remplacer n'importe quel JSX par un autre. Ce qui n'est pas vrai

Je veux dire, il est très difficile de comprendre pourquoi nous pouvons faire

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

mais non

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

@rrousselGit

Quoi qu'il en soit, je ne pense pas que nous puissions nous convaincre ici. Je vais donc énumérer quelques raisons supplémentaires pour lesquelles je n'aime pas JSX en flottement, puis "attendre et voir".

Je ne suis pas d'accord avec beaucoup de ce que vous avez dit, mais j'apprécie vos efforts puisque vous prenez le temps de réfléchir profondément à la question.

1. La création de widget est différente de React

Pour moi, cela n'a pas d'importance car il ne s'agit que d'un détail d'implémentation, conceptuellement une fois que vous voyez du XML, dans React c'est un composant, dans Flutter c'est un widget.

1. Les gens peuvent penser fait quelque chose de spécial que new Foo() ne fait pas

Je pense que les gens apprendront assez rapidement que Dart/DSX n'est pas Javascript/JSX.

1. En général, Dart/flutter n'est pas JS/react

Oui, nous sommes finalement d'accord sur quelque chose, mais même s'ils sont différents, le fil conducteur est qu'ils sont des cadres d'interface utilisateur déclaratifs et je pense que les arborescences déclaratives sont bien gérées avec JSX/DSX. Cela vous permet de rester sur le mode de pensée de la programmation déclarative.

Si nous ajoutons JSX dans Dart, je peux déjà voir les problèmes concernant l'union de type ou être capable de faire return foo && <Component /> ou le rendu asynchrone à venir en réaction.
Justifié par un "nous avons déjà JSX donc nous pouvons l'avoir aussi !"

Nous n'ajoutons pas JSX dans Dart, nous ajoutons DSX, c'est différent mais a des similitudes avec JSX et la familiarité est une chose énorme.

Je préférerais une syntaxe propriétaire ou pas de syntaxe du tout, pour ne pas avoir à implémenter la dernière fonctionnalité JSX/react dans dart.

Donc, avec ce raisonnement, pourquoi utilisez-vous Dart ? il ressemble assez à Java et pourtant il est différent de Java ; Au diable, supprimons tous ces mots-clés et concepts Java et proposons quelque chose de vaguement similaire à Erland que vous ne pouvez programmer que d'une seule main tout en faisant un mouvement de yoga bretzel au sommet du mont Everest ;)

1. JSX rend certaines spécificités des fléchettes peu claires

Pas vraiment, si vous connectez des widgets incomparables, le compilateur Dart crachera des messages d'erreur comme si vous le faisiez dans Dart ordinaire. Je ne saurais trop insister sur le fait que DSX est simplement du sucre syntaxique mince, il n'y a pas de magie, juste une différence de syntaxe pour la même chose.

@cbazza J'ai passé des heures à lire vos messages et j'apprécie vraiment vos efforts sur ce problème. Mais je pense qu'il est (en quelque sorte) facile de mettre fin à l'argument. Rappelez-vous que flux était la solution officielle de gestion d'état pour réagir, mais maintenant tout le monde utilise redux ? Et combien y a-t-il de bibliothèques de navigation pour react-native ? Créez simplement un dépôt DSX et laissez réagir les développeurs.

@rrousselGit

Je n'ai jamais vu la syntaxe part / part of dans Dart auparavant, et j'ai du mal à trouver de la documentation à ce sujet. Est-ce quelque chose que Dart/Flutter prend officiellement en charge ? J'aimerais utiliser quelque chose comme ça dans FLUI.

@cbazza

Vous continuez à tourner en rond avec la justification DSX. DSX n'est pas JSX. DSX ressemble à JSX. DSX est censé être une syntaxe familière pour les développeurs React. DSX est simplement un sucre syntaxique pour Dart. Les gens apprendront que DSX n'est pas JSX. (Etc.)

Bien que je comprenne le point que vous essayez de faire valoir avec toutes ces explications, je pense que le fait que vous deviez continuer à les faire révèle un problème majeur concernant la nature de DSX en général, et c'est un point que rrouselGit a également soulevé. Même si vous continuez à dire que DSX n'est _pas_ JSX, les gens qui le trouveront penseront que c'est le cas, et c'est un problème. JSX et les personnes qui l'utilisent proviennent d'un écosystème qui est si conceptuellement différent de Dart/Flutter sur le plan fondamental. En tant que tel, développer une fonctionnalité pour la "familiarité" n'est pas nécessairement une bonne chose. L'une des raisons les plus apparentes à cela est, comme cela a été souligné, que les gens vont essayer quelque chose comme ceci :

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

Parce qu'ils viennent de Javascript/JSX, ils s'attendent à ce que cette syntaxe fonctionne dans DSX. Quand ce n'est pas le cas, cela devient un point de dissonance cognitive qui peut en fait nuire à leur intérêt non seulement pour DSX mais pour Flutter dans son ensemble. La familiarité est bénéfique lorsqu'elle est utilisée comme un moyen d'amener les gens à découvrir quelque chose de nouveau, mais cela peut être une épée à double tranchant - lorsque 90 % des fonctionnalités sont identiques, les 10 % restants peuvent simplement servir à frustrer et à ennuyer.

Un autre problème avec DSX est qu'il est peu probable qu'il s'agisse d'une fonctionnalité intégrée de manière transparente de si tôt, qu'il s'agisse d'un plugin tiers ou s'il est officiellement adopté par Flutter. Comme vous l'avez dit vous-même, pour que cela fonctionne vraiment avec le processus de débogage et de déploiement de Flutter, il a besoin du soutien officiel non seulement de l'équipe Flutter mais aussi de l'équipe Dart. À défaut, sans le prétraitement et la prise en charge des outils, la seule façon dont DSX fonctionnerait serait d'utiliser des outils de conversion manuelle externes, ce qui n'est qu'une autre étape (potentiellement longue) que les développeurs devront franchir.

En tapant ceci, il y a une autre chose qui m'est venue à l'esprit. Il y a eu plusieurs personnes pro-JSX dans ce fil qui ont fait l'éloge de JSX, affirmant que l'approche de "séparation des préoccupations" de la conception de l'interface utilisateur est vraiment la seule façon dont ils envisageront de développer à nouveau des interfaces utilisateur. Si tel est le cas, pourquoi React est-il le seul framework présent sur le marché qui l'utilise ? Les frameworks d'applications mobiles natives et multiplateformes sont restés fidèles à leurs storyboards, leurs fichiers XML, leurs fichiers XAML et d'autres DST de définition d'interface utilisateur. Même d'autres frameworks JS populaires comme Angular et le futur Vue adoptent toujours l'approche de "séparation des technologies". Les développeurs de React parlent comme si JSX était la voie de l'avenir, mais je ne l'ai pas encore vu apparaître ailleurs que dans React dans un cadre qui a vraiment gagné en popularité.

@andrewackerman

part / part of est une fonctionnalité de fléchettes existante. Il joint en quelque sorte deux fichiers en un seul. Habituellement utilisé pour la génération de code.

Il existe quelques scénarios de cas réels qui utilisent une telle technique. Comme json_serializable qui génère une méthode toJSON et une usine fromJSON pour les classes en fonction de leurs propriétés.

part / part of ne fait vraiment rien tout seul. La partie intéressante est lorsque vous le combinez à quelque chose comme source_gen .

@sunnylqm

Je ne pense pas que mettre du code sur un référentiel résoudrait mon problème car le problème actuel concerne l'intégration correcte de DSX avec les outils Flutter afin de fournir une excellente expérience de développement avec le débogueur, la saisie semi-automatique, etc. travaillant sur le fichier .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.

@andrewackerman

Je n'ai pas besoin de justifier quoi que ce soit, je suis très confiant que DSX sera un succès et il y a près de 100 personnes intéressées par ce seul billet.

À défaut, sans le prétraitement et la prise en charge des outils, la seule façon dont DSX fonctionnerait serait d'utiliser des outils de conversion manuelle externes, ce qui n'est qu'une autre étape (potentiellement longue) que les développeurs devront franchir.

Le transpileur DSX est incroyablement rapide et peut transformer des fichiers .dsx en fichiers .dart plus rapidement que vous ne pouvez cligner des yeux, donc la vitesse n'est pas un problème ; essayer simplement d'obtenir la parité des fonctionnalités pour en faire une évidence pour les gens d'utiliser DSX.

Si tel est le cas, pourquoi React est-il le seul framework présent sur le marché qui l'utilise ? Les frameworks d'applications mobiles natives et multiplateformes sont restés fidèles à leurs storyboards, leurs fichiers XML, leurs fichiers XAML et d'autres DST de définition d'interface utilisateur.

Créez simplement une chronologie et vous verrez l'évolution du développement de l'interface utilisateur. Le développement Android et iOS via leurs méthodes actuelles a commencé il y a plus de 10 ans, il utilise donc des techniques vieilles de 10 ans (techniques totalement impératives). Les techniques de développement d'interface utilisateur réactive (déclaratives) ont commencé à apparaître pour le Web il y a environ 8 ans. React est apparu il y a 5 ans et c'était le premier framework réactif à combiner les technologies de manière transparente avec JSX. Vue est maintenant le dernier framework réactif qui prend en charge les anciennes techniques de "séparation des technologies", mais il prend également en charge JSX. Sur mobile, Flutter est le dernier et il utilise des techniques de framework réactives comme React et il pourrait tirer parti de DSX tout comme Vue tire parti de JSX. Vue tue Angular parce qu'il offre un choix aux développeurs et qu'il n'est pas trop opiniâtre.

Le problème avec les fichiers de modèle séparés est que les constructions de programmation impératives (if, for loop, etc.) sont si faibles par rapport à ce qui est disponible sur le langage de programmation utilisé pour la logique métier. Pour moi, combiner les 2 à la manière de JSX est clairement l'avenir.

Les développeurs de React parlent comme si JSX était la voie du futur,

Il est !!!

mais je ne l'ai pas encore vu apparaître ailleurs que dans React dans un cadre qui a vraiment du succès.

Vue utilise JSX

@cbazza

Je n'ai pas besoin de justifier quoi que ce soit, je suis très confiant que DSX sera un succès et il y a près de 100 personnes intéressées par ce seul billet.

Je ne dis pas que vous devez justifier quoi que ce soit. À l'époque où vous insistiez pour que l'équipe Flutter reprenne cette proposition et la mette en œuvre elle-même, oui, j'aurais dit que vous aviez pas mal de justifications à faire. Maintenant que vous essayez de le faire vous-même, vous pouvez faire ce que vous voulez pour toute justification que vous pensez être suffisante, et plus de pouvoir pour vous. J'énonce simplement les raisons pour lesquelles je vois que ce ne sera peut-être pas aussi facile ou aussi populaire que vous semblez le penser, et je mets la balle dans votre camp pour les défier.

Le transpileur DSX est incroyablement rapide et peut transformer des fichiers .dsx en fichiers .dart plus rapidement que vous ne pouvez cligner des yeux, donc la vitesse n'est pas un problème ; essayer simplement d'obtenir la parité des fonctionnalités pour en faire une évidence pour les gens d'utiliser DSX.

Je suppose qu'à ce stade, vous l'avez testé jusqu'à présent sur des interfaces utilisateur et des applications de taille insignifiante. Qu'en est-il des non triviaux ? Qu'en est-il de ceux qui relèvent des cas extrêmes ? De plus, le temps réel que prend le processus n'est pas la seule partie pertinente - juste le fait que le développeur doit passer par une autre liste de contrôle d'actions manuelles avant de pouvoir construire est suffisant pour de nombreuses personnes.

Vous n'avez pas encore publié le code source du projet, donc personne n'a été en mesure de parcourir votre processus, de revérifier vos résultats et de suggérer des améliorations. À ce stade, tout ce que tout le monde peut vraiment faire est de vous croire sur parole qu'il est à la fois pratique et performant.

Vue utilise JSX

J'utilise Vue depuis près d'un an maintenant, et pendant ce temps, j'ai parcouru un bon nombre de dépôts de projets open source pour voir comment différentes choses sont faites. Bien que je ne me considère en aucun cas comme un maître de Vue, ce que je dirai, c'est que dans aucun d'entre eux, j'ai jamais vu JSX réellement utilisé - les gens semblent préférer massivement l'approche .vue (modèle -script-styling) sur l'approche render+JSX. Je ne savais même pas moi-même que Vue supportait même JSX (via un plugin Babel au moins) jusqu'à ce qu'après votre réponse, j'aie fouillé dans la documentation de Vue et découvert un petit extrait d'informations à ce sujet dans la section de la fonction de rendu .

Mais cela n'a rien à voir avec mon propos général. Vue est toujours un framework Javascript. Flutter n'est certainement pas le cas. En tant que tel, il existe de nombreuses raisons qui font de JSX la plus récente nouveauté dans un environnement centré sur Javascript qui ne se traduira pas par Dart + Flutter, dont beaucoup ont déjà été couvertes dans ce fil.

Il est !!!

Jusqu'à ce que je le voie se propager dans un environnement de développement non-Javascript, je serai respectueusement en désaccord.

Vue utilise JSX

Vue spécifie a une grande variété d'utilisations. JSX est juste "là". Mais ce n'est pas la syntaxe dominante
Vous pouvez connecter JSX à Angular si vous le souhaitez. Bien que personne ne le fasse

Les développeurs de React parlent comme si JSX était la voie du futur,
Il est !!!

Les composants Web sont un grand candidat pour l'avenir. Et ils sont utilisés directement en html similaire à ce que vous trouveriez dans Angular ou la forme la plus courante de Vue

@andrewackerman

le simple fait que le développeur doive passer par une autre liste de contrôle d'actions manuelles avant de pouvoir construire est suffisant pour décourager de nombreuses personnes.

Qui a parlé d'actions manuelles ? N'ai-je pas précisé que j'essayais d'obtenir une intégration complète et transparente de l'IDE (meilleure expérience utilisateur possible pour les développeurs).

Vous n'avez pas encore publié le code source du projet, donc personne n'a été en mesure de parcourir votre processus, de revérifier vos résultats et de suggérer des améliorations.

En quoi cela a-t-il quelque chose à voir avec les personnes utilisant DSX ? J'utilise JSX depuis plus de 2 ans et je me fous de son code source. Faut-il regarder le code source du compilateur Dart pour pouvoir programmer en Dart ?

ce que je dirai, c'est que dans aucun d'entre eux, j'ai jamais vu JSX réellement utilisé - les gens semblent préférer massivement l'approche .vue (modèle-script-style) à l'approche rendu + JSX.

JSX est un nouvel ajout, il faudra donc du temps pour se répandre, mais le point important à comprendre est que Vue accepte d'autres approches sans obliger les développeurs à utiliser "la bonne et la seule manière" que les choses doivent être faites dans Vue.

Vue est toujours un framework Javascript. Flutter n'est certainement pas le cas.

Riiiiight, donc au lieu de JSX, vous utilisez DSX avec Flutter.

@rrousselGit

Les composants Web sont un grand candidat pour l'avenir.

Les composants Web sont des zoobies, morts mais toujours en marche ; ils sont aussi répandus que les kangourous au Canada. Je pourrais continuer pendant des jours mais pour éviter de digresser...
https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/

@cbazza

Qui a parlé d'actions manuelles ? N'ai-je pas précisé que j'essayais d'obtenir une intégration complète et transparente de l'IDE (meilleure expérience utilisateur possible pour les développeurs).

Vous avez également dit que vous aviez besoin d'un support de prétraitement de la part de l'équipe Flutter/Dart pour ce faire. Suis-je dans l'erreur ?

En quoi cela a-t-il quelque chose à voir avec les personnes utilisant DSX ? J'utilise JSX depuis plus de 2 ans et je me fous de son code source.

JSX a été développé par Facebook pour React, soumis à un processus rigoureux de proposition/conception/implémentation/itération, puis publié dans le monde des années avant que vous ne mettiez la main dessus. Il a été rigoureusement testé et éprouvé maintes et maintes fois dans des environnements réels. C'est une technologie mature. Il n'y a aucune raison d'exiger de voir une fiche technique pour quelque chose comme ça.

DSX, d'autre part, est développé aujourd'hui par vous et une poignée de personnes. Vous avez parlé avec éloquence de ce qu'il peut et sera capable de faire, mais tout ce que nous avons réellement _vu_ est une petite poignée d'extraits de code spécialement conçus et votre mot qu'ils ont été générés par le transpileur. Les personnes qui ont même voulu l'essayer et suggérer d'éventuelles modifications ou améliorations ne sont pas en mesure de le faire, elles n'ont donc aucune raison de soutenir vos efforts au-delà de "Yay JSX!".

Je ne vous accuse pas de mentir ou quoi que ce soit, je dis simplement que JSX a gagné un niveau de confiance que DSX n'a ​​pas, alors comment allez-vous faire tourner la tête si vous ne laissez pas les gens bricoler avec ?

JSX est un nouvel ajout, il faudra donc du temps pour se répandre, mais le point important à comprendre est que Vue accepte d'autres approches sans obliger les développeurs à utiliser "la bonne et la seule manière" que les choses doivent être faites dans Vue.

JSX est dans Vue depuis presque 2 ans maintenant. Et contrairement à Vue lui-même, JSX est une technologie préexistante qui n'a pas besoin d'être présentée, en particulier pour les personnes familiarisées avec React. Si JSX allait prendre d'assaut le monde Vue.js, je ne peux pas m'empêcher de penser qu'il l'aurait déjà fait. (En particulier si cela indique qu'autant de personnes réclament JSX dans Flutter que vous le prétendez.)

Riiiiight, donc au lieu de JSX, vous utilisez DSX avec Flutter.

JSX et DSX sont le même concept syntaxique. Le problème est que, là où JSX a été construit sur un langage dynamique faiblement typé comme JavaScript, DSX est construit sur un langage statique fortement typé comme Dart. Cela signifie qu'il y a beaucoup de problèmes que DSX devra prendre en compte pour que JSX n'ait pas à le faire s'il s'agit d'autre chose qu'une implémentation de niche "JSX pour Flutter", et il faudra quelques modifications _ingénieuses_ pour que DSX fonctionne vraiment sans le rendre trop gonflé pour justifier de prétendre qu'il est visuellement plus concis.

Et pour répondre à la réfutation "DSX n'est que Dart, si DSX ne peut pas faire quelque chose, utilisez simplement Dart", alors ma contre-réfutation serait si je dois continuer à revenir à Dart chaque fois que je rencontre un scénario que DSX ne fait pas t gérer, alors pourquoi ne devrais-je pas simplement utiliser Dart tout le temps ?

Et pour répondre à la réfutation de cette lecture "vous pouvez si vous le souhaitez, DSX n'est qu'une option", alors vous vous vendez vraiment à découvert. Même si ce n'est vraiment qu'une "option", il faut encore apporter quelque chose sur la table qui convaincra les gens de l'utiliser. Vous avez vous-même dit que DSX n'est pas JSX, donc les gens qui veulent juste JSX n'obtiendront pas ce qu'ils veulent. Cela signifie qu'il doit y avoir des raisons tangibles au-delà de "l'attrait de type JSX" pour que les gens veuillent l'utiliser.

Si vous construisez simplement un outil que vous souhaitez utiliser vous-même, alors tout cela est sans objet et vous pouvez devenir fou. Mais si vous construisez réellement quelque chose que vous avez l'intention d'utiliser pour d'autres personnes, vous devez le mettre sous une forme solide, pourquoi vous pensez qu'ils le devraient.

Les composants Web sont des zoobies, morts mais toujours en marche ; ils sont aussi répandus que les kangourous au Canada. Je pourrais continuer pendant des jours mais pour éviter de digresser...

Un peu hors sujet, mais je voudrais souligner que les composants Web sont vraiment un regard prometteur sur l'avenir, même si leur prise en charge est ajoutée plus lentement que tar. Pensez-y de cette façon : React fait ce qu'il fait parce qu'il implémente essentiellement l'idée de composants Web en Javascript uniquement. Imaginez à quel point ce serait mieux si ces fonctionnalités étaient prises en charge par le navigateur et bénéficiaient de performances sans bac à sable et ne devaient pas fonctionner via la manipulation du DOM ? (C'est vrai qu'il faudra peut-être encore 20 ans avant de le découvrir, mais quand même...)

@andrewackerman

Désolé mec, je n'ai pas le temps de discuter sans fin et de répéter ce que j'ai déjà dit encore et encore; nous ne finirons pas d'accord de toute façon, alors bonne chance avec votre FLUI.

Vous avez parlé avec éloquence de ce qu'il peut et sera capable de faire, mais tout ce que nous avons réellement vu, c'est une petite poignée d'extraits de code spécialement conçus et votre mot qu'ils ont été générés par le transpileur.

Le transpileur DSX en ligne est en ligne depuis février 2018 et tout le monde peut l'utiliser, il n'est donc pas nécessaire de me croire sur parole. Appuyez sur "Compiler" et il compile ce qui est écrit sur le panneau de gauche et place les résultats sur le panneau de droite. Ouvrez le débogueur et vous verrez l'AST écrit.
https://spark-heroku-dsx.herokuapp.com/index.html

Le problème est que, là où JSX a été construit sur un langage dynamique faiblement typé comme JavaScript, DSX est construit sur un langage statique fortement typé comme Dart.

Cela ne fait aucune différence majeure, comme le concept et la syntaxe de la POO (programmation orientée objet) pour les "classes". C'est presque identique en Javascript sans type ou en Dart typé ; la même chose peut être dite pour l'instruction 'if', 'for', etc.

il doit encore apporter quelque chose sur la table qui convaincra les gens de l'utiliser.

Apparemment, c'est déjà le cas pour 100 personnes dans ce ticket ; et c'est 100 fois plus grand que moi qui l'utilise ; suffisant pour moi.

@cbazza

Désolé mec, je n'ai pas le temps de discuter sans fin et de répéter ce que j'ai déjà dit encore et encore; nous ne finirons pas d'accord de toute façon, alors bonne chance avec votre FLUI.

Je ne discute pas avec vous juste pour le plaisir d'argumenter ou à cause d'un parti pris anti-JSX profondément enraciné. J'essaie de vous amener à répondre à des questions auxquelles il faut répondre. Vous développez un outil que vous avez vraisemblablement l'intention d'utiliser pour d'autres personnes, mais vous n'avez toujours pas proposé de raison impérieuse _pourquoi_ ils devraient l'utiliser au-delà des avantages vagues et subjectifs de "familiarité" et "parce que c'est mieux". Le premier, comme je l'ai déjà dit, n'est pas nécessairement une bonne chose, et le second est pour l'instant une affirmation faite sans aucun support tangible.

Si vous voulez que votre outil soit un succès, il doit être gravé dans la pierre ce que vous faites et pourquoi vous le faites, et vous devez le faire de manière à ce qu'il puisse être facilement transmis aux autres. Cela ne veut pas dire que vous ne pouvez pas créer un produit tant qu'il n'est pas apprécié par _tout le monde_, mais des objectifs clairs et concis sont essentiels pour façonner la conception et la mise en œuvre. Sinon, vous allez simplement vous retrouver avec un utilitaire sans direction qui sera au mieux un produit de niche et sera extrêmement chanceux s'il se retrouve dans un code de production de n'importe quelle échelle.

Le transpileur DSX en ligne est en ligne depuis février 2018 et tout le monde peut l'utiliser, il n'est donc pas nécessaire de me croire sur parole. Appuyez sur "Compiler" et il compile ce qui est écrit sur le panneau de gauche et place les résultats sur le panneau de droite. Ouvrez le débogueur et vous verrez l'AST écrit.

Je n'ai même pas vu que ce lien était un exemple de travail. Je n'ai jamais utilisé herokuapp auparavant et cela ressemblait à un essentiel ou quelque chose, donc c'est sur moi. :P

(Bien que je précise que bricoler avec un bac à sable en ligne n'est pas la même chose que tester le transpiler dans un environnement plus pratique.)

Cela ne fait aucune différence majeure, comme le concept et la syntaxe de la POO (programmation orientée objet) pour les "classes". C'est presque identique en Javascript sans type ou en Dart typé ; la même chose peut être dite pour l'instruction 'if', 'for', etc.

Vous avez déjà dû faire face à une telle différence dans le typage fort de l'enfant . Qu'en est-il du typage fort des attributs ? Qu'en est-il des widgets dans différentes bibliothèques portant le même nom ? Que se passe-t-il si quelqu'un crée un widget avec plus d'un argument positionnel sans nom ? Que se passe-t-il si nous importons deux bibliothèques qui ont des widgets portant le même nom ? Que se passe-t-il dans certains scénarios auxquels je n'ai pas pensé pour montrer davantage la différence inhérente entre des systèmes comme Javascript et Dart ? Je dois dire que vous êtes si désinvolte sur ce point de discussion que je m'inquiète de la longévité de DSX dans un contexte réel.

Apparemment, c'est déjà le cas pour 100 personnes dans ce ticket ; et c'est 100 fois plus grand que moi qui l'utilise ; suffisant pour moi.

Encore une fois, ce sont 100 personnes qui ont voté pour le problème sur la base de "Considérez la syntaxe de type JSX dans le code de fléchettes". Ils ont voté pour parce qu'ils veulent _JSX_, et comme vous avez tenu à le souligner, DSX n'est pas JSX. Alors pourquoi voudraient-ils utiliser DSX ? Parce que la déclaration d'interface utilisateur de type XML en ligne est "l'avenir" ? Encore une fois, je ne le vois pas.

Nous avons déjà couvert JSX dans Vue qui n'obtient aucune traction, mais il y a aussi les deux alternatives React mentionnées dans l'article Web Components que vous avez lié : Inferno et Preact. Pour autant que je sache, ils n'ont pas réussi à faire de vagues dans le monde du développement d'applications Web basées sur JS, bien qu'ils prennent également en charge nativement la syntaxe de type JSX. Je pense vraiment que les gens doivent se pencher longuement sur _ exactement pourquoi _ les gens aiment JSX dans React, car de toute évidence, cela ne semble tout simplement pas être à cause de JSX lui-même. Si l'on peut répondre à _cette_ question, alors nous pouvons avancer vers des innovations "futures" plutôt que de simplement frankensteiner cette fonctionnalité de cette bibliothèque que nous avons aimé partout ailleurs, nous pensons personnellement qu'elle devrait l'être.

Penser à la quantité d'énergie qui a été investie juste dans cette discussion et à ce qui aurait pu être fait de bien pour améliorer le cadre actuel me rend plutôt triste.

@andrewackerman

Le problème est que, là où JSX a été construit sur un langage dynamique faiblement typé comme JavaScript, DSX est construit sur un langage statique fortement typé comme Dart.

Désolé, mais ce n'est pas un problème. De plus, cela n'a aucun sens. À côté de cela, nous utilisons JSX avec TypeScript.

@escamoteur absolument !

@escamoteur je suis avec vous sur celui-ci. _Les 100._

@Bessonov

Désolé, mais ce n'est pas un problème. De plus, cela n'a aucun sens. À côté de cela, nous utilisons JSX avec TypeScript.

React n'a pas été conçu pour TypeScript. Il a été conçu pour Javascript. Toutes les définitions de widgets, les attributs, les propriétés et tout le reste ont été conçus pour être utilisés dans l'environnement dynamique de JavaScript, de sorte que la sécurité de type de TypeScript n'introduit aucun nouveau facteur dans la manière dont JSX interagit avec React. Ceci est encore un autre exemple de la façon dont JSX a été conçu pour un cadre complètement différent de ce qu'est Flutter.

@andrewackerman
Pourquoi pensez-vous que c'est important? JSX est une façon de décrire l'interface. C'est une langue agnostique en soi. Regardez ici . Ce n'est pas JavaScript. Mais bon, pourquoi ça ne peut pas être fait avec JSX ? (De plus, il n'y a pas (encore) d'implémentation de cela)

Et... vous savez... le flux vient aussi de fb :

Flow est un vérificateur de type statique pour JavaScript.

S'il vous plaît, arrêtez de vendre des arguments pour et contre des extensions que vous n'avez jamais utilisées. J'utilise JSX tous les jours et j'en suis satisfait ATM, même si j'étais très sceptique à ce sujet. Je peux imaginer que JSX évolue dans d'autres modèles, comme c'était le cas avec AngularJS.

Et peut-être que ce sujet aide à trouver un meilleur modèle pour Dart ? DSX n'est qu'une proposition. Regardez l'exemple de modèle de générateur ci-dessus ou d'autres ajustements de langage présentés ici. Et bien, peut-être que votre grippe est une meilleure solution ? Je ne sais pas. Mais découvrons-le et aidons-nous les uns les autres à améliorer leurs suggestions au lieu de discuter des mauvaises choses dans la proposition de quelqu'un d'autre.

Je voudrais proposer de fermer ce sujet et d'ouvrir un nouveau sujet parapluie avec une conversation limitée. Toutes les propositions visant à améliorer la manière dont le flottement peut être utilisé, discutez objectivement dans vos propres sujets avec amour et sans haine.

Oui, la quantité de haine ici est épique, considérez simplement ceci :
Il y a 3587 tickets ouverts, si vous les triez par "pouces vers le bas" vous obtenez
1 (celui-ci) avec 57 "pouces vers le bas"
3586 (autres billets) avec 1 "pouce vers le bas" ou moins

@Bessonov

Pourquoi pensez-vous que c'est important? JSX est une façon de décrire l'interface. C'est une langue agnostique en soi. Regardez ici. Ce n'est pas JavaScript. Mais bon, pourquoi ça ne peut pas être fait avec JSX ? (De plus, il n'y a pas (encore) d'implémentation de cela)

C'est une façon de décrire l'interface utilisateur _en Javascript_ (d'où la partie "JS" du nom). Et non, puisqu'il s'agit d'un DSL en ligne, il n'est _pas_ indépendant de la langue. Et même si c'était le cas, cela n'en fait toujours pas le "meilleur choix", car il existe de nombreux DSL vraiment indépendants de la langue qui seraient terriblement inadéquats pour les déclarations d'interface utilisateur.

Et... vous savez... le flux vient aussi de fb :

Flow est comme TypeScript : un système de vérification de type statique pour Javascript. Ce n'est pas un outil React, et React n'a pas été conçu pour être utilisé avec lui. React est avant tout une bibliothèque Javascript, et JSX a été conçu pour être utilisé avec React. Quels que soient les outils et utilitaires secondaires introduits dans le développement de React, ils ne sont finalement pas pertinents pour l'interopérabilité React + JSX.

S'il vous plaît, arrêtez de vendre des arguments pour et contre des extensions que vous n'avez jamais utilisées. J'utilise JSX tous les jours et j'en suis satisfait ATM, même si j'étais très sceptique à ce sujet. Je peux imaginer que JSX évolue dans d'autres modèles, comme c'était le cas avec AngularJS.

J'ai utilisé JSX, et bien que j'aie des opinions personnelles à son sujet, j'ai délibérément laissé ces opinions en dehors de cette discussion. En fait, si vous aviez lu mes commentaires précédents, vous sauriez que j'avais félicité JSX pour avoir révolutionné le développement de l'interface utilisateur dans React. Hormis quelques commentaires légèrement tangentiels que j'ai faits sur la pénétration du marché de JSX dans son ensemble, mes arguments ont porté spécifiquement sur JSX _in Flutter_. Et sur ce sujet, il n'y a aucune base pratique pour déterminer l'efficacité de DSX, donc tout ce que nous pouvons faire est d'examiner comment JSX a été mis en œuvre dans d'autres endroits, et cet examen n'augure rien de bon.

À moins, bien sûr, que vous utilisiez DSX tous les jours et que vous puissiez nous éclairer sur les avantages pratiques de l'utilisation de DSX dans Flutter ?

Et peut-être que ce sujet aide à trouver un meilleur modèle pour Dart ? DSX n'est qu'une proposition. Regardez l'exemple de modèle de générateur ci-dessus ou d'autres ajustements de langage présentés ici. Et bien, peut-être que votre grippe est une meilleure solution ? Je ne sais pas. Mais découvrons-le et aidons-nous les uns les autres à améliorer leurs suggestions au lieu de discuter des mauvaises choses dans la proposition de quelqu'un d'autre.

_C'est ce que je fais._ DSX est proposé comme solution d'interface utilisateur pour les personnes familiarisées avec JSX. Certains éléments de conception clés de JSX étaient destinés à être utilisés dans un environnement complètement différent de Dart et Flutter. _Ces différences doivent être abordées pour que DSX réussisse._ Je ne suis pas un _hater_. J'essaie de promouvoir une discussion constructive et de poser les questions importantes. Pourtant, toutes les réponses que j'ai reçues se résument à une tautologie subjective ("JSX est bon parce que c'est l'avenir, et c'est l'avenir parce que c'est bon"), une agitation dédaigneuse des points de conception cruciaux ("DSX n'a ​​pas besoin de prendre en compte pour les différences entre JS et Dart parce qu'il n'y en a pas"), ou tout simplement hostile ("Vous n'aimez évidemment pas JSX alors arrêtez de parler de DSX").

Vous ne faites pas un produit réussi uniquement avec des éloges purs. Il doit également résister et rendre compte des critiques. Les gens qui se présentent et disent "OMG oui s'il vous plaît, faites du DSX", bien qu'édifiants, ne sont pas utiles. Il y a eu plusieurs personnes tout au long de ce fil qui ont soulevé des critiques parfaitement valables de DSX, à la fois avec sa conception initiale et avec le concept dans son ensemble. Et pour la plupart, bon nombre de ces critiques n'ont pas encore été directement adressées, l'attitude générale étant dédaigneuse.

Ma seule crainte est que tout cet amour inconditionnel pour JSX empêche les gens de voir DSX objectivement. Je comprends pourquoi vous voulez quelque chose comme JSX dans Flutter, et je peux comprendre - mon opinion que Flutter a besoin d'un DSL d'interface utilisateur dédié est ce qui m'a amené à créer flui. Mais si les seules personnes autorisées à parler de DSX sont celles qui n'ont que du bien à en dire, alors cela échouera.

Peut-on recentrer la discussion sur ce sujet ?
En fait, je ne vois aucune raison de garder ce problème ouvert.

L'équipe Dart a déclaré qu'elle avait d'autres priorités. Et le côté pro JSX s'est porté volontaire pour faire sa propre implémentation DSX

Peut-être devrions-nous avoir juste quelques référentiels open source proposant différentes solutions (même à peine fonctionnelles). Tels que DSX ou des modèles.
Et puis envisagez de rediriger depuis le fichier readme ou awesome_flutter de Flutter vers ces dépôts. Et s'il y a quelque chose qui bloque une implémentation DSX, créez un autre problème avec les détails.

Alors laissez la communauté faire son travail.

Laissez-le ouvert tel quel car les gens continueront d'ouvrir de nouveaux tickets demandant JSX (comme cela s'est déjà produit deux fois auparavant).

Laissez-le ouvert tel quel car les gens continueront d'ouvrir de nouveaux tickets demandant JSX (comme cela s'est déjà produit deux fois auparavant).

La différence ici est que nous serions maintenant en mesure de répondre avec ce qui suit :

"Nous ne prévoyons pas d'implémenter cela dans les fléchettes / flutter pour le moment. Mais vous pouvez jeter un œil aux alternatives de la communauté [ici] et [là] ou lire [ce numéro]"

et fermez le problème en double.

Un endroit pour les commentaires et les votes et c'est ici. La demande de fonctionnalité de type JSX ne disparaît pas et le ticket est ouvert car il nécessite le support des outils Flutter (compilateur et VS Code IDE) et j'ai mis à jour la demande de ticket avec cette information (premier commentaire). Si un nombre énorme de personnes commence à le demander, cela incitera l'équipe Flutter à y consacrer des ressources.

On dirait que la plupart de la controverse ici ne concerne pas JSX à ce stade, mais DSX. Je suggérerais de diviser la discussion DSX en son propre fil et de laisser celui-ci générique à JSX.

En fin de compte, DSX n'est qu'un moyen de se rapprocher de JSX, nous ne devrions donc pas mélanger ces deux discussions dans un fil malgré tout.

Gros non pour ça, je pense vraiment qu'un seul langage est un gros gain, la syntaxe jsx viendra avec plus de choses comme la séparation de xml de js, etc... Pas bon.

c'est mon avis.

C'est le problème Github le plus long et le plus inutile que j'aie jamais vu.

@cbazza Bon travail 👍
DSX + 1

@BarryYan , merci

Merci d'éviter ce genre de commentaire, que ce soit "+1" ou "Merci".
Cela envoie un email à tous les abonnés pour rien d'intéressant.

Merci d'éviter ce genre de commentaire, que ce soit "+1" ou "Merci".
Cela envoie un email à tous les abonnés pour rien d'intéressant.

Rien d'intéressant pour vous !!!
Veuillez éviter de dire aux gens ce qu'ils peuvent dire ou faire et concentrez-vous uniquement sur ce que vous pouvez dire ou faire.

@cbazza

Mec, c'est l'étiquette de base. Tout nouveau message sur ce fil de discussion envoie des e-mails à tous ceux qui y sont abonnés, il est donc impoli de publier un commentaire qui ne contribue pas à la discussion car cela agace les gens sans raison. Les réactions de base comme « +1 » et « Merci » peuvent être transmises avec un simple pouce levé, alors faites-le.

Cela étant dit, si ce fil de discussion s'est vraiment transformé en une discussion sur la question de savoir si quelqu'un devrait ou non publier un message "+1", c'est un grand drapeau rouge que toute discussion constructive est officiellement morte, et il devrait vraiment être fermé (peut-être définitivement cette fois).

@andrewackerman ,

J'ai compris, mais pendant que vous y êtes, vous devriez peut-être également tenir compte de l'étiquette de base tout en faisant exploser ce fil avec vos romans (écriture longue et fictive).

S'il vous plaît, arrêtez de répandre le FUD (craindre l'incertitude et le doute) avec votre barrage de questions insensées (vous savez, jetez autant de conneries sur le mur et voyez si quelque chose colle) et demandes.

Après tous vos écrits, vous n'avez ajouté aucune valeur à DSX, je n'ai donc aucun intérêt à discuter avec vous à ce sujet. Votre motivation est évidente cependant, faites la promotion de FLUI tout en faisant exploser DSX.

Dites-moi quelque chose, avez-vous des réponses à vos propres questions lorsqu'elles sont appliquées à FLUI ? Discutons un peu de FLUI d'accord ?

@cbazza

J'ai compris, mais pendant que vous y êtes, vous devriez peut-être également tenir compte de l'étiquette de base tout en faisant exploser ce fil avec vos romans (écriture longue et fictive).

Le fait que vous vous référiez à mes réponses que j'ai consacré beaucoup de temps et d'efforts pour être aussi réfléchies et impartiales que possible comme "écriture longue et fictive" illustre beaucoup votre personnage et votre approche cette discussion. J'essaie de promouvoir la discussion sur des problèmes très réels entourant toute implémentation de JSX dans Flutter, pendant que vous fustigez toute personne ayant une opinion contraire. Lequel d'entre nous est le plus grand contrevenant à l'étiquette de base ?

S'il vous plaît, arrêtez de répandre le FUD (craindre l'incertitude et le doute) avec votre barrage de questions insensées (vous savez, jetez autant de conneries sur le mur et voyez si quelque chose colle) et demandes.

La seule chose que j'exige, c'est que vous répondiez aux nombreux problèmes soulevés par de nombreuses personnes concernant DSX avec plus qu'une vague de main ou une hostilité ouverte. Pour quelqu'un qui propose un changement/ajout significatif à l'ensemble de fonctionnalités de Flutter, j'ai l'impression que ce n'est pas une attente déraisonnable.

Après tous vos écrits, vous n'avez ajouté aucune valeur à DSX, je n'ai donc aucun intérêt à discuter avec vous à ce sujet. Votre motivation est évidente cependant, faites la promotion de FLUI tout en faisant exploser DSX.

Je vous demande de défendre votre position. Vous avez dit à plusieurs reprises que JSX/DSX est le meilleur/futur, mais vous n'avez pas encore expliqué comment ou pourquoi. Plusieurs personnes ont exprimé des inquiétudes valables à propos de DSX, mais au lieu de les aborder, vous les écartez en vous cachant derrière le contre-argument "si vous ne l'aimez pas, ne l'utilisez pas". Mon "motif" est de vous amener à répondre aux questions qui doivent être posées concernant _n'importe quel_ projet technique, d'abord et avant tout pourquoi les gens devraient l'utiliser plutôt que les alternatives. (Et comme je l'ai déjà expliqué, la familiarité n'est pas une raison suffisante.)

En ce qui concerne FLUI, tout ce que je fais est de proposer une solution alternative au problème global (syntaxe déclarative de l'interface utilisateur pour Flutter) tout en demandant que les gens fassent la même chose que je fais pour DSX - offrir des critiques sincères et constructives. Je ne dis pas que FLUI est objectivement meilleur que DSX - je propose une alternative formée à partir d'une approche différente du développement de l'interface utilisateur et je demande aux gens de se forger leur propre opinion.

(Je voudrais également souligner que, à part ma mention initiale où je proposais une approche alternative possible à la représentation graphique, les seules fois où j'ai même parlé de FLUI, c'est quand vous en avez parlé. Alors, comment ça se passe logique que mon arrière-pensée soit d'en faire la promotion alors que vous en parlez plus que moi ?)

Dites-moi quelque chose, avez-vous des réponses à vos propres questions lorsqu'elles sont appliquées à FLUI ? Discutons un peu de FLUI d'accord ?

FLUI n'est pas DSX - il n'a pas à répondre à toutes les questions que je vous ai posées concernant DSX car beaucoup d'entre elles sont spécifiques à la conception de DSX. Cela ne veut pas dire qu'il n'a pas son propre ensemble de questions auxquelles il faut répondre, et non, je n'ai pas toutes ces réponses. C'est _pourquoi_ j'apprécie la discussion critique - FLUI/DSX ne résisteront pas à l'opinion publique à moins qu'ils ne puissent survivre à se faire ratisser à plusieurs reprises. Ce n'est pas l'endroit approprié pour discuter de FLUI. Si vous souhaitez discuter longuement de FLUI, le projet a son propre forum , alors n'hésitez pas à y poster.

Au lieu de répondre aux critiques, vous avez plutôt été défensif et évasif, à tel point que vous êtes directement responsable des deux occasions distinctes (approchant les trois) où ce fil a dû être temporairement fermé en raison de la surchauffe. Je vais donc rompre avec "l'étiquette" et dire ceci une fois : rangez votre ego, arrêtez d'interpréter les critiques comme des attaques personnelles et répondez aux questions importantes. Soit ça, soit faire la paix avec DSX qui ne décollera jamais.

andrewackerman Bon travail 👍
+ 1

@andrewackerman

Bon travail

Mec, tu reçois un compliment de @jstansbe qui transmet beaucoup plus d'informations qu'un pouce levé et tu baisses le pouce sur le compliment ?

De toute évidence, vous n'avez pas pris à cœur mon allusion à la longueur, mais ne tirez pas de conclusions sur mon personnage car vous ne me connaissez pas du tout.

Le fait que vous vous référiez à mes réponses que j'ai consacré beaucoup de temps et d'efforts pour être aussi réfléchi et impartial que possible

Que j'apprécie et que je lis tous vos "longs écrits", en répondant à tout : non, mais quand je réponds correctement, vous ne comprenez pas ma réponse et concluez que je suis dédaigneux.

Il est évident pour moi que vous n'êtes pas très expérimenté avec JSX, vous ne comprenez vraiment pas comment cela fonctionne. Donc, au lieu de doubler, possédez-le et je vous l'expliquerai plus en détail. Par exemple, JSX & DSX ne font que les 2 transformations suivantes (mentionnées plusieurs fois auparavant) :

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

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

Tout le reste est géré par le langage hôte, par exemple : comment gère-t-il l'importation de composants portant le même nom ; réponse : langue d'accueil. Je ne suis pas dédaigneux, c'est la façon dont il est conçu et la source de sa force. Vous voyez si vous séparez le balisage et la programmation dans des fichiers séparés, vous commencez à dupliquer la programmation à l'intérieur du balisage avec des constructions simples pour 'if', etc. Vous finissez par construire un langage de programmation déclaratif à l'intérieur du balisage qui ne peut jamais être aussi puissant que le langage de programmation principal. Ainsi, en introduisant le balisage dans le langage de programmation, vous avez le meilleur des deux mondes et c'est la puissance de JSX/DSX.

Remarquez ci-dessus sur (2) que la transformation codée en dur <Widget> et ce n'est pas toujours le cas, vous pouvez donc maintenant le spécifier si nécessaire, comme indiqué précédemment. Regardez les transformations et maintenant tous les symboles proviennent de la source ou peuvent être spécifiés afin qu'il n'y ait pas de pièges magiques majeurs à l'avenir.

tandis que vous fustigez quiconque ayant une quelconque forme d'opinion contraire.

Ce n'est pas vrai, vous pouvez avoir une opinion contraire mais vous ne pouvez pas prétendre quelque chose de vrai quand je peux prouver le contraire.

Pour quelqu'un qui propose un changement/ajout significatif à l'ensemble des fonctionnalités de Flutter, j'ai l'impression que ce n'est pas une attente déraisonnable.

Mais c'est le problème, je voulais que l'équipe Flutter implémente DSX, mais je l'ai fait, donc ce qu'ils doivent implémenter, ce sont des éléments génériques qui ne dépendent pas de DSX et DSX n'est pas le seul bénéficiaire. Le moteur js du navigateur prend en charge les cartes source qui ont activé un écosystème de nouvelles langues dans le navigateur qui s'est transpilé en js ; il a permis la création de Dart !!! et plusieurs autres (Coffeescript, Typescript, Reason, etc.). Dart pourrait faire de même maintenant et bénéficier de l'écosystème qu'il contribue à faire monter, tous les bateaux montent.

Je vous demande de défendre votre position.

Je l'ai déjà fait plusieurs fois et la conclusion est que Plain Dart ou DSX se résume à la préférence de l'utilisateur ; et l'important est de fournir une option au lieu de forcer les gens à aller dans un sens.

d'abord et avant tout pourquoi les gens devraient l'utiliser plutôt que les alternatives.

J'utiliserais DSX parce que je le préfère, comme les espaces ou les tabulations, la définition de type avant ou après le nom de la variable. Il ne sert à rien de se battre pour cela, acceptez simplement que les gens aient des préférences différentes ; il y a plus d'un éditeur de programmation là-bas, n'est-ce pas ?

la familiarité n'est pas une raison suffisante

Juste votre opinion, pourquoi utilisons-nous les instructions "if" dans presque toutes les langues, les instructions "for", "class", et maintenant "asyn/wait".

Ce n'est pas l'endroit approprié pour discuter de FLUI. Si vous souhaitez discuter longuement de FLUI, le projet a son propre forum, alors n'hésitez pas à y poster.

Très bien, maintenant tu as gagné mon respect.

vous êtes directement responsable des deux occasions distinctes (approchant les trois) où ce fil a dû être temporairement fermé en raison de la surchauffe.

Le fait est que même s'il est à nouveau fermé, cela n'empêchera pas les gens de demander des fonctionnalités de type JSX.

rangez votre ego, arrêtez d'interpréter les critiques comme des attaques personnelles et répondez aux questions importantes.

Je n'ai pas d'ego mais j'ai un tempérament court donc il n'y a pas d'erreur quand quelqu'un me fait chier (ça sort tout de suite). Sans vouloir t'offenser mais tes questions n'étaient pas importantes.

Soit ça, soit faire la paix avec DSX qui ne décollera jamais.

Vous n'êtes pas le compteur utilisé pour mesurer le succès et vous ne savez pas ce que je fais.

Mec, tu reçois un compliment de @jstansbe qui transmet beaucoup plus d'informations qu'un pouce levé et tu baisses le pouce sur le compliment ?

Vous n'avez apparemment pas compris le sarcasme inhérent à son commentaire. (Il a littéralement fait tout ce que j'ai dit de ne pas faire.) Bien que ce soit un peu amusant de pêche à la traîne que je peux apprécier, ce n'est pas approprié ici. Et si, par hasard, il était sincère, alors je m'excuse pour ma sarcastique, mais mon argument est toujours valable - ce genre de commentaire n'est _toujours_ pas approprié ici.

Il est évident pour moi que vous n'êtes pas très expérimenté avec JSX...

Mon avis de non-responsabilité dans mon tout premier commentaire sur ce fil vous a-t-il peut-être alerté ?

... vous ne comprenez vraiment pas comment cela fonctionne.

Vous considérez que je n'ai pas beaucoup d'expérience avec JSX et que je ne sais pas du tout comment cela fonctionne ? Bien que je n'aie jamais travaillé sur un projet React sérieux, j'ai fait ma part de bricolage. Je comprends parfaitement comment cela _fonctionne_.

Tout le reste est géré par le langage hôte, par exemple : comment gère-t-il l'importation de composants portant le même nom ; réponse : langue d'accueil.

Et cela a du sens dans le cas où le langage de balisage et le langage hôte sont distincts. Avec JSX, le langage de balisage est conçu comme une _extension_ du langage hôte. En tant que tel, JSX a été conçu comme une extension de JS, et c'est pourquoi il fonctionne aussi bien. DSX est une implémentation de JSX pour Dart.

Vous ne voyez pas le problème là ? Un langage de balisage conçu comme une extension d'un langage étant truqué dans un langage fondamentalement différent. Il est _inévitable_ qu'il y ait une foule de problèmes, de cas extrêmes et de considérations.

Vous voyez si vous séparez le balisage et la programmation dans des fichiers séparés, vous commencez à dupliquer la programmation à l'intérieur du balisage avec des constructions simples pour 'if', etc. Vous finissez par construire un langage de programmation déclaratif à l'intérieur du balisage qui ne peut jamais être aussi puissant que le langage de programmation principal.

Tout d'abord, l'idée derrière la séparation du balisage et de la programmation est que, si vous le faites correctement, il existe une séparation claire entre les deux, ce qui entraîne _aucune_ duplication.

Deuxièmement, si vous faites quelque chose de beaucoup plus complexe que if s et for s dans votre code d'interface utilisateur (qui sont des constructions qui peuvent facilement être gérées dans de nombreuses solutions de balisage), alors je dirais que c'est un signe qu'il y a quelque chose qui ne va pas dans votre conception de toute façon. Selon les principes de conception MVC/MVVM, si vous intégrez une logique complexe dans vos constructions d'interface utilisateur, c'est un signe potentiel de code malodorant et vous devriez de toute façon sérieusement envisager une refonte.

(Cela ne veut pas dire que vous _ne pouvez pas_ écrire une interface utilisateur déclarative à la manière de MVVM en utilisant JSX, mais c'est juste quelque chose qui crée des problèmes pour un petit gain objectif. Pourquoi utiliser quelque chose dans lequel vous _pouvez_ écrire du code conforme aux normes lorsque vous pouvez utiliser quelque chose qui rend difficile l'écriture de code qui _n'est pas_ ?)

Ce n'est pas vrai, vous pouvez avoir une opinion contraire mais vous ne pouvez pas prétendre quelque chose de vrai quand je peux prouver le contraire.

Vous n'avez rien "prouvé". Vous avez donné un tas d'affirmations subjectives qui n'ont pas encore été étayées par une logique justificative. (Bien qu'à votre crédit, ce dernier message est une grande amélioration.)

Mais c'est le problème, je voulais que l'équipe Flutter implémente DSX, mais je l'ai fait, donc ce qu'ils doivent implémenter, ce sont des éléments génériques qui ne dépendent pas de DSX et DSX n'est pas le seul bénéficiaire.

Vous leur demandez toujours de faire des choses non triviales, il vous incombe donc de les convaincre, ainsi que le reste d'entre nous, pourquoi ils devraient et pourquoi il est si important qu'ils mettent d'autres choses sur leur liste de choses à faire.

Le moteur js du navigateur prend en charge les cartes source qui ont activé un écosystème de nouvelles langues dans le navigateur qui s'est transpilé en js ; il a permis la création de Dart !!!

C'est dans la nature de JS lui-même qu'une telle chose est facilement réalisable (relativement parlant), à tel point que Dart est loin d'être le seul langage qui a un transpileur vers JS. Comme je l'ai souligné à plusieurs reprises, Dart n'est pas JS. Il est statique et fortement typé, ce qui signifie que beaucoup de choses qui seraient faciles à faire dans JS sont extrêmement complexes dans Dart.

J'utiliserais DSX parce que je le préfère, comme les espaces ou les tabulations, la définition de type avant ou après le nom de la variable. Il ne sert à rien de se battre pour cela, acceptez simplement que les gens aient des préférences différentes ; il y a plus d'un éditeur de programmation là-bas, n'est-ce pas ?

Selon cette logique, je devrais créer une solution d'interface utilisateur dans laquelle vous définissez des constructions à l'aide de braille codé en hexadécimal. Je veux dire, si tout ce qui compte vraiment, c'est la préférence personnelle, tout ce que j'ai besoin de dire pour défendre son existence, c'est que "certaines personnes la préfèrent", n'est-ce pas ?

Vous développez un outil que vous souhaitez que d'autres personnes utilisent, vous avez donc besoin d'un raisonnement au-delà de "certaines personnes pourraient l'aimer" pour vous rendre convaincant. Si vous ne pouvez pas le mettre en mots _pourquoi_ ils devraient l'utiliser sur autre chose, alors qu'est-ce qui vous fait croire qu'ils le feront ? Et qu'y a-t-il pour vous inciter à _assurer_ qu'ils le feront lors de la conception de l'ensemble de fonctionnalités de DSX ?

Juste votre opinion, pourquoi utilisons-nous les instructions "if" dans presque toutes les langues, les instructions "for", "class", et maintenant "async/wait".

Tout d'abord, ces mots-clés (à part async/await ) sont devenus un lexique de programmation courant en raison de l'immense popularité de langages comme C et BASIC au cours de plusieurs décennies. Comme je l'ai déjà mentionné, JSX est loin d'avoir fait ses preuves dans sa longévité - il existe depuis 5 ans et n'a pas encore vu d'utilisation significative en dehors de React malgré la disponibilité de l'option.

Deuxièmement, il y a une grande différence entre familiarité et convention. if , while , for , struct , class , enum , try/catch/finally , async/await ... ce sont tous d'excellents moyens de représenter verbalement un concept. Il y a des raisons de défendre l'utilisation de ces mots-clés au-delà du simple fait qu'ils sont familiers aux gens - ils ont un sens conceptuel. (Bien sûr, cela ne veut pas dire qu'ils sont des constantes. Certains langages font if ... then . Certains font if ... elif tandis que d'autres font if ... else if et d'autres encore font if...endif . Certains font foreach , d'autres font from . Et ainsi de suite.)

Pendant ce temps, l'argument d'utiliser JSX parce qu'il est "familier" ne rentre pas dans la même catégorie. JSX est une façon de représenter l'interface utilisateur déclarative, mais ce n'est ni la seule ni la plus populaire. De plus, il a été conçu pour être utilisé dans un type d'environnement, donc l'utiliser dans un autre environnement peut transformer la familiarité en une mauvaise chose - la familiarité les amène à s'attendre à ce qu'il fonctionne plus ou moins exactement de la même manière qu'il fonctionne ailleurs, donc s'il cela ne mène-t-il pas alors à une déconnexion mentale qui est quelque chose que vous voulez _éviter_.

Le fait est que même s'il est à nouveau fermé, cela n'empêchera pas les gens de demander des fonctionnalités de type JSX.

Ils le demandent quand même, et le problème est tout de même redirigé ici. Je ne vois pas en quoi la fermeture du fil changerait cela.

Vous n'êtes pas le compteur utilisé pour mesurer le succès et vous ne savez pas ce que je fais.

Lisez n'importe quel livre sur la conception de produits. Le premier chapitre consiste toujours à créer une déclaration, un manifeste, un slogan, tout ce qui est tangible et exprimable dans un anglais simple qui décrit ce qu'est le produit et pourquoi les gens devraient s'en soucier. Il y a une raison pour laquelle la forme de conseil la plus courante donnée aux entrepreneurs amateurs est de faire un "elevator pitch", quelque chose qui communique clairement et de manière concise le produit et le tirage au sort en 30 secondes ou moins. Si vous ne pouvez pas dire succinctement pourquoi les gens devraient utiliser votre produit, c'est le signe qu'il souffre d'une crise d'identité. Si la personne qui conçoit le produit ne peut pas répondre de manière adéquate aux critiques, cela donne l'impression d'un manque de confiance en son propre produit. Ces deux choses sont de grands drapeaux rouges pour les investisseurs.

Dans cette situation, le produit est DSX et les investisseurs sont des développeurs qui envisagent de l'utiliser. Les seules personnes que vous avez pour vous soutenir sont des personnes qui, apparemment, encourageraient inconditionnellement tout ce qui contient "JSX" dans la description. Toutes les autres personnes dans ce fil que j'ai vues se demander ce que vous faites sont reparties apparemment peu convaincues après votre réponse.

Vous êtes actuellement assis à ou près d'un taux de conversion de 0 %, et _c'est_ d'où je viens quand je dis que vous n'avez pas encore répondu de manière adéquate aux critiques. Peut-être que vous ne vous en souciez pas, mais si vous avez sérieusement l'intention de faire de DSX un plug-in de balisage de déclaration d'interface utilisateur utilisable et utilisé dans des projets réels, vous voudrez peut-être commencer.

Mais là encore, vous êtes peut-être une exception.

Ok, cette conversation est allée bien au-delà des types de discussions que nous considérons comme acceptables dans la communauté Flutter, et je vais donc verrouiller ce fil et fermer le bogue. Veuillez envisager de lire https://flutter.io/design-principles/#conflict-resolution pour plus de détails sur la façon dont nous nous comportons ici.

La prochaine étape, si quelqu'un veut contribuer au code pour résoudre ce problème, serait de proposer une conception de la manière de créer l'intégration du système de sorte que nous puissions faire fonctionner la génération de code avec Gradle, Xcode, le rechargement à chaud et l'intégration avec les applications existantes. Si quelqu'un est intéressé à travailler dessus, n'hésitez pas à me contacter. Sinon, je pense que c'est quelque chose sur lequel nous travaillerons au début de l'année prochaine. Une fois que nous aurons un mécanisme pour le faire, des solutions comme DSX seront faciles à intégrer dans l'écosystème Flutter. On peut même trouver des solutions qui devraient être intégrées par défaut. En attendant, nous travaillons également sur des améliorations de la syntaxe de Dart pour voir si nous pouvons rendre les expressions d'interface utilisateur encore plus faciles à écrire.

Je voudrais demander aux gens de ne pas ouvrir de nouveaux bogues sur ce sujet à moins qu'il n'y ait quelque chose de très constructif et de nouveau qui mérite d'être évoqué.