Flutter: Considere o tipo JSX como React Native

Já faz muito tempo que isso é perguntado:
https://github.com/flutter/flutter/issues/11609
Protótipo funcional desenvolvido:
https://spark-heroku-dsx.herokuapp.com/index.html
Isso mostra a alternativa e alguns benefícios...

O problema atual com o DSX é sobre a integração adequada com as ferramentas Flutter para fornecer uma ótima experiência ao desenvolvedor com depurador, preenchimento automático, etc. trabalhando em arquivos .dsx.

Dizer aos usuários que eles podem usar o DSX, mas não podem usar o depurador ou aproveitar o preenchimento automático, não é um começo para mim. Se alguém quiser ajudar, o que eu preciso é descobrir uma maneira de adicionar suporte completo ao pré-processamento (com mapa de origem) para Dart Tools e VS Code Dart plug-in. é um superconjunto do Dart, mas compila tudo para o Dart) funcionaria.

Se puder e quiser ajudar, conte comigo.

Eu não posso concordar. Especialmente usando um IDE como o Dart Code, você obtém tags de fechamento virtuais, o que facilita muito a leitura. Com Dart2, onde você pode omitir new , ficará ainda melhor.

Também acho que desencoraja você a construir árvores de widget muito grandes sem desconstruí-la em classes de widget menores e mais fáceis de manter.

Eu uso o Android Studio. Eu nem vejo uma tag de fechamento virtual. Apesar de termos uma tag de fechamento virtual, é mais complicado que o HTML que todo mundo odeia. Dart é apenas uma linguagem de programação. As pessoas no Google não entendem a importância da simplificação.

Eu não acho que gostaria de uma sintaxe semelhante ao JSX, mas sim, eu uso o IntelliJ e algo precisa ser feito com as ferramentas para que o código da interface do usuário seja mais fácil de entender.

Também acho que desencoraja você a construir árvores de widget muito grandes sem desconstruí-la em classes de widget menores e mais fáceis de manter.

Não vejo como isso é diferente do JSX... à medida que a árvore fica maior, você pode dividir em sub-árvores menores com ambos.

Eu não acho que gostaria de uma sintaxe semelhante ao JSX, mas sim, eu uso o IntelliJ e algo precisa ser feito com as ferramentas para que o código da interface do usuário seja mais fácil de entender.

e deve ser fácil de ler em todas as plataformas e não apenas no Intellij; Quero dizer, deve ser fácil de ler no Bitbucket ao revisar o código; e também deve ser válido ao usar qualquer editor; Quero dizer, com essas 'anotações de comentários', o que acontece se alguém usando 'vi' digitar um comentário diferente lá?

Esta é uma duplicação do bloqueado # 11609
@sethladd ?

Desculpe, você deve estar vendo as "tags de fechamento virtuais" no IntelliJ e no Android Studio.

cc @devoncarew para verificar qual versão ativou isso ou se o usuário precisa aceitar?

Agradecemos seus comentários sobre: ​​sintaxe semelhante a JSX. Acreditamos que há oportunidades em todo o idioma, nossas ferramentas e plugins para facilitar a edição do código da interface do usuário.

Isso engana # 11609, mas eu gostaria que @devoncarew ou @mit-mit adicionasse uma nota sobre como ativar "tags de fechamento virtuais", se possível.

Obrigado!

@JonathanSum , infelizmente, os rótulos de fechamento não estão disponíveis no Android Studio 3.0. Você precisará de pelo menos o IntelliJ 2017.3 ou o Android Studio 3.1. O Android Studio 3.1 está atualmente no estágio de release candidate e planejamos lançar um plug-in de vibração com suporte para ele amanhã.

Independentemente da conversa em torno de uma sintaxe do tipo JSX, queremos trabalhar para facilitar a escrita de código de interface do usuário no Dart, tanto no IntelliJ/Android Studio quanto no VS Code. Esse é inicialmente o trabalho da gravadora de fechamento, mas também a visualização recente do Flutter Outline. Isso mostra a estrutura do seu método build() em uma visualização de estrutura de tópicos e permite que você navegue pelos widgets e veja mais facilmente seus relacionamentos pai/filho. Isso está atualmente disponível no IntelliJ - esperamos poder trazê-lo para o VS Code também.

@zoechi - Isso pode ser um engano; mas o outro fio esquentou e travou. Portanto, não há como contribuir para essa conversa. Eu não acho que você deva fechar este tópico como um dup só porque você não gosta de pessoas pedindo um recurso. Este provavelmente deve ser o novo tópico para respostas para novas pessoas que chegam e solicitam suporte JSX (ou funcionalidade semelhante).

@sethladd - Por favor, não bloqueie este tópico; Eu acho que ter a comunidade discutindo prós e contras sobre métodos alternativos de layout é útil. Eu teria participado do #11609 se não estivesse bloqueado.

Eu venho de um fundo NativeScript. Devo dizer que esta é uma área em que sinto que o NativeScript é consideravelmente mais fácil de usar do que o Flutter. Posso obter telas bastante complexas funcionando em menos de 5 minutos e iterar facilmente o design rapidamente. Em seguida, adicione o código que executa a tela.

No NativeScript, na verdade, temos os seguintes arquivos:

• screen.js / screen.ts (.ts é transpilado para .js se você preferir texto datilografado). Esta é a lógica principal para a tela que você está exibindo.
• screen.css (ou screen.android.css e/ou screen.ios.css ) que é uma versão muito mais limitada do CSS, mas suporta coisas como altura, largura, cor, plano de fundo, etc. Na maioria das vezes um único arquivo css é necessário, mas ocasionalmente, se você estiver fazendo algo estranho, poderá separar seu css para android e ios. Ele tem suporte completo para Classes, Elementos e id's Então eu posso fazer TextArea.Login #Password e ele realmente se limitará apenas a essa cadeia de elementos específica.
• screen.xml (novamente ou screen.android.xml e/ou screen.ios.xml ) - Este é o layout da tela. Você PODE codificar o layout em JS se quiser (basicamente como flutter); mas o XML é muito mais fácil. Exemplo:

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

O interessante é que ActionBar é um componente específico somente para página (ou seja, é específico apenas para Page); então basicamente o que acontece é a página do analisador XML See; cria um novo Elemento de Página; em seguida, cria um componente ActionBar que executa uma função builderChild no componente Page; o componente de página substitui o builderChild padrão e verifica se o filho é um ActionBar; se for; em seguida, ele a atribui internamente à variável apropriada; caso contrário, o restante é passado pelo pai/super, que o atribui aos componentes "filho" ou "filhos" automaticamente. O sistema de compilação é incrivelmente versátil, pois cada componente pode usar a função builderchild do pai ou substituí-la para fazer itens extras como suporte <Label>Hi</Label> e atribuir isso ao valor Text automaticamente. Isso torna o layout incrivelmente fácil de instalar e executar sem nenhum código.

Como a maioria dos editores tem boa capacidade de edição de XML, ele é automaticamente colorido e com a definição xsd apropriada, o intellij (& vscode) faz verificação automática e suporte limitado ao contexto.

Agora, tecnicamente, tudo é na verdade um componente JavaScript; então você pode fazer tudo isso manualmente (como o que o Flutter faz); mas acho que a facilidade de criar uma tela é trivial no NativeScript. E você não precisa do JS ou CSS quando inicia; então você pode adicionar o CSS (normalmente você não codifica no layout as propriedades baseadas em CSS; mas você pode, se quiser).

A coisa boa sobre isso; é que permite que os desenvolvedores da Web entrem de cabeça com muito pouco (se houver) retreinamento. Na verdade; por causa de seu renderizador flexível e por ser baseado em JS - o NativeScript realmente suporta Angular e Vue - para que você possa compartilhar cerca de 95% da base de código entre a Web e seu aplicativo móvel se usar Angular ou Vue. Uma vez que usa componentes nativos do sistema operacional como react native (não uma visualização da web como cordova); é realmente um sistema multiplataforma decente (que é melhor que o React Native). No entanto, posso ver onde existem alguns pontos fortes que o Flutter tem que o tornam uma boa ferramenta complementar para alguns desenvolvimentos móveis, pois há alguns aplicativos nos quais o NativeScript é pior e alguns ainda são muito melhores e com base nas respostas ao meu questões de Ian; continuará a ser a ferramenta consideravelmente melhor para essas áreas.

É melhor abrir esse tópico bloqueado e copiar esses comentários lá para que tenhamos um histórico de discussões completas.

@JonathanSum não é sobre se alguém quer ou não quer o recurso,
é se este é o lugar para ter uma discussão acalorada sobre isso. Eu acho que reddit ou similar são lugares melhores.

@cbazza - não discordo; mas você tem que ter muito cuidado no futuro para não insinuar coisas sobre as pessoas. Isso só inflama a discussão, não importa o quão idiota você acredite que eles estão sendo.

@zoechi - Na verdade, acredito que qualquer discussão sobre um novo recurso deveria estar aqui. O histórico deve ser mantido para que quando John Doe chegar daqui a um mês e pesquisar sobre o recurso XYZ ele possa :+1: um recurso existente e/ou contribuir para ele.

Eu não acho que o tópico está realmente bloqueado por tanto tempo por causa dos meus comentários. Se o que eu disse foi tão ruim como é que posso comentar tudo, como por exemplo este tópico?

O tópico está bloqueado porque a equipe do Flutter não tem interesse em fazer isso e só quer que as pessoas parem de falar sobre isso.

Vamos manter a discussão nesta edição focada em casos de uso e exemplos para um recurso do tipo JSX.

Na verdade, se o NativeScript é tão bom, por que se preocupar com o Flutter em vez de tentar fazer o Flutter NativeScript como.
Estou vindo de uma plataforma baseada em XML (Xamarin Forms) e pensei no começo que poderia ser mais difícil projetar em código, mas esse não é o caso.
Pelo contrário, é muito fácil dividir seu design em classes separadas que são fáceis de manter.

JSX está projetando em código !!!

@sethladd

Vamos manter a discussão nesta edição focada em casos de uso e exemplos para um recurso do tipo JSX.

OK, vamos falar sobre o meu design DSX que pode ser visto aqui:
https://spark-heroku-dsx.herokuapp.com/index.html

Ele fornece um mapeamento direto para a forma atual como os widgets são construídos e ainda fornece um sabor semelhante ao JSX que é muito leve e familiar aos desenvolvedores do React. Está faltando alguma coisa nesse projeto? Esse design pode gerar todos os widgets possíveis na natureza?

Regra geral, se você sentir que um ponto de exclamação não é suficiente, você provavelmente deve se afastar do teclado e fazer uma pausa.

Sou um novato no Flutter, tendo apenas alguma experiência com Android e Java, e devo dizer que acho o que o Flutter oferece muito melhor do que o que está sendo proposto aqui. Eu tendo a achar que XML é feio e pesado. É muito mais bonito ter um personagem final singular, em vez de um mar deisso torna meu código 5x mais longo, um ódio meu ao editar o XML do Android e apenas tags de fechamento virtuais que a grande maioria dos IDEs que as pessoas usam suportam. Isso é incrivelmente útil ao projetar estruturas mais longas. O XML de aninhamento puro fornecido simplesmente não supera o resto das desvantagens, na minha opinião, especialmente quando 'child:/children:' faz um trabalho quase tão bom quanto. Dart é incrivelmente limpo, e é por isso que gosto tanto dele. Eu ficaria incrivelmente desapontado se isso fosse arruinado.

Eu sei que o React faz assim, mas da última vez que verifiquei, este lugar diz Flutter. Só porque o React faz isso não significa que temos que fazê-lo - você não é o único a pular do navio para aqui! Concordo muito com todos os pontos que o @escamoteur fez. Não vejo sentido em adicionar mais uma linguagem que as pessoas precisam manipular ao usar o Flutter. Já estamos usando o Dart para programar a maior parte, não precisamos de muitas outras coisas para dominar! A consistência e a simplicidade devem ser valorizadas.

Algumas observações do seu DSX vs snippets de Dart gerados:

1. Subjetivo: não vejo grandes ganhos de legibilidade. Verbosidade é semelhante - se não um pouco mais. O plug-in Dart IDE fornece tags de fechamento automático, que espelha as tags de fechamento de marcação declarativa. Se JSX é design em código, não vejo como os widgets no Dart não são.

2. Várias propriedades em <vars>

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

Ser capaz de definir estilos globais misturando várias propriedades é uma boa ideia.
No entanto, quando estou olhando para minha modesta experiência de vibração, não vejo onde eu usaria isso.

Para Text , parece que a maior parte do que preciso reutilizar está definida em TextStyle , em vez de uma mistura de várias propriedades. Talvez você possa encontrar outro exemplo além de Text onde esse não é o caso.

Olhando para TextStyle , acho que o atual imutável + copy() é ótimo para reutilizar e compor no Dart:

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

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

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

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

Para Container reutilizável compartilhando um mesmo estilo, acho que criar um widget sem estado personalizado funciona melhor do que um <vars> definido externamente. Na maioria das vezes, quero também um preenchimento, uma tinta, um ouvinte de gestos ou uma sombra.

Para qualquer um desses casos, eu precisaria compor Container com outro widget: Material , Padding , Center etc. widget de "contêiner" reutilizável personalizado de qualquer maneira, não vejo muito ganho em ter um estilo <vars> externo que apenas definiria as propriedades de um único widget na minha hierarquia de widgets reutilizáveis.

Não vejo que "tudo é um widget" do Flutter funcione bem com estilos de "múltiplas propriedades".

1. Não destacado em seus exemplos atuais de DSX: Como você codificaria uma interface com widgets dinâmicos? Significado: como mostrar ou não alguns widgets dependendo de uma condição.

Ao fazer design no Dart, é fácil e conveniente adicionar ou não um widget específico em children .
Também é muito conveniente envolver dinamicamente um widget com outro. Isso torna a função build() fluente e fácil de entender.

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

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

    children.add(wb);

@SirComputer1 a proposta do DSX é uma adição, a maneira atual não muda, então se você não gostar, não use, continue como está hoje.

A coisa <var> só foi feita para a demonstração porque eu não queria analisar o Dart completo. A solução final não incluiria <var> , mas usaria qualquer variável de dardo. Além disso, o '@' foi feito apenas para a demonstração para facilitar a análise. A solução final não a incluiria.

Não se esqueça de que qualquer outra coisa no arquivo é seu código Dart normal, então você pode usar isso para todo o resto.

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

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

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

    children.add(wb);

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

Vamos parar de comparar o DSX com o atual, um não está competindo com o outro. Algumas pessoas vão preferir JSX e este tópico é para elas. O que eu quero saber é como posso melhorar o DSX para lidar com coisas para as quais ele não funcionará.

@escamoteur - Eu não costumo usar um martelo como chave de fenda. Avalio as diferentes tecnologias e uso a adequada para o caso de uso adequado. Isso não significa que suas coisas não podem ser alteradas para melhor em cada uma das plataformas. :sorrindo:

Por exemplo; integração de plugins de terceiros. O NativeScript é verdadeiramente rei sobre todas as outras plataformas cruzadas. Nada mais remotamente se aproxima do NativeScript; e integração de terceiros. Eu tenho um cliente perguntando sobre o uso de https://github.com/vipulasri/Timeline-View . Flutter praticamente impossível; O NativeScript me dá algumas horas e funcionará como qualquer outro controle NS, provavelmente, mesmo com a vinculação de dados totalmente funcional. Por outro lado, a vibração tem alguns pontos fortes sérios, onde NS sinaliza ...

Use a ferramenta adequada para o trabalho. :sorrindo:

Eu tendo a gostar do layout de tela baseado em XML; mas eu entendo porque as pessoas não. Adicionar a capacidade de construção baseada em XML NÃO significa eliminar o método existente; é apenas complementar ; escolha. Para quem não se deu ao trabalho de ler, posso fazer a mesma cadeia de chamadas em NS que fazemos em flutter; mas usar xml é muito menos digitação e mais fácil de ler. Cada um tem suas preferências...

Eu realmente pensei em adicionar um renderizador baseado em XML ao Flutter como um POC; mas não tenho tido tempo livre. Eu só queria contribuir para a conversa e dizer que gostaria de ver esse avanço; mas na verdade não espero que a equipe principal trabalhe nisso. Eu acho que o formato NS XML poderia ser feito como projetos comunitários onde aqueles de nós que se importam (ou seja, provavelmente eu :grinning:) estariam dispostos a fazer o trabalho neles. No entanto, minha maior preocupação @sethladd -- é se eu gastar muito tempo em um patch; será rejeitado porque alguém da equipe principal se opõe absolutamente a essa habilidade. Isso é o que eu gostaria de esclarecer primeiro antes de gastar algum tempo com isso ...

@NathanaelA Perspectiva fantástica !!!!!! e olha eu usei muitos pontos de exclamação ;-) Você literalmente acertou em cheio na cabeça.

Sim, eu posso fazer DSX, mas preciso de uma maneira de integrá-lo no sistema de compilação atual do Flutter, então preciso do compromisso da equipe atual do Flutter antes de seguir em frente. A integração IDE é praticamente trivial no VS Code, mas não tanto com o Intellij (a menos que o Google tenha acesso ao suporte ao Intellij JSX).

@zoech , Não! Eu acho que isso é um problema. Lembro-me de desenvolver um aplicativo Android com Java e XML nativos. Ainda usamos XML para a parte da linguagem da interface do usuário. Acho que usar o Dart para lógica e interface do usuário é meio estranho, e esse problema é meio óbvio. além disso, espero que o Google adicione a ideia de interface do usuário do React na vibração. A parte da interface do usuário do React é muito poderosa e concisa.

@JonathanSum Eu vi muitos comentários sobre isso.
Para mim, ainda parece algo que as pessoas querem porque estão relutantes em mudar seus hábitos, não porque é um benefício para a plataforma.

Algumas pessoas gostam de jsx, outras não. Por que não suporta as duas maneiras de implementar a interface do usuário. Você pode escrever uma sintaxe do tipo jsx, e ela finalmente será compatível com a sintaxe nativa de vibração, por que não suportar?

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

@zoechi

Para mim ainda parece algo que as pessoas querem porque estão relutantes em mudar seus hábitos

Esta é uma observação justa, mas não seria melhor para o Flutter ser um facilitador e remover o máximo de atrito possível para as pessoas (fora do Google) adotarem o Flutter? Esse comportamento de guardião não está conquistando corações e mentes dos desenvolvedores.

@yuu2lee4

Algumas pessoas gostam de jsx, outras não. Por que não suporta as duas maneiras de implementar a interface do usuário. Você pode escrever uma sintaxe do tipo jsx, e ela finalmente será compatível com a sintaxe nativa de vibração, por que não suportar?

Excelente pergunta. Dado que estou fazendo todo o trabalho no DSX, que é exatamente como o JSX, e @Hixie pessoalmente me enviou um e-mail animado com o progresso, não vejo por que não apoiá-lo, não vejo por que não estender a mão e dizer 'O que eu posso fazer para te ajudar? O que está bloqueando você para fazer isso?'

Sinceramente, estou começando a pensar que este está indo na mesma direção que o anterior... o que não ajudaria...

@cbazza

@Hixie pessoalmente me enviou um e-mail animado com o progresso.

Então, por que você não continua e os outros que podem ajudar também devem embarcar e ajudar? Se não queremos que isso apareça como o outro tópico... acho que deveríamos discutir quais são os bloqueios, como vamos fazer isso e como podemos fazê-lo funcionar e colocá-lo lá fora... e Eu também acho que a equipe de flutter e dart de alguma forma começou algum trabalho na redução da natureza detalhada da escrita da interface do usuário ...
Talvez a equipe não consiga se juntar agora, mas acredito que se for uma causa digna, que acredito que seja, para mim, tudo bem, seja qual for a abordagem... eles vão se atualizar em algum momento... então @cbazza vamos continuar com o que você está fazendo e divulgue... como o que esse cara fez http://mutisya.com/ nos primeiros dias, embora eu não saiba de seu estado... também sei que @NathanaelA pode ajudar porque ele contribuiu com algumas coisas e ferramentas realmente incríveis para Nativescript... Vamos lançá-lo para dar mais opções a mais desenvolvedores...

@MichaelSowah
A razão para não investir mais tempo nisso é como @NathanaelA disse:

No entanto, minha maior preocupação @sethladd -- é se eu gastar muito tempo em um patch; será rejeitado porque alguém da equipe principal se opõe absolutamente a essa habilidade. Isso é o que eu gostaria de esclarecer primeiro antes de gastar algum tempo com isso ...

Bom, aqui está o que eu tenho:
(a) Um pré-processador que recebe arquivos *.dsx e gera arquivos *.dart como saída.

Aqui está o que eu preciso:
(1) Alguém para cuidar da integração do 'VS Code'. Da minha investigação parece simples.
(2) Alguém para descobrir como adicionar capacidade de pré-processador ao sistema de compilação Flutter para que a depuração funcione corretamente. Quero dizer, a revisão de código estaria nos arquivos *.dsx por meio de algo como mapa de origem, etc.

Uma vez que os 2 itens acima são feitos, temos um sistema inicial de ponta a ponta para fazer a bola rolar. Algum comprador?

Então, como você pode ver acima, (1) e (2) exigem alterações no código Flutter que a equipe Flutter pode rejeitar, portanto, sem suporte/compromisso, esse recurso está travado.

@cbazza ótimo, então vamos chamar um dos membros da equipe flutter aqui para nos informar se eles estão dispostos a aceitar um e dois ... então quem podemos chamar aqui para nos ajudar a progredir ...?

Para (2) acho que a melhor aposta é entrar em contato com a equipe do Dart, provavelmente via [email protected] ou seu rastreador de problemas? Acredito que um dos objetivos do Dart 2 era criar uma infraestrutura para mais experimentação com a linguagem e deixar a comunidade criar experimentos como o DSX. Talvez @anders-sandholm @mit-mit ou @mraleph possam apontar na direção certa.

@sethladd Obrigado pela resposta rápida e você também poderia copiar as pessoas de recurso e possivelmente
equipe de dardos para este tópico também
@cbazza você poderia entrar para fazer esse discurso com a pessoa do recurso listada.
com relação à integração do 'VS Code', tenho certeza de que, quando tirarmos 2 do caminho, talvez @DanTup possa estar interessado em ajudar

Apenas alguns pensamentos

Bom, aqui está o que eu tenho:
(a) Um pré-processador que recebe arquivos *.dsx e gera arquivos *.dart como saída.

Isso é provavelmente tudo o que você precisa para começar, isso e um observador de arquivos para reconstruir as alterações - consulte FileSystemEntity . O desafio é que essa gramática .dx é um superconjunto de dartlang, então você teria que analisar todo o Dart também. Isso será complicado porque, ao contrário do JavaScript, < e > são usados ​​em mais lugares. Acho que o analisador do Dart já está escrito no Dart e em algum lugar dentro do repositório do SDK, mas não sei onde

1. Para integração vscode e Intellij, não é o sistema de compilação flutter, é o analisador de dardos que você deseja. Acho que você pode criar um plugin para isso que consumiria o dx, transpile-o para dart e mapeie os resultados de volta para o arquivo original. É assim que o plug-in do analisador angular funciona para fornecer coisas como autocompletar para arquivos html.

2. Você quer construir runner , este é um pacote muito mais sofisticado para fazer a .

@MichaelSowah
Excelente, então acho que você está assumindo (1) e (2) para que eu possa me concentrar no transpilador?

@jonahwilliams
Eu sei, a análise completa de dardos será complicada e não será realmente necessária no momento, porque sempre posso usar meus marcadores para o primeiro lançamento (https://spark-heroku-dsx.herokuapp.com/index.html)

Mas uma coisa é certa, precisamos que o IDE e o depurador funcionem corretamente, caso contrário as pessoas não usarão o DSX porque a troca é demais. Quero dizer 'usar DSX e esquecer a depuração simbólica', não uma oferta muito atraente. Essa também é a razão pela qual eu quero pelo menos um IDE suportado e o VS Code seria tão simples quanto torta (já que ele já suporta JSX em seus arquivos json de definição de sintaxes Typescript e Javascript)

re: IDE e depurador, presumivelmente implementando esse recurso dentro da infraestrutura do Dart 2 e "front-end comum", você deve permitir que os níveis mais altos da pilha estejam cientes do DSX. Recomendo trabalhar com a equipe do Dart e aprender a explorar as várias partes do Common Front End e suas APIs.

@MichaelSowah Eu fiz CC com o pessoal do Dart em https://github.com/flutter/flutter/issues/15922#issuecomment -376960770

@NathanaelA você estaria interessado em participar do (1) e (2) já que agora temos claramente o apoio da equipe

Não tenho certeza; neste momento -- estou sobrecarregado com vários projetos de clientes. Mas eu estaria disposto a ver como se conectar ao pipeline de compilação e potencialmente criar mapas de origem. (ou seja, 2) Mas pode levar algumas semanas até que eu possa fazê-lo.

@NathanaelA Não há pressa nem nada, então você está bem :-)

Se DSX é simplesmente Dart + Virtual closing tag , então não há benefício real. Um benefício do dart é que podemos usar funções e variáveis ​​para criar parte do widget e aumentar a legibilidade.

Também com DSX e pré-processador, perderemos a capacidade de recarga a quente de sub-segundo, certo @cbazza ?

Não, o DSX é como o JSX e completamente diferente do 'Dart + Tag de fechamento virtual', que é o que você pode fazer hoje com sua árvore de widgets e IDE apenas para Dart.

DSX é descrito aqui:
https://spark-heroku-dsx.herokuapp.com/index.html

DSX é Dart, então todos os benefícios do Dart como você descreve estão lá. Pessoas familiarizadas com JSX vão entender imediatamente e adorar.

Não, você não vai perder nada, nada muda para o arquivo *.dart normal que você cria, você ainda tem recarga quente de sub-segundo.
Agora, se você tiver um arquivo *.dsx, ele será primeiro transpilado para *.dart e esse processo é mais rápido do que posso piscar!!! Portanto, será imperceptível para os usuários do DSX.

Antes que este seja fechado novamente, deixe-me terminar o que quero dizer primeiro.
A interface atual da parte flutter é um problema, e não estou tentando vender a ideia do React.
Como a estrutura da interface do usuário do flutter é muito difícil de perceber na mente com esses parênteses, realmente precisamos de algo para melhorar. Eu sugiro usar react native ou a coisa toda como React. O React não apenas facilita a leitura das pessoas, mas também separa um enorme código de interface do usuário em diferentes grupos. Como resultado, posso gerenciar um código de interface do usuário enorme e complexo mais rapidamente e lê-lo facilmente. Por outro lado, com muitas árvores com parênteses só na esvoaça, não sei lê-los.

@JonathanSum você tentou a última versão do Android Studio (3.1) com rótulos de fechamento?

@14n Sim, vejo essas tags e comentários de fechamento virtuais.

Uma grande árvore de widget do tipo XML pode ser tão difícil de ler quanto qualquer outra coisa grande , seja Dart, JSON, YAML ou JSX. Não parece que o próprio JSX resolve o problema de legibilidade.

Não tive nenhum problema ao ler árvores de widgets de tamanho normal com a sintaxe atual. Além disso, o Flutter promove a composição, então, uma vez que determinado widget fica muito grande, é trivial dividi-lo em vários widgets menores.

Opinião subjetiva sobre o formato DSX proposto:

1. Visualmente nenhum benefício real e novamente - ler uma grande árvore XML pode ser tão doloroso, então não parece resolver o problema. A promoção de práticas de Código Limpo, por exemplo, realmente abordaria questões de legibilidade, mas essas práticas podem ser aplicadas a (quase) qualquer sintaxe.
2. Requer aprender outra DSL/sintaxe. Eu realmente gosto que eu só preciso saber uma sintaxe - Dart - para fazer tudo - layout, estilos, animações, lógica. É muito mais amigável tanto para iniciantes quanto para desenvolvedores experientes em comparação com o que aconteceu com a Web com html/js/jsx/ts/coffee/css/sass/scss. Na verdade, até considero isso um grande benefício do Flutter em relação a outras plataformas.

Dito isso, acredito que há espaço para melhorias para o Dart ser mais expressivo quando usado para descrever UIs, embora eu prefira que seja mais uma extensão da sintaxe do Dart existente em vez de uma DSL completamente nova.

Por favor, pare de tentar fazer o Flutter ser como a "coisa nova e quente". É a novidade quente por si só, deixe-a explorar novos paradigmas.

@naiveaiguy eu acho quente. Isso me torna muito produtivo e me permite compartilhar código com aplicativos de navegador e servidor.
Eu não preciso de algum hype para um verão. Preciso de algo que me permita fazer meu trabalho.
É exatamente isso que Flutter e Dart fazem.

Meus pensamentos sobre isso refletem o que @pulyaevskiy disse em https://github.com/flutter/flutter/issues/15922#issuecomment -377666972. Todos os exemplos que vi que não são tão legíveis geralmente podem ser arrumados no código existente e acho que pode haver mais pequenas alterações que podem ser feitas no Dart (semelhante à remoção de new/const) que podem melhorá-lo ainda mais . Manter todo um outro conjunto de arquivos com uma sintaxe totalmente diferente e um conjunto totalmente novo de código de ferramentas parece um custo alto para o que acredito ganho relativamente pequeno (FWIW, também prefiro React sem JSX).

Não sei se é totalmente aplicável aqui, pois o dsx proposto também permite código Dart normal, mas toda vez que ouço alguém falar sobre uma nova sintaxe, lembro-me deste ótimo post de Gilad A DOMain of Shadows . Essas coisas são sempre mais complicadas do que as pessoas pensam. Não é tão simples como transpilar o código porque as pessoas esperariam erros em tempo real, conclusão de código, refatorações, dicas de ferramentas, etc. - é um grande empreendimento.

Em vez de um transpilador de trabalho, eu estaria mais interessado em ver uma comparação de três vias entre algum código considerado difícil de ler, como ele ficaria nessa sintaxe proposta e como ficaria se você pudesse fazer alterações a sintaxe do Dart existente sem substituir todos os colchetes. Por exemplo, algo que eu gosto no React é que as crianças são passadas como varargs como o último parâmetro - eu acho que child e children adicionam muito ruído no Flutter - talvez haja espaço para melhorias lá . Há também algumas discussões sobre se alterar a formatação ou destacar nomes de classes de widgets pode ajudar. Parece que um refatorador Extract Widget está a caminho de quebrar facilmente métodos de compilação grandes. E, claro, o IntelliJ tem a visualização Flutter Outline, que permite ver o código em uma árvore e a seleção mantém a sincronia com a posição do cursor no editor (e estou realmente esperando obter algo semelhante no VS Code, embora esteja bloqueado por alguns recursos do VS Code como este, então fique à vontade para 👍!).

@pulyaevskiy
Eu entendo o que você está dizendo, mas a experimentação é boa, é o caminho para a evolução. Mesmo que minha experimentação com o DSX falhe, espero que outros experimentem muitas outras coisas e reúnam as melhores ideias para criar uma tecnologia incrível.

@sethladd
Obrigado pelas pistas.
Adoraria ouvir de @anders-sandholm @mit-mit ou @mraleph em
como trabalhar com a infraestrutura do Dart 2 e 'front end comum'.
Vou analisar isso com @NathanaelA.

@DanTup

Essas coisas são sempre mais complicadas do que as pessoas pensam. Não é tão simples como transpilar o código porque as pessoas esperariam erros em tempo real, conclusão de código, refatorações, dicas de ferramentas, etc. - é um grande empreendimento.

Sim você está correto. Meu comentário 'trivial, simples de implementar' só se aplicava a fazer com que o editor reconhecesse a sintaxe .dsx. Eu examinei o Intellij e eles exigem um analisador de linguagem completo para isso (então isso é complexo), enquanto o VS Code era muito mais fácil com os arquivos de sintaxe e também notei que os arquivos de sintaxe Typescript/Javascript já tinham suporte para JSX (e o DSX só tem pequenas alterações do JSX).

Nós certamente estaremos incomodando você por ajuda/direção para começar nossa experimentação.

Em resumo, tenho:
(a) Um pré-processador que recebe arquivos *.dsx e gera arquivos *.dart como saída.
https://spark-heroku-dsx.herokuapp.com/index.html

Preciso de ajuda com:
(1) Alguém para cuidar da integração do 'VS Code'.
(2) Alguém para descobrir como adicionar capacidade de pré-processador ao sistema de compilação Flutter para que a depuração funcione corretamente. Quero dizer, a revisão de código estaria nos arquivos *.dsx por meio de algo como mapa de origem, etc.

@NathanaelA ajudará com (2).

Então, ainda estou procurando pessoas para ajudar (1)
Algum comprador? @birkir @yuriy-manifold @tehfailsafe @alexkrolick @sanketsahusoft

@DanTup - Não sou profissional em JSX, mas posso falar sobre o formato XML NativeScript. Eu posso fazer:

Qualquer propriedade suportada pela classe StackLayout pode ser adicionada ao XML. Portanto, é uma relação de um para um; que elimina uma tonelada de lixo extra: Então, vamos dar uma olhada na demonstração do Flutter:
https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/gallery/home.dart#L39 -L63

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

Acho isso mais fácil de ler e entender se eu converti corretamente. :sorrindo:

@NathanaelA O que acontece se você precisar fazer algo mais dinâmico, como chamar map ? Aqui está algum código desse mesmo arquivo:

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

Como seria children: _kBackgroundLayers.map(...) nesta sintaxe?

JSX/DSX especifica apenas a transformação da tag como:

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

Dentro:

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

Fora:

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

e você pode usar {} para colocar qualquer código Dart válido, como avaliação de variáveis ​​e funções anônimas, etc. O {} pode ser colocado em 3 lugares. O exemplo abaixo mostra {} usado em 2 lugares (atributos de tag e como filhos), sendo o 3º com o operador spread.

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

Coloque o código acima em um arquivo Javascript e visualize-o com VS Code/Intellij. Observe o +/- (lado esquerdo da linha) que você pode usar para abrir e recolher nós XML para tornar a árvore menor/maior.

Por que não podemos simplesmente admitir o problema e adotar o modo React Native? Vamos fazê-lo ou não?

@JonathanSum desculpe ao ser direcionado aqui, mas quem você pensa que é? Não há problema geral apenas algo que você não gosta.
Você já escreveu um único aplicativo com Flutter?
Os exemplos acima misturando Dart com XML parecem muito piores do que apenas Dart. Nada a ganhar aqui.
Eu vim do Xamarin Forms que usa xaml e gostei muito. Mas em vez de reclamar por que o Flutter não suporta Xaml, eu mergulhei nele e comecei a me adaptar e aprender.
Encare se você quer trabalhar como no React, então use Reactive em vez de irritar todos aqui.

Aqui está o mesmo bloco de código acima, mas em Dart puro e refatorado para evitar aninhamento profundo.
Curioso sobre quais partes do snippet abaixo são difíceis de ler e/ou entender?

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

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

Na verdade, pessoalmente, eu faria parecer mais próximo de algo assim:

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

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

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

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

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

Novamente, parece que estamos misturando dois problemas diferentes aqui:

1. Não gosta da sintaxe do Dart e precisa de sintaxe semelhante a XML/JSX
2. Legibilidade do código Flutter.

Existem pessoas aqui que acreditam que a implementação do JSX resolverá a legibilidade? Ainda seria possível criar árvores profundamente aninhadas no código e os desenvolvedores ainda precisariam passar pelas mesmas etapas que acabei de executar com a versão Dart para tornar as coisas legíveis.

Mas o que definitivamente adicionaria é uma etapa extra de compilação/transpilação com mapas de origem & co, e muito trabalho para oferecer suporte a essa infraestrutura em IDEs e SDK do Dart (analisador, depurador, etc).

@JonathanSum @escamoteur Não falamos agressivamente sobre este projeto. Por favor, permaneça colaborativamente colegial. Obrigado. A discussão recente foi amigável e produtiva, então obrigado a todos que participaram dessa discussão!

No geral, parece-me que adicionar DSX fragmentaria o ecossistema Flutter em seus estágios iniciais, com muito trabalho sendo feito para tentar manter ambas as sintaxes completas, não ajudar significativamente a legibilidade na maioria dos casos e atrair o tipo de desenvolvedores que são atraídos por projetos puramente por terem uma sintaxe e/ou paradigma semelhante a uma novidade quente.

@Hixie desculpe por ter perdido a paciência, mas acho que o Flutter está em um bom caminho e os desenvolvedores do Flutter têm o suficiente para fazer sem demandas como essa

@escmoteur - Acho que é por isso que disse especificamente o esforço da "comunidade". Eu não acho que isso precise envolver a equipe principal do flutter além de eles estarem dispostos a aceitar patches... O que Seth parece ter dito que podemos prosseguir. Se você não estiver interessado neste recurso; então não use... :grinning:

@escamoteur , desculpe pelo jeito que eu disse.
Eu construí alguns aplicativos de vibração de tutoriais. Tudo o que sinto sobre o flutter é que tudo é um objeto e não um widget. É como um enorme pedaço de códigos de programação orientados a objetos complicados colados desordenadamente.

Acho que o mais importante é fazer um framework que seja fácil de ler e gerenciar, e não deve ser complicado pra caramba. Mais importante, acho que a maneira como o React-Native constrói segue o que os humanos constroem coisas naturalmente. Por outro lado, o flutter precisa conectar o widget stateful ao stateless e... Além disso, a maioria dos frameworks de interface do usuário que usamos nesses anos se concentram nesse modo React como padrão, e acho que o flutter deve se concentrar mais nisso em vez do hot reload (quando tento adicionar novas algumas novas classes, o console me diz para reiniciar tudo em vez de fazer o hot reload). Eu realmente acho que isso é um problema, não um comentário ou demanda.
naiveaiguy disse:

Por favor, pare de tentar fazer o Flutter ser como a "coisa nova e quente". É a novidade quente por si só, deixe-a explorar novos paradigmas.

Você pode ir vê-los.
https://facebook.github.io/react-native/
Pensando em Reagir:
https://reactjs.org/docs/design-principles.html
Flutuação:
https://flutter.io/tutorials/animation/

Olhe para o React-Native, ele ainda coloca o gerenciamento de estado acima e as partes da interface do usuário abaixo. É uma arte e um comportamento natural do ser humano. É por isso que a curva de aprendizado e o tempo de gestão são baixos. Assim, por favor, não compare XML ou mesmo Xamarin com o React Native. Além disso, o futter é apenas como um caos e desordem. O stateless conecta-se ao stateful, e o create-state conecta tudo no stateless. Com React-Native, você está desenhando uma bela imagem com um lápis. Com uma vibração, é como jogar uma água em um papel e separar a água em diferentes partes. Mas acho que ainda estamos nos primeiros dias de vibração. O React-Native tem sua própria filosofia e objetivos, e o flutter é apenas um projeto sério, ou todos discordam de mim.

@JonathanSum

Eu construí alguns aplicativos de vibração de tutoriais. Tudo o que sinto sobre o flutter é que tudo é um objeto e não um widget. É como um enorme pedaço de códigos de programação orientados a objetos complicados colados desordenadamente.

Você falhou em fornecer uma razão pela qual seu sentimento subjetivo neste assunto justificaria a enorme quantidade de fragmentação que inevitavelmente causaria. Quando entre essas duas abordagens, nenhuma é claramente melhor objetivamente que a outra, não acho que valha a pena, e definitivamente não no estágio em que o Flutter está agora como um ecossistema.

Acho que o mais importante é fazer um framework que seja fácil de ler e gerenciar, e não deve ser complicado pra caramba.

Isso é uma tautologia. Obviamente, todo mundo quer isso, mas as pessoas têm maneiras diferentes de abordar o problema. O paradigma de Flutter é um deles.

Mais importante, acho que a maneira como o React-Native constrói segue o que os humanos constroem coisas naturalmente.

Eu não acho que algo tão pequeno quanto a sintaxe para construir a interface do usuário influencie a facilidade de uso de uma estrutura geral.

Por outro lado, o flutter precisa conectar o widget com estado ao sem estado e...

Parece que você discorda fundamentalmente de como o Flutter aborda os aplicativos. Por que você está usando? Além disso, este não é realmente um ponto válido. Você não está expressando algo que sente que está errado, está apenas dizendo "Acho que as conexões entre widgets sem estado e com estado estão erradas e complicadas de uma maneira vaga que não vou explicar".

Além disso, a maioria dos frameworks de UI que usamos nestes anos focam nesta forma React como um padrão,

Argumentum ad populum.

e acho que o flutter deve se concentrar mais nisso do que no hot reload (quando tento adicionar novas algumas novas classes, o console me diz para reiniciar tudo em vez de fazer hot reload)

Sim, porque o recarregamento a quente não é um recurso muito fácil de alcançar da maneira que o Flutter o fez. Eu diria que o ciclo de desenvolvimento que o Flutter conseguiu alcançar, mesmo em 30-40% das mudanças de código, é realmente impressionante e só seria retardado por camadas de transpiling.

No entanto, o futter é apenas como caos e desordem.

Aqui você deixou claro que simplesmente não gosta da abordagem do Flutter. Não use então. E se você acha que de alguma forma, magicamente, alterar a sintaxe da interface do usuário fará com que o Flutter não seja "caos e desordem", então você precisará fornecer evidências claras de que isso funciona nos mesmos tipos de configurações e restrições com as quais o Flutter está trabalhando.

É por isso que a curva de aprendizado e o tempo de gerenciamento são baixos. Por favor, não compare XML ou mesmo Xamarin com o React Native.

Bastante justo - use React Native então. Os desenvolvedores de lá estão fazendo um ótimo trabalho com seu paradigma.

O stateless se conecta ao stateful e create-state no stateless

Que? Não. Isso é simplesmente errado - qual é o seu ponto aqui?

Com React-Native, você está desenhando uma imagem com um lápis. Com uma vibração, é como uma água caindo em um papel e separando a água em diferentes partes.

Francamente, essa analogia faz muito pouco sentido para mim. Eu poderia facilmente declarar a opinião inversa e estaríamos de volta onde começamos aqui.

Você está agindo como se isso fosse evidentemente óbvio ("vamos encarar") e estamos apenas sendo pretensiosos e/ou insuportáveis ​​aqui por dizer que a equipe do Flutter não deveria ter que lidar com isso. Essa não é uma boa atitude a ser adotada se você quer que outras pessoas o levem a sério.

Ponto adicional: Por favor, não finja que isso é algo que desenvolvedores de terceiros podem fazer sem nenhum envolvimento ou trabalho por parte da equipe principal do Flutter. A equipe do Flutter terá que fazer muito trabalho adicional com IDEs e plugins de editor, e evangelismo, e lidar com problemas do GitHub, se esse recurso for implementado satisfatoriamente como uma parte harmoniosa do Flutter.

@naiveaiguy
Tudo bem, acho que você está certo. Eu sou apenas uma pessoa aleatória comparando todos aqui e uma pessoa que gosta de React. O Flutter tem seu próprio jeito, e o React também. Sinto muito pela minha atitude, e eu não fui legal.

@JonathanSum Acho que você só precisa de mais tempo para realmente entender como os aplicativos Flutter são criados. Para ser justo, não há muitos documentos sobre arquitetura, como usar widgets herdados corretamente e como conectar seu modelo de visualização aos widgets.

O que eu gostaria de saber é por que você está interessado em Flutter? Para mim, o React não funciona por causa do JS

Tanto para comentar, tão pouco tempo, talvez eu devesse me concentrar...

@escamoteur o que exatamente você quer dizer com:

Para mim, o React não funciona por causa do JS

ES6/7 ou Typescript estão tão perto de Dart/Kotlin/Swift que eu danço alegremente com qualquer uma dessas mulheres :)

O que me atrai no Flutter é o suporte a gráficos e animações. Gráficos Skia Vector diretos construídos em cima do OpenGL para UX super rápido a 60 fps para implementar facilmente coisas como o que você vê em:
https://uimovement.com/
Eu gosto de UX personalizado e o Flutter permite isso. Eu implementei coisas de UX por décadas e eu realmente gosto de poder construir isso usando técnicas declarativas/reativas, e o Flutter suporta isso.

@pulyaevskiy

Novamente, parece que estamos misturando dois problemas diferentes aqui:

• Não gosta da sintaxe do Dart e precisa de sintaxe semelhante a XML/JSX
• Legibilidade do código Flutter.

Correto, este ticket aqui (e o anterior) só quer recursos do tipo JSX. Existem outros tíquetes para melhorias da linguagem Dart para diminuir a verbosidade do código de construção da interface do usuário atual.

Existem pessoas aqui que acreditam que a implementação do JSX resolverá a legibilidade?

Pode ser para eles, para cada um na sua.

Sim, o exemplo que você forneceu torna a árvore menor, mas ao dividi-la em pedaços e movê-los para outro lugar, também torna ainda mais difícil ver toda a estrutura no código. Prefiro manter a estrutura completa em um só lugar e tirar da árvore algumas propriedades relacionadas (parâmetros nomeados) e usar o operador spread do DSX para trazê-las. Apenas minha preferência.

Mas o que definitivamente adicionaria é uma etapa extra de compilação/transpilação com mapas de origem & co, e muito trabalho para oferecer suporte a essa infraestrutura em IDEs e SDK do Dart (analisador, depurador, etc).

Estamos lidando com isso e @sethladd afirmou que I believe one of the goals of Dart 2 was to create an infrastructure for more experimentation with the language and let the community create experiments like DSX.

@naiveaiguy

Eu diria que o ciclo de desenvolvimento que o Flutter conseguiu alcançar, mesmo em 30-40% das mudanças de código, é realmente impressionante e só seria retardado por camadas de transpiling.

Sim, eu realmente gosto de carregamento a quente, mesmo que não funcione o tempo todo. Definitivamente vou aceitar isso, mas seu comentário com transpilar desacelerando é infundado. Se você não usar o DSX, ele não adicionará nada ao seu tempo de compilação. Se você usa DSX, o transpilador é tão rápido que você nem vai notar.

Ponto adicional: Por favor, não finja que isso é algo que desenvolvedores de terceiros podem fazer sem nenhum envolvimento ou trabalho por parte da equipe principal do Flutter. A equipe do Flutter terá que fazer muito trabalho adicional com IDEs e plugins de editor, e evangelismo, e lidar com problemas do GitHub, se esse recurso for implementado satisfatoriamente como uma parte harmoniosa do Flutter.

Na verdade. Estamos fazendo isso e pedindo apenas para não serem bloqueados. Estamos pedindo orientação para nos apontar na direção certa. Não vou fazer tudo isso sozinho, então agora somos 2 (obrigado @NathanaelA) e estamos procurando mais pessoas (pelo menos mais 1) se quiserem ajudar.

Cumprimentos a todos! Em primeiro lugar, gostaria de salientar que não faz muito sentido continuar a discussão sobre esta questão - ela será grande e difícil de acompanhar devido à estrutura linear. Seus argumentos serão perdidos e repetidos uma e outra vez. Vamos reduzir isso a números puros:

• Se você é a favor deste recurso - curta o primeiro comentário sobre este problema.
• Se você é CONTRA esse recurso - curta o primeiro comentário sobre esse problema.

Em seguida, gostaria de esclarecer a declaração de @sethladd , deve ler _"um dos objetivos do Dart 2 era criar uma infraestrutura para mais experimentação com a linguagem para a equipe Dart "_.

Mesmo no Dart 2, não fornecemos nenhuma API que permita alterar facilmente a sintaxe da linguagem Dart, sem reconstruir o SDK do Dart (ou artefatos do mecanismo Flutter). O que o Dart 2 fornece é uma infraestrutura _common front-end_ (CFE) (localizada em pkg/front_end nas fontes do SDK do Dart) - que é um analisador para a linguagem Dart escrita em Dart. Para alterações de linguagem sugar puramente sintáticas, como DSX, você deve poder editar o código CFE, criar o SDK do Dart (ou mecanismo Flutter) e ter todas as ferramentas (exceto o código de realce de sintaxe embutido nos respectivos plug-ins IDE) pegar sua nova extensão de sintaxe. Observe que atualmente apenas VM e dart2js realmente usam CFE, o analisador está programado para a próxima transição. Como você pode ver, há certa barreira para a entrada aqui.

Uma coisa importante a destacar aqui é que, como não há API para estender a sintaxe do Dart, você teria que trabalhar com a equipe de linguagem do Dart para estender a linguagem. Atualmente não existe um processo formalizado para isso, no entanto, para um recurso como o DSX, seria necessário haver muitas evidências e motivação para que ele fosse incluído no Dart. (/fyi @leafpetersen @lrhn - corrija-me se estiver errado)

Aqui estão minhas recomendações para os defensores do DSX como solução:

• Em primeiro lugar, você realmente precisa colocar sua proposta por escrito e mover a discussão para um local que facilite a discussão não linear. Quando você propõe mudanças no idioma, você precisa ter uma descrição _elaborada_ do que você está tentando resolver e como isso é resolvido usando suas extensões de sintaxe propostas. Caso contrário, é impossível avaliar os custos e benefícios da mudança proposta. Então você precisa de uma maneira de ter discussões não lineares sobre diferentes partes da proposta, por exemplo,

  • se você colocar sua proposta no Google Doc, as pessoas poderão usar os comentários integrados para discutir vários componentes de sua proposta;
  • como alternativa, você pode criar um repositório do GitHub com descrição de markdown de sua proposta e usar o problema e PRs do GitHub para refinar e discutir sua proposta.

  Observe que não estou dizendo que você precisa criar uma _especificação formal_ para sua alteração que seja comparável à especificação da linguagem Dart no nível de refinamento. Em vez disso, você precisa ter exemplos extensos de como a mudança proposta funciona e quais benefícios ela oferece.



• Em seguida, se você puder, você deve tentar ter uma implementação. A barreira é alta aqui mesmo com a infraestrutura CFE - mas muito menor do que era antes.

@mraleph Acho que os argumentos sobre integração no Dart eram mais sobre ganchos para invocar geração de código ou similar, não para alterar o idioma.
Não faço ideia de que algo assim seja necessário.
Eu acho que isso poderia ser implementado principalmente como Angular com seu plugin Analyzer, apenas DSX em vez de HTML

@mraleph

Muito obrigado pelo esclarecimento.
Nós realmente não queremos modificar a linguagem Dart, o que precisamos é capacidade de pré-processamento para transformar nosso DSX experimental em Dart.
A propósito, você pode experimentá-lo online em:
https://spark-heroku-dsx.herokuapp.com/index.html

A coisa é que quando o Dart foi lançado pela primeira vez, ele foi capaz de transpilar para Javascript e, usando mapas de origem, foi capaz de se conectar ao ecossistema Javascript (várias outras linguagens fizeram o mesmo: Coffeescript, Typescript, etc). O que estamos procurando é algo semelhante a isso para Dart/Flutter. Estamos procurando por recursos genéricos de pré-processamento que permitiriam que qualquer outra linguagem de transpilação fosse construída em cima do Dart/Flutter.

Com relação à votação, o bilhete anterior tem alguns números:
https://github.com/flutter/flutter/issues/11609

@cbazza

Nós realmente não queremos modificar a linguagem Dart, o que precisamos é capacidade de pré-processamento para transformar nosso DSX experimental em Dart.

Eu estava falando da perspectiva de que os arquivos *.dsx são, na verdade, arquivos Dart nos quais você pode usar alguma sintaxe adicional. E, como eu disse, atualmente não há APIs ou pontos de extensão que facilitem a criação de tais extensões de sintaxe de uma forma que permita que essas extensões de sintaxe interoperem de forma transparente com todas as ferramentas no ecossistema Dart. Além disso, não acho que haja planos imediatos para projetar e fornecer essas APIs ou pontos de extensão - portanto, sua melhor aposta a partir de hoje é bifurcar o SDK do Dart e construir o suporte DSX no CFE.

Eu também recomendo pensar em casos de canto - em vez de pensar em casos simples. Por exemplo, imagine que você está editando seu arquivo DSX. Nesse caso, você provavelmente deseja ver a conclusão em tempo real no código semi-acabado, por exemplo, nomes de construtores e nomes de atributos. Como isso funcionaria com o mapeamento de origem? Coisas assim constituem a experiência do desenvolvedor.

@mraleph Obrigado mais uma vez.

Com certeza, nosso objetivo é fornecer uma ótima experiência de usuário para usuários de DSX, com certeza.

Algumas pessoas gostam de sintaxe semelhante a XML, algumas pessoas odeiam isso. Talvez adicionar sintaxe semelhante a jsx seja muito exagerado. Minha principal preocupação com o Flutter é a legibilidade. IMHO, ainda há espaço para melhorar a sintaxe atual do Dart e Flutter (para mim é principalmente sobre parênteses de aninhamento profundo, child , children , ruídos de ponto e vírgula, etc.)
Repostando algum código de exemplo[1]aqui,

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

Versão do Dart 2 com new e ponto e vírgula opcional (código de @sethladd)[2],

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

IMO, a versão kotlin é limpa e parece melhor. A versão Dart 2 está muito próxima e ainda tem espaço para melhorias (se Dart suportar métodos de extensão?). Então, acho que melhorar a sintaxe do Dart para reduzir a verbosidade é a direção certa.

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

Outro ângulo, gosto da habilidade de composição do JSX.

Trabalhar com os componentes (widgets) é muito fácil e acessível, movê-los para cima e para baixo na árvore em um editor é apenas uma questão de atalho de teclado (Alt+UP / Alt+DOWN). Isso é especialmente verdadeiro para quando mover coisas para dentro e para fora do contêiner, linha, coluna etc.

Mas isso não é algo que o DSX resolveria sozinho. Os widgets que eles mesmos precisariam ser
mais restrito com nomenclatura de propriedades para que isso funcione. Em React, esta é uma propriedade chamada children e é um principal principal em JSX. Flutter permite flexibilidade na nomeação de crianças (crianças, crianças, corpo, etc.).

Aqui está uma ótima discussão de prós e contras: https://github.com/jsforum/jsforum/issues/1

Dardo	DSX

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

Eu tenho que admitir que a amostra DSX parece atraente. Mas temo que assim que você misturá-lo com o código Dart, por exemplo, ao usar qualquer widget do construtor, ele ficará muito feio.

O @birkir DSX deve ser capaz de suportar algo como o padrão de props de renderização para slots filhos múltiplos/não children . Se ele puder receber funções ou referências de classe como props (o que provavelmente faria automaticamente), funcionaria imediatamente.

No que diz respeito à implementação de ferramentas, as ferramentas Javascript suportam sintaxe não padrão e extensão de linguagem por um longo tempo (Flowtype/Typescript/Babel), portanto, muitas das ferramentas para JSX aproveitaram os transpilers existentes. Afaik Dart não experimentou esse nível de fragmentação, então as ferramentas ainda não existem. Mas agora é um bom momento para começar a construí-lo 😄

IMHO, sintaxe semelhante a json é muito melhor do que a sintaxe ~xml-like~!

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

@jaychang0917
Eu não acho que o JSX pode ser comparado ao XML. Eu acho que JSX e XML são duas coisas diferentes como aeronaves supersônicas verso hélice.

Com JSX, você pode fazer coisas como:

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

ou

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

Com JSX, podemos até mesmo quebrar tudo peça por peça, como acima, ou você pode agrupar uma grande parte da interface do usuário em uma tag <> para colocar essa grande parte da interface do usuário em qualquer lugar que desejar.

É por isso que o React substitui o HTML e o XML e adota o JSX para construir um aplicativo para iPhone ou um aplicativo da web, ou as pessoas dizem que o JSX é apenas uma versão mais legal do HTML.

• Eu não gosto de XML e HTML e adoro JSX.

• Acho que o mais importante não é o desempenho como iPhone vs desktop.

• A coisa mais importante é fácil de usar como iPhone vs desktop.

Por exemplo:

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

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

Ou escreva

< AwkwardScrollingImage/>

escrever-uma vez-executa-em todos os lugares

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

~Flutter está usando uma linguagem de programação para construir uma interface do usuário. ~

Referência:

Flutuação:
https://flutter.io/tutorials/layout/
React Native que constrói android, Iphone e até desktop:
https://facebook.github.io/react-native/

@birkir
Ohh que parece tão booooom!!! apenas carne e sem ossos :)
Imagine usar https://builderx.io/ com ele (dê uma olhada na segunda imagem animada - 2 way UI building como o Flex usa para fazer :)

@escamoteur
com construtores inline, pareceria tão confuso quanto com a forma atual; amostras foram fornecidas acima:
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

enfim, acho que a forma atual é clara e consistente. Misturar algum código de dardo e tag < em um arquivo de dardo me faz sentir que o código é estranho e pouco claro. Do ponto de vista de um desenvolvedor Android, parece escrever código java/kotlin em um arquivo xml de layout :)

APENAS MEUS DOIS CENTAVOS

@JonathanSum hum...

Então, quais vantagens de usar o JSX dessa maneira atual de vibração não podem fazer? Não vejo nenhum argumento que você disse ser forte.

JSX não é como XML. JSX é mais simples e poderoso que esse XML.

Btw, JSX é semelhante a xml , se a equipe do facebook não mentir para mim :)

@jaychang0917
JSX não é XML porque JSX é mais simples e mais poderoso que esse XML. (Eu digo que JSX não é como XML)

Se você diz que não há argumentos fortes, deixe-me fazer uma pergunta.
Deixe-me terminar minha conversa aqui. Se as pessoas quiserem JSX ou DSX, haverá um semelhante no futuro.

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

Eu sinto falta das tags de fechamento reais do XML embora :)
Ideia: tags de fechamento geradas automaticamente

Kotlin teria resolvido isso também. Veja como o Kotlin-react e o Anko são incríveis

Kotlin-react não é tão incrível, KSX teria sido melhor :)

import React from 'react';

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

package hello

import react.*
import react.dom.*

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

package hello

import react.*
import react.dom.*

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

As tags simplesmente não pertencem lá :)

Estando no campo JSX/DSX/KSX, certamente acredito que as tags pertencem ao código :)

@saied89
Você quer usar uma tag para aninhar um elemento dentro de outro elemento como HTML? Ou você deseja digitar uma palavra "crianças", "criança" ou [ ]? Além disso, o JSX fornece coisas como reutilizar centenas de código de interface do usuário digitando apenas uma tag.

Talvez um outro aspecto seja a formatação padrão que dart format faz. IMHO é difícil de ler, especialmente com o filho principal: /children.

Eu realmente preferiria alguma formatação que enfatize a estrutura da árvore algo assim:

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

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

Esta pode não ser a solução ideal, mas deve mostrar a direção.
@sethladd alguma chance de fazer algo nesse sentido?

Em primeiro lugar, estou feliz que isso não esteja ficando tão aquecido quanto sua edição irmã foi: smile:.

Se me pedissem para escolher qualquer uma das 2 sintaxes, eu me inclinaria para o lado do Dart. Isso se baseia em vários fatos:

• Prefiro alternar entre o menor número possível de contextos. Goste ou não, pular entre sintaxes é uma maneira de fazer isso. Isso pode ser ajudado com o suporte de ferramentas, mas isso leva ao ponto abaixo.
• Prefiro que a equipe de desenvolvimento dedique tempo a outros problemas que nos impedem de codificar determinados recursos e/ou impedem que as pessoas entrem no Flutter. Eu acho que não ter uma sintaxe do tipo JSX não deve ser a razão pela qual uma empresa/desenvolvedor/qualquer coisa dispensa o Flutter.
• Nós nos beneficiaríamos de cada atualização do Dart. Isso é especialmente verdadeiro para o Dart, já que o Flutter é um de seus principais clientes e é uma estrutura de interface do usuário. Veja as alterações de new/const , por exemplo.
• Eu valorizo ​​muito a segurança do tipo. Não estou dizendo que uma sintaxe do tipo JSX não possa ser segura para tipos, não acredito que o esforço em realizá-la valha sua receita.

Além disso, eu realmente sou a favor de uma sintaxe semelhante ao Kotlin. Especialmente se essa sintaxe traz alguns recursos Kotlin para Dart : inocente:.

@emalamela ,

Aqui está a coisa, não há troca de contexto como você chama, basta perguntar a qualquer desenvolvedor React experiente. Além disso, essa separação de sintaxe é realmente um ótimo recurso, porque quando você observa o código, pode ver facilmente o que é declarativo e o que é imperativo.

Eu acho que não ter uma sintaxe do tipo JSX não deve ser a razão pela qual uma empresa/desenvolvedor/qualquer coisa dispensa o Flutter.

Mas infelizmente será para muitos desenvolvedores do React.

Nós nos beneficiaríamos de cada atualização do Dart.

Não vejo como o DSX também não se beneficie das atualizações do Dart, pois é um superconjunto do Dart.

Eu valorizo ​​muito a segurança do tipo. Não estou dizendo que uma sintaxe do tipo JSX não possa ser segura para tipos, não acredito que o esforço em realizá-la valha sua receita.

O esforço para alcançar a segurança de tipo no DSX é zero porque o DSX é apenas uma pequena camada de açúcar sintático em cima do Dart, então ele usa o sistema de tipo Dart assim como usa instruções de controle Dart, etc.
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

Obrigado por sua contribuição @cbazza !

Aqui está a coisa, não há troca de contexto como você chama, basta perguntar a qualquer desenvolvedor React experiente.

Eu não sou um desenvolvedor React experiente, então para mim é uma mudança de contexto. Assim como no Android, você precisa pular de Java/Kotlin para XML, embora o salto seja maior lá. Uma linguagem, as mesmas ferramentas, menos sobrecarga.

Além disso, essa separação de sintaxe é realmente um ótimo recurso, porque quando você observa o código, pode ver facilmente o que é declarativo e o que é imperativo.

A forma como está agora é bastante declarativa na minha opinião.

Não vejo como o DSX também não se beneficie das atualizações do Dart, pois é um superconjunto do Dart.
O esforço para alcançar a segurança de tipo no DSX é zero porque o DSX é apenas uma pequena camada de açúcar sintático em cima do Dart, então ele usa o sistema de tipo Dart assim como usa instruções de controle Dart, etc.

Pontos justos. Mas o DSX ainda é algo a ser mantido e melhorado, o que ainda implica um esforço que eu gostaria de ver focado em outros aspectos mais críticos/faltos do ecossistema.

Outro aspecto da discussão com o qual não concordo é a constante comparação com o React. Eu entendo sua relevância, mas não quero que o Flutter seja uma cópia do React sem a ponte JS e alterando o nome dos Componentes para Widgets. Se é o mesmo, então por que mudar? Isso não significa que o Flutter deva tentar ficar o mais longe possível do React. Flutter deve ter sua própria identidade. Prefiro que a cultura Flutter de fornecer soluções seja proativa, não reativa. Devemos usar o React apenas como um ponto de contraste, não como uma diretriz.

No que me diz respeito, se algum desenvolvedor optou por não desenvolver no Flutter por causa do DSX/JSX não ser suportado, bem, essa pessoa não queria se juntar ao Flutter.

Outro aspecto da discussão com o qual não concordo é a constante comparação com o React. Eu entendo sua relevância, mas não quero que o Flutter seja uma cópia do React sem a ponte JS e alterando o nome dos Componentes para Widgets. Se é o mesmo, então por que mudar?

Porque o React tem lacunas que o Flutter poderia preencher e então você cria algo que é melhor do que o React porque ele corrige os contras do React com desempenho do Dart e gráficos acelerados por GPU, mantendo as melhores partes do React, bem como sua familiaridade.

No que me diz respeito, se algum desenvolvedor optou por não desenvolver no Flutter por causa do DSX/JSX não ser suportado, bem, essa pessoa não queria se juntar ao Flutter.

Não importa, o resultado final é que, se os desenvolvedores móveis que estão usando ferramentas de plataforma cruzada não aderirem ao Flutter, o Flutter falhará no mercado. Portanto, o Flutter precisa atrair desenvolvedores React Native para sua sobrevivência.

Falando sobre evolução, não é 'sobrevivência do mais apto', é 'sobrevivência do mais adaptável'. Adapte-se ou você perece.

@cbazza

Não importa, o resultado final é que, se os desenvolvedores móveis que estão usando ferramentas de plataforma cruzada não aderirem ao Flutter, o Flutter falhará no mercado.

Que? Por que precisaria? O Flutter pode formar seu próprio nicho enquanto está na versão beta (como fez com muito sucesso) e depois crescer organicamente sem precisar atrair mariposas com recursos superficialmente semelhantes. Além disso, o que você quer dizer com "falhar"? Flutter não precisa ser popular para ser um sucesso.

@naiveaiguy
Olha, eu sei que você votou negativamente nas respostas do cbazza.
Mas você poderia gastar 15 segundos para ver isso antes de votar negativamente na minha resposta?

Antes de pensar em DSX.
Basta dar uma olhada abaixo, é apenas um JSX.

Depois de construir uma barra de navegação e um corpo, basta importar o código de barras de navegação do seu código de barras de navegação.

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

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

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

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

Talvez alguém odeie o JSX porque é do Facebook, mas na verdade é de uma pequena empresa japonesa de jogos.

Tendo feito aplicativos com React Native e Flutter, sinto que no estado atual o JSX é mais fácil de ler e ajustado do que classes Dart aninhadas puras.
No entanto, como mencionado anteriormente, o Facebook teve uma razão para usar JSX devido à forma como o JavaScript é escrito (por exemplo, sem parâmetros de construtor nomeados), o que não é o caso do Dart. Além disso, a segurança do tipo Dart adicionada é realmente boa!
Portanto, caso o Flutter se atenha à sintaxe pura do Dart no final, espero ver melhorias com o marca-texto de sintaxe e o formatador automático. Os novos comentários da tag de fechamento já são uma grande melhoria, mas não o suficiente para alcançar a produtividade do JSX.

@JonathanSum Você está explicando a ideia de componentes reutilizáveis. Você não precisa do JSX para fazer componentes reutilizáveis. Eu acho que poderia ter algo melhor refing a sintaxe do Dart, mas DSX não é uma boa maneira de fazer isso.

@hartmannj Estamos sempre à procura de melhorias na sintaxe, marcador e formatador do Dart que ajudarão na produtividade. Para quaisquer ideias ou propostas específicas para tais melhorias que você ou outros possam ter pensado, eu ficaria muito curioso para saber mais.

IMHO tirando a necessidade de usar new/const já ajudou bastante. Eu tenho dificuldades reais na forma como o formato de dardo formata as árvores. não enfatiza o suficiente a estrutura de árvore IMHO em comparação com:

    return Scaffold(
      appBar: AppBar(title: Text("WeatherDemo")),
      resizeToAvoidBottomPadding: false,
      body: 
        Column(children: <Widget>
        [
          Padding(
            padding: const EdgeInsets.all(16.0),
            child: 
            TextField(
                    key: AppKeys.textField,
                    autocorrect: false,
                    controller: _controller,
                    decoration: InputDecoration(hintText: "Filter cities",),
                    style:  TextStyle(fontSize: 20.0,),
                    onChanged: ModelProvider.of(context).textChangedCommand,
                    ),
          ),

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

O React não requer o uso de JSX, mas a maioria das pessoas o considera útil como auxílio visual ao trabalhar com UI dentro do código JavaScript. Também permite que o React mostre mensagens de erro e aviso mais úteis.

Quando tantos desenvolvedores estão ansiosos para usar o tipo JSX para construir a interface do usuário, isso significa que o caminho é necessário e eles não devem ser ignorados.

@woodstream O tipo de pessoa que está ansiosa para usar o JSX já são fãs dos fanboys do React. Eles já estão usando React Native. O Flutter está atendendo a um tipo muito diferente de desenvolvedor.

EDIT : Admito que meu uso de fanboy estava errado aqui.

@naiveaiguy , @Hixie

O tipo de pessoa que está ansioso para usar JSX já são fanboys do React. Eles já estão usando React Native. O Flutter está atendendo a um tipo muito diferente de desenvolvedor.

Você está errado e seus xingamentos comentários divisivos ('React fanboys' e 'diferentes tipos de desenvolvedores') não são bem-vindos. JSX/DSX tem mérito técnico e outros preferem. Este tópico é para discutir que, se você não gostar, cancele sua inscrição. Também pare de votar em cada um dos meus comentários, isso não é um bom presságio para você.

Eu apenas sugiro oferecer duas maneiras para os desenvolvedores escolherem qual eles gostam, e alguém gosta de dar polegares para baixo na frente de opiniões diferentes? A tecnologia deve ser aberta e inclusiva, em vez de jogar em uma comunidade fechada.

@anders-sandholm Concordo com @escamoteur sobre a necessidade de melhorar a visibilidade da árvore de widgets. Eu teria feito o exemplo dele da seguinte forma:

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

Além disso, eu poderia imaginar destacar os nomes das classes Widget com uma cor, estilo de fonte ou peso diferente para que fosse ainda mais reconhecível imediatamente.

@cbazza

Nome chamando? Não quis dizer que essas pessoas eram negativas, apenas que eram diferentes. Eu gosto deste tópico, mas acusar-me de argumentar de má fé é um pouco irônico.

A palavra "fanboy" é geralmente considerada uma derrogativa, e foi tomada nesse contexto também. Eu recomendo evitar palavras como essa em discussões aqui.

Por favor, todos, sejam civis e construtivos. Estamos discutindo estilo aqui, algo muito subjetivo, então não importa o quanto cada um goste de sua própria preferência, é improvável que seja inerentemente superior à de todos os outros. Liste as vantagens e desvantagens que você vê nas sintaxes existentes e propostas, mas lembre-se de que nem todo mundo vê da mesma maneira, e isso está perfeitamente bem.

@hartmannj

Apenas alguns pequenos esclarecimentos...

No entanto, como mencionado anteriormente, o Facebook teve uma razão para usar JSX devido à forma como o JavaScript é escrito (por exemplo, sem parâmetros de construtor nomeados), o que não é o caso do Dart.

Na verdade, desde ES2015/ES6, JS tem parâmetros nomeados; você pode simplesmente usar 'desestruturando' para isso :)
Aqui está um exemplo:

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


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

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

Além disso, a segurança do tipo Dart adicionada é realmente boa!

Você obtém a mesma segurança de tipo com o DSX, o que é realmente bom.

Como esta é uma duplicata do https://github.com/flutter/flutter/issues/11609 relatado anteriormente, vou fechar este em favor daquele.

eu realmente não entendo como as pessoas podem votar contra isso - algo que é tão natural para a forma como o código declarativo é escrito na era da internet.

<like><this /></like>

por favor, seja flexível o suficiente para dar ao flutter a chance de voar!

infelizmente, isso parece sem esperança, todas as tecnologias usavam marcação para criar UI no passado e até agora e toda essa experiência do desenvolvedor agora está sendo desperdiçada pela vibração.

não precisamos fazer isso como reagir nativo ou html, basta usar xml simples

e talvezeee... xml embutido no dardo! ;P

Em terça-feira, 28 de agosto de 2018 às 21:29, Touseef [email protected] escreveu:

não precisamos fazer isso como reagir nativo ou html, basta usar xml simples

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/flutter/flutter/issues/15922#issuecomment-416550338 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AC8aNdVb_NV8c8JH4t36OS1OOvX6kY58ks5uVSmjgaJpZM4S6HPa
.

--
Tony Polinelli

Para mim, a funcionalidade do tipo JSX é o futuro e se tornará uma construção padrão para estruturas declarativas como React, Vue e Flutter.

não precisamos incorporar xml no dart se pudermos ter apenas 2 arquivos separados para interface do usuário e lógica, podemos seguir facilmente mvvm, mvc ou qualquer outro padrão desejado.

Já disse no outro tópico, mas:

Se você realmente quer JSX, um bom começo é usar a geração de código. Vá com um arquivo .html ou .xml e gere widgets a partir deles.

Obviamente, este não é um JSX completo, mas é um começo. O suficiente para ver como a comunidade reagirá a isso.
Se essa sintaxe ganhar força, talvez a equipe do Flutter reconsidere o tópico.

Caso contrário, acho que é apenas uma perda de tempo. Podemos ver claramente a partir daqui que é um tema fortemente debatido.

Se o flutter introduzir e xml / jsx / chamá-lo do que você quiser para criar a interface do usuário, eu começaria a usá-lo para aplicativos de nível de produção em um batimento cardíaco!

Eu concordo @leossmith que é a única coisa que é um obstáculo para aplicativos de nível de produção.

Eu pessoalmente preferiria _não_ adicionar JSX ou uma linguagem de marcação externa. Prefiro manter tudo em um único idioma com verificação de tipo. Eu sinto que uma abordagem melhor é continuar melhorando a linguagem Dart com a finalidade de codificar árvores de interface do usuário declarativas profundamente aninhadas. Eles já adicionaram alguns recursos interessantes nesta área:

• Tornar as palavras-chave new e const opcionais ajuda.
• Tags de fechamento virtuais no IDE
• dartfmt também ajuda

Prefiro manter tudo em um único idioma com verificação de tipo

É exatamente isso que o DSX/JSX faz, a linguagem é Dart para DSX, Javascript para JSX !!!

Eu sinto que uma abordagem melhor é continuar melhorando a linguagem Dart com a finalidade de codificar árvores de interface do usuário declarativas profundamente aninhadas.

O DSX é uma melhoria da linguagem Dart para oferecer melhor suporte a árvores declarativas profundamente aninhadas. Assim como JSX é para Javascript.

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

O objetivo desta especificação é definir uma sintaxe concisa e familiar para definir estruturas de árvore com atributos.

@cbazza Você levanta um bom ponto. JSX é apenas uma melhoria para JavaScript.

Então, primeiro vamos separar claramente duas coisas:

1. DSL externo para definir a interface do usuário. Eu sou 100% contra isso. Sempre acreditei que isso cria mais problemas do que resolve. Eu escrevi um post no blog discutindo esse ponto. Ele obteve 58 mil visualizações e, surpreendentemente, quase nenhuma opinião divergente: 80% da minha codificação está fazendo isso (ou por que os modelos estão mortos)
2. Melhorias na linguagem. Para facilitar a construção e a visualização de estruturas de árvore de UI profundamente aninhadas. Quanto a isso, ambos concordamos que há espaço para melhorias.

Mas diferemos ligeiramente na abordagem. Existem duas razões pelas quais o JSX faz mais sentido para o React:

1. Estrutura de dados: Na web, o JSX corresponde exatamente ao que está sendo gerado (nós HTML DOM). No flutter, estamos gerando instâncias de Widget.
2. Familiaridade: As pessoas estão acostumadas a olhar para código html. Mas a proposta DSX desvia-se do JSX/XML apenas o suficiente para invalidar este ponto.

Abaixo estão as duas coisas (eu acredito) que tornam o XML bom (e legível) para a construção de árvores de interface do usuário. A questão é, eles podem ser alcançados sem introduzir XML na linguagem:

1. XML tem tags End. Isso é possível com ou sem uma sintaxe xml-ish. O Visual Basic tinha isso nos anos 90 (pense no End If). E outras línguas têm isso. O IDE fornece "tags finais virtuais", mas isso é meio incompleto. Eu preferiria suporte a idiomas.
2. XML tem tratamento especial para crianças. Os atributos são distintos dos filhos. Mas eu diria que esta é uma faca de dois gumes. Existem alguns casos em que o Dart é realmente mais claro e expressivo que o XML a esse respeito. Por exemplo, widgets de contêiner com diferentes modelos de conteúdo filho:

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

Proposta de Dave para problema de tag final

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

Isso seria fácil de ler por humanos. E um analisador apenas substituiria )ButtonsView por ) . Além disso, o IDE poderia fornecer melhor verificação e assistência com esse esquema. Eu tornaria necessário a qualquer momento que os parênteses abertos e fechados não estivessem na mesma linha.

Proposta de Dave para o problema dos filhos aninhados

Algumas linguagens (como kotlin) permitem tratamento especial para argumentos do tipo lambda. Eles permitem que você coloque o argumento lambda fora dos parênteses. Consulte Passando um lambda para o último parâmetro .

Proponho algo semelhante para Dart, mas como argumento do tipo List, não para lambdas. Proponho uma sintaxe especial para passar um argumento de lista de tipos chamado "filhos":

```
//ao invés disso:
Foo(a: 1, b:10,c:44, filhos:[...])

//fazemos isso:
Foo(a: 1, b:10,c:44)[

]

Para construtores/funções que recebem um único filho ou 2 filhos (como superior e inferior), deixe-o como está, sem alterações.

Prefiro manter tudo em um único idioma com verificação de tipo

É exatamente isso que o DSX/JSX faz, a linguagem é Dart para DSX, Javascript para JSX !!!

Eu sinto que uma abordagem melhor é continuar melhorando a linguagem Dart com a finalidade de codificar árvores de interface do usuário declarativas profundamente aninhadas.

O DSX é uma melhoria da linguagem Dart para oferecer melhor suporte a árvores declarativas profundamente aninhadas. Assim como JSX é para Javascript.

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

O objetivo desta especificação é definir uma sintaxe concisa e familiar para definir estruturas de árvore com atributos.

@StokeMasterJack - sua proposta para o problema da tag final parece a mesma que minha proposta há algum tempo.
Ideia: tags de fechamento geradas automaticamente

Acho que o flutter precisa de algo assim. Eu luto para inserir novos widgets dentro de um ninho profundo na maioria dos dias. Eu usaria uma sintaxe do tipo JSX apenas para obter a notação da tag final.

Eu não quero ter que escrever tags de fechamento. É uma dor em JSX/html/xml. Especialmente quando eu quero refatorar.
Eu acho que as tags de fechamento virtuais são bem legais. Parece um bom compromisso entre os dois mundos.

Se realmente precisarmos de algumas melhorias aqui, acho que podemos continuar explorando o lado do IDE. Por exemplo, vscode fornece o seguinte painel:

(Tenho certeza que o Android Studio tem o mesmo)

Em vez de parar no método focado, poderíamos adicionar construtores aninhados também.
Para que, ao passar o mouse sobre uma classe específica, tenhamos a seguinte interface do usuário:

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

Se se trata de separar visualmente os widgets de outro tipo de conteúdo, o IDE também pode fazer isso novamente.

Podemos ter um destaque de sintaxe diferente para widgets. Em vez da cor usual usada para classes, podemos ter uma cor específica para subclasse de widget

Se for sobre editabilidade, o Flutter já fornece todas as ferramentas que você precisa.

Existem algumas opções de refatoração, incluindo:

• Envolva em um novo widget
• Remover widget
• Trocar widget com filho
• Trocar widget com pai

Com isso em mente, você não precisa mais lidar com parênteses.

Com toda a honestidade, passei horas diariamente brincando com o Flutter por meses. E não senti falta de legibilidade ou desconforto em escrever widgets aninhados.
Enquanto em comparação, eu usei o React para tanto e existem algumas coisas que me frustram.

@rrousselGit - essas opções de refatoração que você tem parecem úteis. Eu não os vejo no Android Studio 3.2.
Achei que o Android Studio forneceria os melhores recursos para o desenvolvimento do Flutter.

@Rockvole

Aqui está uma captura de tela do Android Studio:

Ativado como uma correção rápida Option+Enter (macOS).
Eu uso isso o tempo todo, super útil.

Sobre o tópico: parece que a equipe do Flutter está explorando opções para "UI como código" e podemos obter mais melhorias nessa frente mais cedo ou mais tarde. Embora as ideias de @StokeMasterJack pareçam interessantes.

@Rockvole Grandes mentes pensam da mesma forma!

@StokeMasterJack

Bela resposta!!!

Existem duas razões pelas quais o JSX faz mais sentido para o React:

1. Estrutura de dados: Na web, JSX corresponde exatamente ao que está sendo gerado (nós HTML DOM). No flutter, estamos gerando instâncias de Widget.

O poder do JSX não está na geração de nós HTML/DOM, está no gerenciamento de hierarquias de componentes; O React Native não possui nós HTML/DOM certo?

1. Familiaridade: As pessoas estão acostumadas a olhar para código html. Mas a proposta DSX desvia-se do JSX/XML apenas o suficiente para invalidar este ponto.

Assim como acima, não se trata de código HTML, trata-se de uma sintaxe que se torna claramente separada das construções imperativas da linguagem host e grita marcação declarativa para construir hierarquias de árvores .

Não sou fã da sua proposta ou da Kotlin porque parece um hack feito para evitar fazer um design adequado. Em vez de projetar uma DSL que pareça distinta, agora tenho que examinar o código e tentar descobrir o que ela faz; A sintaxe parece ambígua. Há benefícios para separar construções imperativas e declarativas; Ferramentas de terceiros podem localizar facilmente a marcação XML dentro do código, por exemplo.

@Rockvole

Eu usaria uma sintaxe semelhante a JSX apenas para obter a notação de tag final

Bom saber ;)

@rrousselGit

Eu não quero ter que escrever tags de fechamento.

Você não precisa; O WebStorm, por exemplo, gera automaticamente a tag de fechamento e até renomeia as tags de abertura ou fechamento conforme você edita a outra. Funcionalidade de editor realmente ótima que outros deveriam seguir (olhando para você 'VS Code').

Com toda a honestidade, passei horas diariamente brincando com o Flutter por meses. E não senti falta de legibilidade ou desconforto em escrever widgets aninhados

Espero que você possa apreciar que sua experiência não reflete a experiência de todos os outros. Com as ferramentas, escrever não é tão doloroso quanto ler o código. Vá para o github para ler o código de outras pessoas e você notará que a leitura é uma dor, o código é muito detalhado e longo com estruturas aninhadas. Parece que quando as cadeias de promessas foram usadas antes de async/await mostrar uma maneira melhor. Também parece que as técnicas declarativas são menos importantes que as imperativas; Quero dizer, por que não há construções de gráficos vetoriais declarativos? em vez disso, tenho que usar chamadas imperativas para Skia para desenho de gráficos vetoriais, por exemplo.

Você não precisa; WebStorm, por exemplo, gera automaticamente

O Vscode também faz isso. Mas que ainda não é perfeito. Especialmente na etapa de refatoração ao mover as coisas.
Acho que as tags virtuais proporcionam uma experiência muito mais suave aqui.

Espero que você possa entender que sua experiência não reflete a experiência de todos os outros

Com certeza ! Eu só queria salientar que pode ser mais uma inexperiência com as ferramentas do que uma falta real 😄

Vá para o github para ler o código de outras pessoas e você notará que ler é uma dor, [...]

Não vejo bem como seus argumentos aqui estão relacionados ao tópico.
O problema que você listou vem de más práticas, não de sintaxe ruim. Não é culpa do Flutter se as pessoas querem fazer uma árvore de widgets de 500 vezes.

@pulyaevskiy - obrigado pela dica útil, no Linux a solução rápida é Alt-Enter. Não é um recurso muito fácil de descobrir, vasculhei as opções do menu superior, mas parece não estar em nenhum lugar, exceto pelo pressionamento de teclas mágicas :)

Acho que as tags virtuais proporcionam uma experiência muito mais suave aqui.

Essas tags virtuais aparecem no arquivo de origem no github, por exemplo?

Não vejo bem como seus argumentos aqui estão relacionados ao tópico.

Basicamente, a linguagem pode fornecer construções para tornar as coisas menos detalhadas, como mencionei no exemplo de promessas vs. async/await. No Flutter Widget os construtores são enormes e muitas vezes eles pegam muitos parâmetros; com o DSX, você pode usar o operador spread , por exemplo, para compactar um construtor de 10 linhas em um construtor de 1 linha e, portanto, ainda pode ter a hierarquia de árvore completa visível com menos ruído ao redor. Isso facilita a leitura do código e permite uma separação limpa do estilo da estrutura da árvore, por exemplo. Não estou dizendo que isso não pode ser feito reestruturando seu código Dart, mas pode ser feito sem muito esforço ou reestruturando as coisas. Você não precisa se adequar às limitações da linguagem, a linguagem se adapta a você.

O problema que você listou vem de más práticas, não de sintaxe ruim.

Antes de async/await, as práticas recomendadas eram usar promessas em vez de retornos de chamada de eventos malucos em todos os lugares. O uso de promessas causa problemas de legibilidade que foram resolvidos por async/await. É basicamente a mesma coisa apenas açúcar sintático, mas async/await é mais claro ao ler o código de outra pessoa.

Este é um exemplo terrível @woodstream

Atualização : Apenas para deixar meu ponto de vista e não apenas bater palavras sem argumentos. O equivalente DSX é tão longo... Isso não tem nada a ver com contagem de linhas ou HTML.

class MusicImage extends StatelessWidget {

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

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

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

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

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

Como desenvolvedor React, acho que o que essa comunidade precisa fazer é fornecer esse recurso por conta própria e quando os desenvolvedores começarem a adaptá-lo e usá-lo de fato; os principais contribuintes serão forçados a adaptá-lo nativamente também. Eu sou um desenvolvedor React e tenho muitos problemas ao lidar com como a interface do usuário é escrita em flutter, adoraria mudar para flutter, mas a sintaxe não está ajudando, eu até pesquisaria como implementar a sintaxe do tipo JSX eu mesmo, como disse antes "É bom ter a opção".

Eu acho que uma das principais razões pelas quais as pessoas estão lutando contra isso é que elas não podem imaginá-las usando. A verdade é que você realmente não precisa, assim como as pessoas usam (comparando para reagir) React.createElement(Component, {}, null) em oposição a <Component /> Se isso for implementado, isso atrairá as pessoas para usar o Flutter no primeiro lugar, e é isso que realmente queremos. Uma grande comunidade dedicada ao Flutter com apoio mútuo. Se não for o tipo de sintaxe que você usaria, tudo bem. Mas toneladas prefeririam uma notação como JSX em oposição ao método atual.

Pessoalmente, acho que SGML e seus derivados são simplesmente feios. Se estamos fazendo uma DSL, por que não uma com sintaxe do tipo QML?

Também acho que alguns dos pontos pró-DSX estão combinando recursos do Javascript como linguagem (que o Dart como linguagem não possui) e recursos do JSX como DSL. Por exemplo,

Basicamente, a linguagem pode fornecer construções para tornar as coisas menos detalhadas, como mencionei no exemplo de promessas vs. async/await. No Flutter Widget os construtores são enormes e muitas vezes eles pegam muitos parâmetros; com o DSX, você pode usar o operador spread , por exemplo, para compactar um construtor de 10 linhas em um construtor de 1 linha e, portanto, ainda pode ter a hierarquia de árvore completa visível com menos ruído ao redor.

Esse não é um recurso que o DSX concederia magicamente, é um recurso que o JSX possui porque o Javascript o possui. Dart como uma linguagem poderia ganhar o operador spread (IMO bastante improvável), caso em que você seria capaz de usá-lo com construtores e outras chamadas de função sem precisar de um DSL especial em cima das coisas. É também um recurso que funciona em grande parte porque os objetos, hashmaps e arrays do Javascript são essencialmente a mesma coisa, o que definitivamente não é o caso do Dart e quase definitivamente nunca vai mudar.

E esse eu acho que é o problema que muitas pessoas contra a proposta têm, mesmo que não seja vocalizada - é essencialmente um pedido para que o Dart se comporte (ou finja se comportar) como Javascript, e embora existam alguns prós, o fato é que eles simplesmente são linguagens diferentes que vêm divergindo cada vez mais desde os primeiros dias do Dart 1.

Edit: O que não quer dizer que uma DSL de marcação/modelagem para interface do usuário seja totalmente uma má ideia. Sinceramente não, mas acho que a inspiração para isso deve vir de linguagens/frameworks que são um pouco mais semelhantes a Dart/Flutter (no paradigma de digitação, bem como outros detalhes semânticos - não estou falando de sintaxe simples) do que Javascript é.

Dart como idioma pode ganhar o operador de spread (IMO bastante improvável)

Na verdade, o spread para coleções já está especificado e pronto para implementação, consulte Spread Collections e todo o "Funil de idioma" para obter mais informações sobre os próximos recursos do idioma Dart.

@mraleph Eu estava falando sobre o operador spread especificamente em uso em chamadas de função/construtor e com objetos, não apenas com listas ou mapas - é o que acho improvável. Desculpe se não ficou claro!

(Estou vagamente ciente dessa proposta, mas a última vez que verifiquei você não pode simplesmente espalhar um Dart Size(10, 10) da maneira que você pode espalhar/destruir um Javascript Size { width: 10, height: 10 } ou espalhar uma lista /map de argumentos em uma chamada de função normal (não usando Function.apply , o que sacrificaria a segurança de tipo))

@filleduchaos

Pessoalmente, acho que SGML e seus derivados são simplesmente feios. Se estamos fazendo uma DSL, por que não uma com sintaxe do tipo QML?

Porque muita gente, diferente de você, não acha feio e prefere. Você não precisa ter muita visão para ver todos os desenvolvedores entusiasmados do React por aí.

O JSX/DSX traz a marcação para a linguagem host Javascript/Dart de uma forma que aprimora a linguagem host e habilita todas as construções de linguagem programática na marcação. Coisas muito simples e poderosas.

Esse não é um recurso que o DSX concederia magicamente, é um recurso que o JSX possui porque o Javascript o possui.

Não é verdade; O DSX pode implementar a propagação por si só, não precisa do Dart para apoiá-lo. Seria bom se isso acontecesse, mas não um requisito. Essa é a beleza de transpilar de um idioma superior para o Dart, o idioma superior não precisa ser restringido pelo Dart.

Meu protótipo de transpilador DSX online processa o operador de propagação muito bem, confira:
https://spark-heroku-dsx.herokuapp.com/index.html

E esse eu acho que é o problema que muitas pessoas contra a proposta têm, mesmo que não seja vocalizada - é essencialmente um pedido para que o Dart se comporte (ou finja se comportar) como Javascript, e embora existam alguns prós, o fato é que eles simplesmente são linguagens diferentes que vêm divergindo cada vez mais desde os primeiros dias do Dart 1.

Pare de pensar sobre o que é o Dart atual e concentre-se no que poderia ser, pegando as melhores ideias de todas as outras linguagens existentes.

Eu acho que a inspiração para isso deve vir de linguagens/frameworks que são um pouco mais semelhantes a Dart/Flutter (no paradigma de digitação, bem como outros detalhes semânticos - não estou falando de sintaxe simples) do que Javascript.

Typescript é digitado e suporta JSX. A estrutura de interface do usuário mais próxima do Flutter é o React, e adivinhe o que o React decolou por causa do JSX. Por favor, venha com algo melhor do que JSX/DSX e se você fizer, as pessoas vão parar de pedir JSX/DSX, mas eu não vi nada por aí que eu considere melhor, então agora JSX é o estado-da-arte .

É bom ver que o pessoal da linguagem Dart está pegando as melhores ideias de outras linguagens como Python (compreensão de lista e dicionário).

@cbazza

Porque muita gente, diferente de você, não acha feio e prefere.

E vice versa. Por que essa sintaxe e não qualquer outra, principalmente quando ela não tem uma relação forte com a linguagem? (Com o Android SDK, Java e XML tinham uma relação de anos. Idem com Javascript e HTML, que JSX se assemelha muito. DSX como proposto estaria trazendo a sintaxe SGML baseada nele fazendo sentido para outras linguagens, mas não necessariamente para _Dart_).

O JSX/DSX traz a marcação para a linguagem host Javascript/Dart de uma forma que aprimora a linguagem host e habilita todas as construções de linguagem programática na marcação. Coisas muito simples e poderosas.

Não é verdade; O DSX pode implementar a propagação por si só, não precisa do Dart para apoiá-lo. Seria bom se isso acontecesse, mas não um requisito. Essa é a beleza de transpilar de um idioma superior para o Dart, o idioma superior não precisa ser restringido pelo Dart.

É bastante interessante olhar para essas duas declarações em justaposição, porque elas apenas provam meu ponto de vista. JSX é ótimo (para Javascript) especificamente por causa de sua simplicidade - é simplesmente açúcar sobre o que já são construções de linguagem JS, ele realmente não implementa nenhuma semântica especial. Você elogia corretamente essa simplicidade, então continua dizendo que o DSX deve implementar a semântica por si só, independentemente do idioma de destino, aparentemente sem reconhecer 1) quanto mais trabalho é pedir e 2) como ele derrota inteiramente o ponto de ser um DSL simples, mas poderoso.

Meu protótipo de transpilador DSX online processa o operador de propagação muito bem, confira:
https://spark-heroku-dsx.herokuapp.com/index.html

Eu já vi seu transpilador antes e, embora seja um trabalho impressionante, ele não chega nem perto de processar o operador de propagação da maneira que o Javascript como uma linguagem (e, portanto, o JSX) faz por padrão. Como foi mencionado, espalhar (e eventualmente desestruturar) coleções não está muito em desacordo com o Dart e, de fato, está em processo de implementação. Espalhar e desestruturar qualquer objeto (que, ao contrário do JS, não é a mesma coisa que Maps) é, e seu transpilador também não parece lidar com isso (e de fato requer colocar argumentos dentro de Maps, o que é bastante unidiomático e Dart inutilizável (não pode interagir de forma decentemente segura, por exemplo)).

Pare de pensar sobre o que é o Dart atual e concentre-se no que poderia ser, pegando as melhores ideias de todas as outras linguagens existentes.

Certo. Mas das linguagens disponíveis para o Dart, pessoalmente, o JS não está muito no topo da lista - eu honestamente acho que tentar ser muito parecido com o JS (por causa da interoperabilidade) prejudicou o Dart em seus primeiros dias.

Eu adoraria uma DSL de interface do usuário, com certeza. Mas essa DSL deve ser idiomática para _Dart_, não retirada de uma linguagem semanticamente diferente apenas por causa da popularidade.

E eu também gostaria que as pessoas parassem de confundir o que o Javascript faz com o que o JSX o DSL faz, porque alguns dos benefícios mencionados são, na verdade, solicitações de recursos em nível de linguagem disfarçadas. Para continuar com o operador de spread, se o Dart como uma linguagem realmente suportasse todo o alcance do operador como está em JS, não vejo como return <SomeWidget {...someArgs, arg: newValue } />; é preferível de ler do que return SomeWidget(...someArgs, arg: newValue); ou return SomeWidget { ...someArgs, arg: newValue }; do tipo QML, a menos que tenha algum apego ao SGML.

@filleduchaos

Por que essa sintaxe e não qualquer outra, principalmente quando ela não tem uma relação forte com a linguagem? (Com o Android SDK, Java e XML tiveram uma relação de anos. Idem com Javascript e HTML, que JSX se assemelha muito. DSX como proposto estaria trazendo a sintaxe SGML baseada nele fazendo sentido para outras linguagens, mas não necessariamente para Dart).

Pare de juntar coisas que você acha que combinam (e tenha um relacionamento) e concentre-se em escolher as melhores ideias, independentemente de onde elas vêm. Você está segregando artificialmente as coisas quando não há necessidade disso.

Estou escolhendo a sintaxe JSX porque é bem vista no React e é isso que as pessoas do React esperam e querem. Este bilhete é sobre isso, se não for para você, não o use.

É bastante interessante olhar para essas duas declarações em justaposição, porque elas apenas provam meu ponto de vista. JSX é ótimo (para Javascript) especificamente por causa de sua simplicidade - é simplesmente açúcar sobre o que já são construções de linguagem JS, ele realmente não implementa nenhuma semântica especial. Você elogia corretamente essa simplicidade, então continua dizendo que o DSX deve implementar a semântica por si só, independentemente do idioma de destino, aparentemente sem reconhecer 1) quanto mais trabalho é pedir e 2) como ele derrota inteiramente o ponto de ser um DSL simples, mas poderoso.

Se implementa nova semântica ou não, é irrelevante. A simplicidade vem de seu uso. Se for fácil para os usuários/desenvolvedores usarem, eles o usarão. Usuários/Desenvolvedores não se importam com o quão complexo internamente algo é (ou quanto trabalho era fazer), eles apenas se importam com o quão simples isso torna sua vida e melhora seu código.

Eu já vi seu transpilador antes e, embora seja um trabalho impressionante, ele não chega nem perto de processar o operador de propagação da maneira que o Javascript como uma linguagem (e, portanto, o JSX) faz por padrão.

Minha intenção com o spread no DSX era apenas espalhar atributos e não uma implementação JS completa do spread. Funciona muito bem para o que é e não tem problemas de segurança de tipo. A verificação/correção de tipo ocorre quando o Dart compila o que o DSX gera.

aleijado Dart em seus primeiros dias.

O que prejudicou o Dart nos primeiros dias não era fornecer interoperabilidade JS simples para que as bibliotecas JS atuais pudessem ser usadas facilmente com código Dart (e vice-versa). Além disso, esta é exatamente a mesma razão pela qual o Typescript teve sucesso onde o Dart falhou.

Eu adoraria uma DSL de interface do usuário, com certeza. Mas esse DSL deve ser idiomático para o Dart, não retirado de uma linguagem semanticamente diferente apenas por causa da popularidade.

A popularidade dita tudo. As melhores ideias são as melhores ideias porque se tornam populares porque muitas pessoas apreciam seus benefícios.

E eu também gostaria que as pessoas parassem de confundir o que o Javascript faz com o que o JSX o DSL faz, porque alguns dos benefícios mencionados são, na verdade, solicitações de recursos em nível de linguagem disfarçadas.

Novamente, isso não é relevante.

O que realmente precisamos do pessoal do Google (Dart/Flutter) é suporte genérico de transpilação através de mapas de origem para que qualquer linguagem de nível superior possa ser desenvolvida que tenha como alvo o Dart/Flutter e funcione bem com as ferramentas atuais (IDE, depurador, etc) . Nivele o campo de jogo e você garante que as melhores ideias chegarão à plataforma de outras pessoas.

@cbazza

Estou escolhendo a sintaxe JSX porque é bem vista no React e é isso que as pessoas do React esperam e querem. Este bilhete é sobre isso, se não for para você, não o use.

Isso parece bastante divisivo e bastante direito para mim. Por que o Flutter deve ter suporte de primeira classe para a sintaxe React especificamente? Por que não arquivos de componentes Vue ou sintaxe Xamarin.Forms? Por que a DSL de interface do usuário (presumivelmente oficial) para Flutter deve ser baseada no que um conjunto específico de pessoas que usa uma estrutura diferente em um idioma diferente espera e deseja? Se você quer uma ferramenta de comunidade especificamente para desenvolvedores React/JS, isso seria uma coisa. Mas pedir que o próprio framework o inclua apenas para atender a todos vocês é um pouco IMO.

Se implementa nova semântica ou não, é irrelevante. A simplicidade vem de seu uso. Se for fácil para os usuários/desenvolvedores usarem, eles o usarão. Usuários/Desenvolvedores não se importam com o quão complexo internamente algo é (ou quanto trabalho era fazer), eles apenas se importam com o quão simples isso torna sua vida e melhora seu código.

Esta é uma forma tão estranha de direito na minha opinião. E não, os desenvolvedores se preocupam com a complexidade de uma implementação quando ela começa a causar problemas e desvios de recursos, como a complexidade nas abstrações tende a fazer. Os desenvolvedores que desejam fazer mais do que apenas usar o DSL - estendê-lo, por exemplo - definitivamente se preocupam com a complexidade da implementação. Os desenvolvedores que teriam que construí-lo e mantê-lo também são pessoas que merecem consideração nisso.

Minha intenção com o spread no DSX era apenas espalhar atributos e não uma implementação JS completa do spread. Funciona muito bem para o que é e não tem problemas de segurança de tipo. A verificação/correção de tipo ocorre quando o Dart compila o que o DSX gera.

Ele só "não tem problemas de segurança de tipo" se você não pensar nisso. O que eu disse foi que os mapas de argumentos não são _usáveis_ de uma maneira completamente segura com o resto de uma base de código Dart, onde presumivelmente você gostaria de interagir com esses argumentos da maneira que você pode com adereços e afins em JavaScript - passe-os de outro Widget, importá-los de outro módulo, etc - e não apenas declará-los em um lugar; nesse caso, qual é o objetivo de uma chamada de construtor normal?

Para ilustrar o que quero dizer, você pode fazer isso em JS:

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

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

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

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

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

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

Mas com o Dart e seu transpilador que requer hashmaps de argumentos:

class MyCustomSize {
  int length, width, height;

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

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

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

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

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

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

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

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

O que prejudicou o Dart nos primeiros dias não era fornecer interoperabilidade JS simples para que as bibliotecas JS atuais pudessem ser usadas facilmente com código Dart (e vice-versa). Além disso, esta é exatamente a mesma razão pela qual o Typescript teve sucesso onde o Dart falhou.

A interoperabilidade do Dart com o JS nunca foi complexa, a menos que (e este é um ponto que continuo enfatizando) você simplesmente queira ainda escrever Javascript e seja avesso a aprender qualquer outra coisa. Typescript sendo um superconjunto não tem tanto operacionalidade com JS quanto simplesmente é JS, a ponto de ter deliberadamente um sistema de tipos insalubre apenas para atender a JS (assim como nenhum tempo de execução para realmente impor seu sistema de tipos expressivos, que é um pena que tantos anos depois). Mas voltando ao meu ponto, eu pessoalmente sinto que o Dart tomou algumas decisões de design ruins por causa do JS e o Dart 2 realmente deveria ter sido a primeira iteração da linguagem.

A popularidade dita tudo. As melhores ideias são as melhores ideias porque se tornam populares porque muitas pessoas apreciam seus benefícios.

"Melhores", ou melhor, boas ideias são boas ideias porque têm mérito . Às vezes eles se tornam populares, às vezes não. Às vezes as ideias ruins se tornam populares, às vezes não. Sugerir que a popularidade é um indicador direto de mérito é francamente absurdo e é uma atitude que eu pessoalmente preferiria não se espalhar para a comunidade Dart, por menor que seja.

O que realmente precisamos do pessoal do Google (Dart/Flutter) é suporte genérico de transpilação através de mapas de origem para que qualquer linguagem de nível superior possa ser desenvolvida que tenha como alvo o Dart/Flutter e funcione bem com as ferramentas atuais (IDE, depurador, etc) . Nivele o campo de jogo e você garante que as melhores ideias chegarão à plataforma de outras pessoas.

...Eu não pensei que fosse possível ter mais direito do que você antes, e ainda assim aqui estamos. Por que esse SDK de interface do usuário deve ser segmentado por todas as linguagens de alto nível do mundo? Mais uma vez, a proposta fortemente, fortemente sai como "Faça o Dart/Flutter em minha linguagem/framework" - você pode simplesmente sair e dizer que deseja construir aplicativos Flutter com Javascript. E sim, mais graxa no cotovelo e eu seria a favor de contribuir para um projeto comunitário como esse, mas é francamente ridículo esperar uma resposta positiva se você solicitar apoio oficial para isso.

Novamente reiterando - eu não me importo com uma DSL de interface do usuário e realmente adoraria uma. Mas se estamos pedindo à equipe que o prepare, deve ser um DSL que seja idiomático para o Dart. Porque sim, existem dezenas de nós aqui que realmente gostam do Dart como idioma.

Ainda outra edição: uma coisa seria solicitar uma DSL, sugerir JSX como uma possível inspiração de sintaxe/sintaxe e estar aberto a outras sugestões. É a insistência no DSX que me incomoda (e suspeito que muitos comentaram) errado.

@filleduchaos

Você está hilariamente confuso e eu não tenho muito tempo a perder ainda.

A única coisa que estou pedindo à equipe Dart/Flutter é o que eu disse antes:

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

Isso fornece tudo o que é necessário para implementar DSX, arquivos de componentes Vue, Xamarin.Forms, NativeScript, QML etc. Não gosta de DSX, você pode usar o Dart simples ou criar sua própria coisa com facilidade.

Eu diria que você está procurando por coisas como https://github.com/dart-lang/build e dartanalyzer.
Você provavelmente perderá uma ou duas partes (como a capacidade de criar plugins do analisador como dependência de publicação), mas tenho certeza de que a equipe do Dart está bem em ajudar com isso.

De qualquer forma, não acho que ser duro um com o outro continuamente ajudará a estrutura a progredir de alguma forma.
O máximo que vamos tirar disso é outro assunto permanentemente encerrado porque ficou "muito aquecido".

@filleduchaos

Em relação ao seu exemplo 'foo', o spread DSX é uma coisa de tempo de compilação, então o mapa precisaria ser definido como const ou eu poderia inventar qualquer outra coisa que eu quisesse que acontecesse em tempo de compilação (por exemplo, criar um nova palavra-chave DSX ou anotação para ela seguida pelo mapa const). Tem que ser em tempo de compilação, em vez de em tempo de execução, porque o Dart não suporta a inserção de parâmetro de construtor dinâmico em tempo de execução. Não é um problema porque resolve o problema que eu queria resolver, ou seja, espalhando atributos em construtores.

@cbazza O ponto é que parte do que torna o operador spread tão útil no JS/JSX é que você não precisa impor restrições como "você só pode usar um hashmap" ou "todos os seus argumentos devem ser conhecidos em tempo de compilação" ou "você não pode interagir com os argumentos/props que deseja passar para um Widget da mesma forma que pode interagir com todo o resto" (observe que você não sugeriu nada para lidar com o caso em que a coisa com as propriedades que você need é na verdade um objeto, não um literal de mapa) -0 está tudo bem quando é um exemplo simples, mas esse tipo de coisa seria extremamente frustrante _fast_ em qualquer projeto de tamanho médio. Quero dizer, em que ponto alguém para de acumular soluções alternativas, compromissos e anotações, dá um passo para trás e se pergunta se a extensão é realmente uma boa opção para a linguagem como ela existe?

JSX tem sido um sucesso (comparado com a maioria dos templates) porque não o força a programar de uma certa maneira (ou melhor, não o força a escrever código de forma diferente do que você faria em Javascript de qualquer maneira). É praticamente indolor para usar com _any_ JavaScript; é isso que quero dizer com a criação de uma DSL que realmente se encaixa na linguagem. É algo semelhante com o Redux. Redux em uma base de código JS é uma beleza (quando usado corretamente); por outro lado, todos os exemplos de Flutter que eu vi usando o Redux extensivamente honestamente parecem dolorosos em comparação com o uso de Streams/o padrão BLoC. Isso não quer dizer que não há coisas que se sobreponham com grande sucesso: Context do React e Context InheritedWidget Flutter implementam um conceito comum que atende incrivelmente bem aos pontos fortes de ambos. Só não estou convencido de que o JSX é atualmente uma dessas coisas - exceto várias mudanças no nível da linguagem, honestamente parece que o DSX seria uma dor para desenvolver _e_ uma dor para usar para algo mais do que exemplos triviais, enquanto que provavelmente poderia escrever um transformador JSX completo do zero em um fim de semana preguiçoso por causa de quão simples é mapear para JS.

Também fui um pouco agressivo antes e peço desculpas.

@filleduchaos

Não estou tentando criar um operador de spread totalmente genérico que funcione em todos os lugares e para tudo, nem mesmo o planejado para o futuro Dart é tão genérico quanto o de JS. O que eu quero que o spread lide no contexto do DSX funciona muito bem. O DSX não tem necessidade de espalhar objetos, por exemplo.

Coleções de Spread
https://github.com/dart-lang/language/issues/47

Eu desenvolvi projetos super grandes com JSX e realmente nunca precisei usar spread nos atributos da tag. JSX funciona muito bem sem ele. A razão pela qual eu adicionei ao DSX é porque ele resolve um problema para widgets Flutter que não há solução simples para isso, especificamente se um widget leva 20 parâmetros no construtor, como você pode escrever isso em menos de 20 linhas contínuas que farão o widget árvore uma pirâmide de destruição. O único recurso do spread DSX é permitir tirar algumas dessas linhas da árvore e colocá-las em outro lugar.

@cbazaa Estou avaliando se uso React Native ou Flutter. Inclinando-se para Flutter porque tudo é apenas Dart para que o compilador possa verificar meus erros de digitação da interface do usuário. Veja também: https://medium.com/flutter-io/out-of-depth-with-flutter-f683c29305a8

O JSX também detecta meus erros de digitação? Eu uso TypeScript.

Eu odeio HTML / marcações separadas. Por exemplo, em Angular, se eu digitei errado alguma coisa/variáveis ​​em HTML, só encontro meus erros depois de renderizar a página.

@sivabudh

O JSX também detecta meus erros de digitação? Eu uso TypeScript.

Sim, alguns erros de digitação JSX são detectados em tempo de compilação (nome do componente, por exemplo), mas não nomes de prop (que serão detectados em tempo de execução) ao usar JS/ES6; mas como você está usando o TypeScript, o sistema de tipos captura todos os erros de digitação do JSX em tempo de compilação:
https://www.typescriptlang.org/docs/handbook/jsx.html

@cbazza é dsx de código aberto?

@pushqrdx
Ainda não, não liberei seu código fonte.

Como consumidor de React + TypeScript e Flutter posso me oferecer como testador. Saúde

Teremos fonte dsx? Vai ser muito grande!

Aplaudo os esforços do cbazza, mas não usarei o DSX no Flutter. Feliz por testá-lo, no entanto.

O problema nº 27141 acompanha a adição do suporte à geração de código ao sistema de compilação. Isso será feito através de https://github.com/dart-lang/build com Builder . Em teoria, deve ser bastante simples conectar um compilador/transpilador dsx quando esse recurso estiver pronto.

Depois de duas edições, conheci uma equipe tão teimosa pela primeira vez.

Esta não é uma discussão de JSX, mas uma discussão de inferno aninhado

Mesmo que você não possa fornecer uma solução JSX, você deve tornar o aninhamento menos e o código mais legível

Acho que a vantagem do JSX é óbvia, mas a equipe do flutter está tentando ignorá-la.

JSX não resolve o problema de aninhamento. Reagir enfrenta o mesmo problema

Se você não gosta desse aninhamento, você pode querer dar uma olhada em hooks , que é uma porta de hooks React, que são uma tentativa de resolver o inferno de aninhamento.

Acho que devemos descobrir por que o JSX surgiu. Isso porque a função h/createElement está mal escrita e o código é pouco legível. Inesperadamente, o flutter agora é escrito 10.000 vezes pior do que a função h/createElement , que pode ser vista pelos olhos

O JSX surge porque o React é, em sua essência, uma mistura de Javascript e HTML. A sintaxe XML com interpolação/injeção Javascript cria naturalmente o JSX.

O Flutter é totalmente separado do Javascript e do HTML, portanto, não traduz bem em JSX. Concordo que os projetos do Flutter geralmente são muito aninhados e pode ser uma dor real, especialmente quando dartfmt esmaga essas linhas fortemente aninhadas. Horrível.

Eu também observaria que senti que o Flutter era horrivelmente estruturado quando eu era novo nele, vindo do React, mas o Flutter é objetivamente muito mais fácil de trabalhar quando você passa da curva de aprendizado inicial. A curva de aprendizado não é exclusiva do Flutter, é comum ao aprender novos frameworks. O Flutter é especialmente difícil porque não tem motivos para agir como a sintaxe HTML com a qual muitas pessoas estão familiarizadas.

Acho que existem maneiras de melhorar o problema de aninhamento e o JSX não é a resposta.

Algumas ideias:

1. Desenvolva um guia de estilo interno que exija que as pessoas quebrem enormes árvores flutuantes em componentes menores.

2. Obtenha dartfmt para reconhecer formalmente que o Flutter tem um conjunto exclusivo de necessidades de formatação em comparação com os pacotes Dart e trabalhe com a equipe Flutter/Dart para encontrar uma solução que seja razoável. @munificent

3. Use a geração de código como o pacote @stateless do @rrousselGit para tornar mais fácil para os desenvolvedores fazer o número 1

Para ser justo, o problema de aninhamento surge principalmente quando não queremos refratar nosso código.

Widgets são feitos para serem divididos em muitos pedaços menores.
Use e abuse da ferramenta de refatoração extract widget .

Isso torna o código muito mais legível, reduz a redundância e potencialmente até corrige bugs/aumenta desempenhos.

Embora eu concorde na maior parte, os widgets Flutter são de nível tão alto que eu vi muitas pessoas fazerem visualizações inteiras em um único widget porque ... níveis de widgets. O que você perde no processo é que você obtém esse código aninhado horrível que dartfmt esmaga em algo irreconhecível. Então eu entendo porque as pessoas fazem isso, entendo que existe uma solução, mas também entendo porque as pessoas não usam a solução.

O JSX surge porque o React é, em sua essência, uma mistura de Javascript e HTML. A sintaxe XML com interpolação/injeção Javascript cria naturalmente o JSX.

Como você explica o fato de o React Native usar JSX e não ter nada a ver com HTML?

Como você explica o fato de o React Native usar JSX e não ter nada a ver com HTML?

Porque ele usa React. Eles provavelmente não queriam reinventar a sintaxe

Porque ele usa React. Eles provavelmente não queriam reinventar a sintaxe

Então JSX não é realmente a mistura de Javascript e HTML como @lukepighetti afirma, mas é um XML-like syntax extension to ECMAScript without any defined semantics... who's purpose is to define a concise and familiar syntax for defining tree structures with attributes.
Está tudo explicado na especificação: https://facebook.github.io/jsx/

Pelo que entendi, o React foi lançado pela primeira vez como react + react-dom com um compilador jsx , então a combinação HTML + JavaScript era natural. Depois disso, react foi usado para direcionar outros renderizadores como react-native , react-vr , react-pdf , etc. razoável e sensível à história e pedigree do React. A especificação de 2019 é a especificação de 2019 e não aborda o histórico do React.

eu concordo

Mas para mim há um problema maior. Vue e React funcionam de forma semelhante nesse aspecto.
React tem uma função createElement e Vue tem uma função h .

Nunca estamos instanciando manualmente componentes em React e Vue. É a estrutura que cuida disso.

Flutter se comporta de maneira diferente. Estamos manipulando diretamente a instância de um Widget.

Como tal, no mundo Flutter, um <Foo /> significa apenas new Foo()

Mas nesse caso, o JSX é totalmente alheio aos Widgets. Estamos apenas mudando a sintaxe de como instanciamos classes no dart.

Para mim, parece que estamos perdendo o significado do que é criar um widget.

@lukepighetti
react-pdf não é outro renderizador de reação, você deve estar pensando em react-canvas .
Então react != react-dom != react-native . O pacote react é responsável por gerenciar hierarquias de componentes com a ajuda de JSX então react não se importa se está gerando react-dom , react-native , react-canvas , então react não é realmente sobre HTML.

A especificação de 2019 é a especificação de 2019 e não aborda o histórico do React.

Não existe a especificação de 2019 do JSX. Existe apenas uma versão do JSX e é a original publicada em 2014 a partir do link que forneci (https://facebook.github.io/jsx/).

@rrousselGit

Estamos apenas mudando a sintaxe de como instanciamos classes no dart.

Para o caso do DSX com Flutter, é exatamente isso que o transpilador está fazendo.

Para mim, parece que estamos perdendo o significado do que é criar um widget.

Como você pode perder algo se nada for removido, você está apenas ganhando outra maneira de fazer algo (que tem vantagens e desvantagens) e agora você tem liberdade de escolha, escolha a que melhor lhe convier.

Oi, eu acredito que você pode ter um mal-entendido da minha mensagem. react direciona outros renderizadores de reação, como react-dom , react-native , react-pdf , react-vr , etc. Afaik, react e react-dom foram lançados simultaneamente, então a herança de jsx é, na minha opinião, bastante clara. Espero que você não esteja explorando minha mensagem porque temos opiniões diferentes sobre o valor do JSX no contexto do Flutter. Provavelmente seria melhor mantê-lo no tópico e não dividir os cabelos.

Oi lukepighetti , você usou react native com JSX por um a dois meses? Se sim, você deve entender por que construir um aplicativo com JSX E reagir nativo (ou reagir, eu sei que são diferentes) o estilo de estrutura é simples e bem estruturado.
No entanto, se você não tiver usado por um período de tempo, nunca poderá entender por que o JSX é tão útil e importante.

Ainda espero que o Google possa entender a beleza do JSX, e como tivemos muitas pessoas apoiando isso. A equipe do Google pode um dia pensar em DSX ou JSX para um framework inspirado em React, flutter.

Oi lukepighetti , você usou react native com JSX por um a dois meses? Se sim, você deve entender por que construir um aplicativo com JSX E React nativo (ou React, eu sei que eles são diferentes) é simples e bem estruturado.

Não posso falar por lukepighetti, mas trabalho profissionalmente com React há dois anos, agora fazendo alguns Vue. Então, eu sou bastante versado quando se trata de JSX.

Da mesma forma, também uso o Flutter há cerca de 2 anos. No começo, também pensei que o Flutter precisava de algum tipo de JSX.
Mas o Flutter melhorou bastante nesse período, e eu mudei de ideia.

• JSX é horrível para escrever à mão. Requer muitas ferramentas para torná-lo suportável, incluindo tags de fechamento automático, tags de renomeação automática e emmet. E mesmo assim não é tão simples quanto a sintaxe do Flutter.

Por exemplo, refatorar Foo() para Foo(child: Bar()) é fácil.
Mas refatorar <Foo /> para <Foo><Bar /></Foo> não é.

• O Flutter oferece muitas opções de refatoração que tornam a manipulação de parênteses ainda mais fácil

• As tags de fechamento virtuais que o Flutter oferece compensam a falta de tags de finalização.
  _Mas eles não aparecem nas revisões de código!_
  Eles realmente fazem! Você pode fazer suas revisões de código do seu IDE. Consulte https://code.visualstudio.com/blogs/2018/09/10/introducing-github-pullrequests

  • JSX não traduz bem para o modelo Flutter.

E se um widget receber child e children ? Obtemos:

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

?

Nesse caso, significa que, para fins de consistência, child deve sempre ser tratado como um argumento nomeado em vez de usar o slot children .

O problema é que muito poucos widgets levam children . A grande maioria é um único child , ou uma combinação de parâmetros nomeados personalizados (como Scaffold ).

O que significa que a grande maioria dos widgets usando JSX será semelhante a:

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

O que é _pior_ então:

Container(
  child: Bar(),
)

Tudo resumido, acho que Flutter está bem. E mesmo que o JSX estivesse disponível, duvido que realmente melhorasse as coisas.

Como eu disse upthread, acho que há muita confusão entre o que são realmente JS/ECMAScript/recursos gerais da Web (disseminação de objetos, desestruturação, intercambialidade de objetos/hashmaps, todos os nós DOM* tendo uma interface altamente semelhante, a flexibilidade do HTML em geral, etc) com quais são os recursos JSX. O antigo IMO é o que torna o JSX agradável de escrever. Sem eles, você está apenas escrevendo XML, e a maioria das pessoas que conheço que realmente têm uma escolha não gosta de escrever XML.

*Vale a pena notar que isso acima de tudo é minha maior oposição a tentar adaptar o Flutter ao XML. Eu não acho que haja algum ponto real tentando negar que o JSX/React tem raízes profundas na web, e os elementos DOM têm um padrão de longa data de cada nó com _attributes_ e _children_. Por outro lado, o Flutter não vincula os desenvolvedores para nomear o slot de um widget personalizado para outros widgets children ou mesmo child e não vejo nenhuma razão pela qual ele deveria começar a fazer isso.

Eu posso ver por que o outro thread JSX foi bloqueado. Eu não deveria ter que defender minhas habilidades/experiência nos comentários do GitHub para explicar por que acho que o JSX não beneficia o Flutter. Eu poderia facilmente dizer "Você não tem experiência suficiente com o Flutter para ter alguma opinião sobre o Flutter". Não se sente bem, não é. Vocês gostam da sua tribo de guerreiros de teclado.

E se um widget receber child e children ? Obtemos:

Por que um widget precisa ter child e children ? É isso ou aquilo。
Outro tópico，alguns widgets do Flutter usam children , e os outros usam child , ninguém acha complicado e fácil de confundir？ children contém child , então não não importa quantos child você tenha, um ou mais de um, basta usar children para fazer o trabalho.

@rrousselGit

JSX é horrível para escrever à mão. Requer muitas ferramentas para torná-lo suportável,

Não apenas todo o mundo React discorda de você, mas também todo o mundo HTML e XML.

O Flutter oferece muitas opções de refatoração que tornam a manipulação de parênteses ainda mais fácil

Então você está dizendo que o Flutter 'requer muitas ferramentas' também, mas como você é tendencioso, sente a necessidade de destruir o outro lado. FYI: melhor coisa a fazer é aceitar que há mais de uma maneira de fazer algo e que algumas pessoas vão preferir a outra maneira de fazê-lo.

Eles realmente fazem! Você pode fazer suas revisões de código do seu IDE.

Isso não resolve o problema de todas as outras ferramentas de revisão de código online usadas pelas equipes. Essas ferramentas manipulam o código-fonte e se não estiver no código-fonte, não existe.

JSX não traduz bem para o modelo Flutter.

Essa é apenas sua opinião ruim, qualquer um pode ver que o DSX adiciona aprimoramentos ao JSX que se encaixam perfeitamente no Flutter.
https://spark-heroku-dsx.herokuapp.com/index.html

Então você está dizendo que o Flutter 'requer muitas ferramentas'

Não, eu disse "ainda mais fácil" e não "suportável".

Acontece que eu respondo ao StackOverflow/Slack com frequência e às vezes até do meu telefone.
E eu claramente tenho um mau momento ao responder a perguntas relacionadas a html - mas o Flutter está bem.

a melhor coisa a fazer é aceitar que há mais de uma maneira de fazer algo e que algumas pessoas vão preferir a outra maneira de fazê-lo.

Isso funciona ao contrário. Você deve ver isso claramente, a comunidade não é 100% fã de JSX. O número de votos negativos nesta questão e na anterior prova isso.

Essa é apenas sua opinião ruim, qualquer um pode ver que o DSX adiciona aprimoramentos ao JSX que se encaixam perfeitamente no Flutter.

Discordo. A sintaxe contém muitos caracteres complexos que em muitos layouts de teclado são difíceis de acessar.
Ele contém toneladas de repetição também.

De qualquer forma, não entendo por que você é permanentemente tão agressivo. Estamos todos tentando melhorar o Flutter.
Não adianta ser duro e fechar essa discussão novamente .

Se o JSX não funcionar bem no flutter, posso aceitar não ingressar no JSX, mas devemos considerar o inferno aninhado.

Outra história paralela é o ponto e vírgula da linguagem de dardos. É realmente irritante.

Outra história paralela é o ponto e vírgula da linguagem de dardos. É realmente irritante.

Há uma solicitação para isso em dart-lang/language: https://github.com/dart-lang/language/issues/69
Vai dar um 👍

Esta longa discussão é sobre poder usar isso:

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

Em vez disso:

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

Mesmo que se concorde com a sintaxe anterior ser superior, algo que eu pessoalmente não faço, isso vem com custos de manutenção contínuos, maior complexidade e novas fontes de erros possíveis, não apenas na linguagem / framework, mas também nas ferramentas circundantes, como IDEs, depurador, linter, etc. Também aumenta os tempos de compilação. E isso exige que os desenvolvedores aprendam uma nova sintaxe e se ocupem com as partes internas do transpilador, para entender quando e como as instâncias estão sendo criadas. Tudo isso praticamente com o único objetivo de React & co. desenvolvedores se sentindo em casa.

Antes de começar com novas linguagens, prefiro me concentrar em melhorar o Dart, que está longe de ser o ideal, faltando recursos importantes como correspondência de padrões , classes de dados , ADTs , desestruturação , opcionais adequados , etc. Alguns desses PRs já estão abertos 5+ anos. Isso, ao contrário de adicionar uma camada de marcação cosmética e desnecessária para criar widgets, tem um enorme impacto na arquitetura, segurança e qualidade geral do código.

Mesmo que isso seja relegado a "orientado pela comunidade", ainda é tempo que a comunidade pode gastar trabalhando em algo significativo. Mas é claro que cada um pode fazer com seu tempo o que quiser. Apenas pare de colocar essa quantidade desproporcional de pressão na equipe Flutter, por favor.

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

Olá, i-Schuetz.
há uma seção de resposta.

Isto é o que tenho dito neste longo post. JSX corrigiu o "problema de espaguete de HTML e XML" (código de interface do usuário ilegível e complicado). Na minha opinião pessoal, depois de usar o flutter, é mais complicado que o JSX ou pior.

Nesses anos, tenho visto pessoas dizendo que o Flutter não consegue capturar algumas das vantagens do React, por exemplo, a verdadeira ideia de tudo são componentes.

Não tenho certeza se sigo. No texto que você destacou, o usuário está dizendo que achou JSX mais fácil de aprender porque estava familiarizado com HTML e tem uma sintaxe semelhante. Não vejo como isso justifica a existência do JSX e muito menos uma imitação do Flutter de alguma forma.

Não adicionei as respostas às capturas de tela simplesmente porque as imagens ocupariam muito espaço. Eles pareciam bastante favoráveis ​​ao que eu postei, então também redundantes. Eu postei links.

@JonathanSum é Flutter mais complicado que JSX, ou Flutter é diferente de _React_ e isso está causando atrito em você? É mais detalhado em alguns casos, sim, e muito menos legível sem tags de fechamento virtuais em um IDE, mas não tenho certeza de como usar construtores é mais _complicado_ do que escrever um DSL semelhante a XML e ainda não tenho certeza por que tantas pessoas parecem pensar que o DSL tipo XML seria uma bala de prata que tornaria o uso do Flutter mais fácil de _entender_. Especialmente considerando que o Flutter não tem histórico anterior com os problemas que o React/JSX foi criado para resolver - o React torna a manipulação do DOM mais fácil e limpa, e isso é legal, mas o que exatamente isso tem a ver com o Flutter novamente?

Nesses anos, tenho visto pessoas dizendo que o Flutter não consegue capturar algumas das vantagens do React, por exemplo, a verdadeira ideia de tudo são componentes.

Sem tocar na noção de que o React tem alguma ideia "verdadeira" de que tudo são componentes que o Flutter não tem, também existem algumas vantagens do design do Flutter/Dart que o React/JS não pode capturar. E você pode dizer o mesmo (e vice-versa) para os SDKs/frameworks/bibliotecas de interface do usuário mais decentes. Incrivelmente, projetos diferentes são de fato diferentes; talvez as pessoas que vêm para um projeto possam ser mais bem atendidas se não começarem esperando que seja [inserir projeto que usaram no passado]. 🙂

Existem algumas ideias interessantes por aí https://github.com/munificent/ui-as-code

Provavelmente seria uma mudança bastante inovadora, mas a proposta de liberdade de parâmetros me fez pensar o quanto os métodos de construção mais concisos poderiam ser se o Dart tivesse, por exemplo , os argumentos de método do Crystal spec .

Claro que o compilador do Crystal viria por último em uma corrida contra uma lesma e uma tartaruga, então é isso 😅

Agora eu concordo em não adicionar JSX e não colocar pressão extra no flutter.

Mas no que diz respeito ao dart, é muito menos elegante que JS ou TS. Me sinto desamparado

Por exemplo, a rota de desenvolvimento da tecnologia de interface do usuário da Microsoft é do WinForm para o WPF，e agora no Flutter，abandone o WPF e use o WinForm。Em resposta às reclamações do desenvolvedor, a equipe do Flutter trabalhou duro para implementar a janela visual e o editor de propriedades do WinForm。

Como um novato em flutter, devo dizer que isso deveria estar no roteiro. Se não jsx, uma maneira mais legível de estabelecer widgets.

Eu posso ver uma função de renderização de classe de reação e uma imagem da classe renderizada e associar no momento.

Posso ver um arquivo de dardo e o conteúdo renderizado e levarei de 5 a 6 minutos para descobrir como funciona ...

Eu posso fazer uma classe react semi-complexa em 5 minutos em um editor de texto simples, porque é intuitivo

Eu não posso fazer isso em vibração. Sem autocompletar, terminei como desenvolvedor. Eu não gosto de ser dependente de uma extensão para desenvolver algo -.-

No entanto. Vai ser interessante como os desenvolvedores de dardos lidam com esse "problema". No dardo 2 eles tornaram mais legível. Eu não sei como eles vão melhorar a legibilidade no dardo 3 -4 -5 . mas acho que uma refatoração da função de construção de componentes será necessária mais cedo ou mais tarde.

EDITAR:
Não importa, apenas tentei React Native novamente, e eu odiava jsx, o sistema de adereços, o fato de que tudo era dinâmico era um conceito realmente assustador novamente, eu acho que é apenas uma opinião pessoal então. Deixe a vibração como está....

Eles solicitaram DSX, não apenas porque amam JSX. Eles querem Flutter.

A declaração da interface do usuário deve ser visualmente separada no código para melhor legibilidade e suporte do código. Especialmente em grandes equipes com muitos juniores/médios. Vindo do Adobe Flex, posso dizer que ler as declarações da interface do usuário do Flutter reduz muito a produtividade.
Se não DSX (o que seria incrível IMO), mas algo deve ser feito com a situação atual, pelo menos no nível do IDE.
Todos os antigos frameworks de desenvolvimento de UI tinham esse recurso e devemos tê-lo também.

A declaração da interface do usuário deve ser visualmente separada no código para melhor legibilidade e suporte do código.

e para uma melhor integração com outras ferramentas como 'construtores de gui', por exemplo.

Vindo do Adobe Flex, posso dizer que ler as declarações da interface do usuário do Flutter reduz muito a produtividade.

Imagine uma declaração de interface do usuário como MXML com poder Flutters! Eu só posso sonhar!

Agora que temos suporte a codegen, a melhor maneira de colocar algo assim no produto é criar um pacote que o habilite e mostre que é extremamente popular.

@Hixie existe algum ponteiro para doc para codegen?

Agora que temos suporte a codegen, a melhor maneira de colocar algo assim no produto é criar um pacote que o habilite e mostre que é extremamente popular.

Parece-me que codegen é apenas para .dart -> .dart, o arquivo de entrada deve ser um arquivo .dart válido. Isso não é muito útil para arquivos .dsx, pois é um superconjunto de dardos. Ainda preciso de suporte para compilação cruzada em .dart com mapas de origem, como recursos para depuração, etc.

Por favor, dê uma olhada no SwiftUI, que foi lançado ontem. Este parece ser o objetivo do Flutter, em vez da marcação do tipo React.

As expressões implícitas de membro de Swift sozinhas seriam tão incríveis

Estou confuso sobre a sintaxe SwiftUI. É leve, com certeza, mas alguns aspectos parecem mágicos.

Mas tecnicamente já podemos ter algo relativamente semelhante:

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

Esse é um código de dardo válido, onde Column é _still_ uma classe.

Aqui está um widget sem estado mostrando isso:

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

  final List<Widget> children;

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

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

É clichê, mas um gerador de código pode ajudar – especialmente com os próximos membros da extensão.

O único problema sobre essa abordagem é que estamos perdendo construtores const (já que ela usa uma função para especificar filhos) e instanciamos a classe de widget _duas vezes_.

Se essa sintaxe for desejada, idealmente em vez de um método call , ela deve ser implementada usando o construtor currying.

@rrousselGit Estou curioso sobre quais aspectos do SwiftUI parecem mágicos para você - parece uma extensão bastante direta da sintaxe do Swift para mim.

Em seu exemplo de código daqui :

• Content é mutável? Isso significa que eles têm uma loja Mobx / Vue integrada?
• O que é isso @State ?
• Por que body é uma variável? Isso é um pegador? Se sim, quando o getter é chamado novamente?
• body faz parte de uma interface ou muitas variáveis ​​semelhantes dentro Content ?
• O que isso item in _exatamente_ faz? Por que o operando certo de in não é algo iterável, mas o "resultado"?
• Por que o Image está alinhado à esquerda do título/subtítulo quando não há HStack ?

Não me lembro ao certo, mas tenho certeza de que não tive essas perguntas ao pegar o Flutter.

@rrousselGit Isso pode ser por causa do seu histórico, não porque a sintaxe ou semântica do Flutter é inerentemente óbvia (conheci muitas pessoas que ficaram bastante perplexas com isso). E os pontos que você levantou parecem ser uma junção estranha de superanalisar um trecho de código de 14 linhas para falhas, sem realmente conhecer o idioma em que está escrito.

• Não é realmente mutável (no sentido de Dart ou JS) embora? É uma estrutura. Além disso, as lojas no estilo MobX/Vue (ou seja, cobrindo suporte a idiomas bastante limitado) não são a única maneira de lidar com a mutabilidade

• @State é um atributo, também conhecido como anotação em algumas linguagens (por exemplo, Dart), também conhecido como algo muito comum no código Swift. Se você quer dizer o que significa, mesmo sem olhar para os documentos, provavelmente marca uma propriedade como estado que mudará com o tempo.

• body é uma propriedade computada, que é facilmente percebida pelos desenvolvedores do Swift. Quanto a quando é recalculado, Widget build(BuildContext context) também lhe diz inerentemente quando é chamado novamente?

• Content (novamente claramente para desenvolvedores Swift) estende/implementa View , que é onde você procuraria respostas para sua pergunta (na verdade, ele tem uma página de referência de API muito boa).

• Isso é praticamente "por que a palavra-chave neste idioma não é a mesma coisa que a palavra-chave no idioma que eu uso", não é nada particularmente "mágico". A palavra-chave in aqui não é a mesma coisa que uma construção for...in - ela indica que o corpo de um encerramento está prestes a começar. { item in ... } é um bloco de função passado para o construtor List ; ListView de itemBuilder , se você quiser.

• Você está legitimamente perguntando por que uma visão tem suas próprias regras de layout encapsuladas?

No SwiftUI:

1-Bom ver o estado declarado na View e não como um apêndice lateral.

2-Nice métodos individuais para definir as coisas em vez de ter que passar tudo no construtor (métodos permitem que as ações tenham efeito em vez de apenas dados serem passados).

3-Muito bom ver gráficos vetoriais declarativos misturados com tudo o que é declarativo (como sugeri no passado com SVG declarativo como widgets) !!!
https://developer.apple.com/tutorials/swiftui/drawing-paths-and-shapes

4-construções de animação e transição muito simples
https://developer.apple.com/tutorials/swiftui/animating-views-and-transitions

Ferramentas de design 5-Drag&Drop em sincronia com o editor de código nos dois sentidos.

Existem verrugas como todo o resto, mas eu prefiro focar no que eles fizeram muito bem.

Essas "perguntas" existem apenas para mostrar pontos potencialmente confusos. Estas não são _perguntas reais_.

Isso pode ser por causa do seu background

Provável. Não estou dizendo que a abordagem deles é ruim ou algo assim. Estou dizendo que não me pareceu natural como foi com Flutter.
Os widgets Flutter quase não usam "recurso de idioma sofisticado" e podem ser implementados em praticamente qualquer idioma (embora o recente if/for for collections mude isso).
Enquanto a vitrine do SwiftUI usa amplamente recursos específicos do Swift.

Quanto a quando é recalculado, o Widget build (contexto BuildContext) também informa inerentemente quando é chamado novamente?

Meu ponto aqui é a falta de relação entre State e o ato de recalcular body .
React e Flutter são muito explícitos nesse assunto: setState.
Vue/Mobx são "mágicos", usando o mesmo recurso @State .

Está tudo bem, na verdade, mas esse é um padrão diferente.

Você está legitimamente perguntando por que uma visão tem suas próprias regras de layout encapsuladas?

Não, é mais um "explícito" vs "implícito".
Parece que eles realmente se concentraram em "fazer o máximo possível com o mínimo de código possível", mesmo que esconda parte da lógica (nesse caso, a lógica ltr vs rtl )

Flutter pediria para você usar um Row .

O Flutter usa e conta com muitos "recursos de linguagem sofisticados" (leia-se: recursos de linguagem com os quais o falante não está acostumado e / ou não concorda). Apenas no topo da minha cabeça, construtores constantes (e o estilo de Dart de nomear construtores em geral), sobrecarga de operadores, classes sendo interfaces implícitas, @covariant e mixins são recursos que atrairiam reações de confusão a rotulagem direta como um cheiro de código dependendo do histórico de um desenvolvedor. Eu provavelmente poderia fazer uma lista mais longa, pensando em uma hora. E isso não é uma acusação ao Flutter mais do que é uma acusação ao SwiftUI - não vejo por que alguém pensaria que é uma virtude escrever software em um idioma específico para que possa ser escrito da mesma maneira em qualquer idioma - qual é o ponto de línguas diferentes se devemos fingir que as diferenças entre elas não existem?

Além disso, discordo completamente que setState ou @State seja explícito sobre sua relação com o ato de reconstruir uma visão. Em ambos os casos, você é simplesmente informado de que, se alterar algo que foi marcado como estado, a estrutura classificará o que construir. Em ambos os casos, o desenvolvedor ainda não tem controle explícito sobre o que está acontecendo ou quando exatamente. Você acha uma chamada de função mais familiar, as pessoas que trabalham em outras linguagens acham os decoradores mais familiares. Mas chamar uma função não torna as coisas mágicas.

Flutter pediria para você usar um Row

Acho que você nunca usou ListTile , que tem o mesmo comportamento mostrado aqui, mas com parâmetros nomeados? Devemos também perguntar por que um Scaffold "magicamente" coloca um botão de menu à esquerda da sua barra de aplicativos quando você não pediu?

A diferença é que no estado atual do Dart é muito parecido com a maioria das linguagens convencionais.

Isso é importante.
A pergunta "Preciso aprender Dart ou posso começar a aprender Flutter?" surge com bastante frequência.
No momento, a resposta é "apenas aprenda Flutter. Você pode escrever dardo eficaz depois de um único dia".
Isso não é garantido para ficar assim para sempre, mas acho que esse é um dos pontos fortes do Flutter.

O resto da discussão é um pouco off-topic. Se você quiser, podemos continuar essa parte por correio (meu correio do github funciona).

Por que isso não está bloqueado? Isso já está evoluindo mal e é exatamente o mesmo que um problema bloqueado anteriormente.

Fiz um simples aqui:
https://github.com/danialdezfouli/flutterjsx
https://www.npmjs.com/package/flutterjsx
https://www.youtube.com/watch?v=Oj1JMSurphA

Este tópico foi bloqueado automaticamente, pois não houve nenhuma atividade recente depois que ele foi fechado. Se você ainda estiver enfrentando um problema semelhante, abra um novo bug, incluindo a saída de flutter doctor -v e uma reprodução mínima do problema.