React: idée: prise en charge de la valeur abrégée de la propriété littérale de l'objet dans la syntaxe jsx

J'ai tendance à dire non. Nous avons beaucoup parlé de l'utilisation de différentes syntaxes et nous essayons de la garder aussi minimale que possible. Ajouter le {...spread} était déjà un gros problème.

cc @sebmarkbage

Nous essayons de maintenir les discussions sur la syntaxe dans : https://github.com/facebook/jsx De cette façon, nous pouvons avoir un groupe plus large contribuant à cette syntaxe pour que cela en vaille la peine pour le langage.

Je pense que la différence entre <Foo {item} /> , <Foo {...item} /> et <Foo item /> peut être trop déroutante. Les deux derniers sont déjà pris en charge.

J'aime bien ta façon de penser. Si vous vous sentez fortement à ce sujet, vous devriez ouvrir un problème à https://github.com/facebook/jsx

https://github.com/facebook/jsx/pull/118

^ Une proposition pour la syntaxe d'expression d'objet comme discuté ici.

Je pense que la différence entre , et peut être trop déroutant.

La confusion est peut-être relative. <Foo item /> n'est pas très utile car il est toujours évalué à {item : true}. Avec le recul, cela semble très limité, mais je peux comprendre son comportement à partir de ses gènes html. Personnellement, je ne lui ai pas trouvé beaucoup d'utilité.

et ne sont pas déroutants si vous le regardez du point de vue de la notation d'objet ES8. {item} est un raccourci pour {item: item} . {...item} est un raccourci pour aplatir/copier/étaler dans un nouvel objet.

une fois que quelqu'un comprend que jsx se transpile en h(name: string | Component, props: {[name]: any}, ...children) . ObjectExpression tombe naturellement.

Il est déroutant que <Foo {x} /> ne soit pas pris en charge, mais que <Foo {...x} /> soit pris en charge. La solution de contournement est
<Foo {...{x}} /> ce qui est beaucoup plus déroutant.