Pourquoi JSX est-il bon, alors que les scriptlets JSP sont mauvais?

21

React.js fournit JSX comme une syntaxe de type XHTML pour la construction d'un arbre de composants et d'éléments. JSX compile en Javascript, et au lieu de fournir des boucles ou des conditions dans JSX proprement dit, vous utilisez directement Javascript:

<ul>
  {list.map((item) =>
    <li>{item}</li>
  )}
</ul>

Ce que je n'ai pas encore pu expliquer, c'est pourquoi est-ce considéré comme bon si les constructions analogues sont considérées comme mauvaises dans JSP?

Quelque chose comme ça dans JSP

<ul>
   <% for (item in list) { %>
     <li>${item}</li>
   <% } %>
</ul>

est considéré comme un problème de lisibilité à résoudre avec des balises comme <c:forEach>. Le raisonnement derrière les balises JSTL semble également pouvoir s'appliquer à JSX:

c'est un peu plus facile à lire lorsque vous ne basculez pas entre la syntaxe de type XHTML (crochets, imbrication) et Java / Javascript (curlies, virgules, parens)
lorsque vous avez le langage complet et la plate-forme disponibles pour une utilisation à l'intérieur de la fonction de rendu, il y a moins pour vous décourager de mettre une logique qui n'y appartient pas.

Les seules raisons pour lesquelles je peux penser pourquoi JSX est différent sont:

en Java, vous étiez incité à faire la mauvaise chose - JSP serait rechargé à chaud, il était donc tentant de mettre du code dans les JSP pour éviter un cycle de reconstruction / redémarrage. La maintenabilité a été sacrifiée pour une productivité immédiate. Bannir les scriptlets et se limiter à un ensemble fixe de constructions de modèles était en fait un moyen de renforcer la maintenabilité. Aucune distorsion de ce type n'existe dans le monde JS.
La syntaxe JSP et Java est maladroite avec le supplément <% ... %>pour distinguer le code Java de la génération d'éléments, et avec la syntaxe native de Java dépourvue de foreachconcept ou de fonctions de première classe (jusqu'à récemment). La pénalité syntaxique de l'utilisation de Javascript natif pour les boucles et les conditions dans JSX est non nulle (à mon avis) mais pas aussi mauvaise que JSP, et sans doute pas assez mauvaise pour justifier l'introduction d'éléments spécifiques à JSX pour les boucles et les conditions.

Y a-t-il autre chose qui me manque?

— wrschneider
source

1

Je ne pense pas que ce soit mauvais d'avoir des boucles dans votre JSP en soi, le problème est d'incorporer du code dans les balises de scriptlet. Si vous les bannissez et utilisez JSTL, vous serez alors obligé de simplifier vos JSP. En outre, comme vous le faites remarquer, un bonus supplémentaire est que la syntaxe JSTL est un peu moins discordante que la syntaxe du scriptlet. Bien que je ne sois pas familier avec JSX, je suppose que vous pourriez probablement abuser des fragments JSX avec beaucoup de logique alambiquée qui ne serait pas recommandée mais qu'elle n'empêchera pas.

— PhilDin

11

Principalement, les personnes qui ont créé JSX n'étaient pas d'accord avec les personnes qui n'aimaient pas JSP. Voir leur discussion ici: Pourquoi avons-nous construit React? ainsi que l' affichage des données

Les modèles sont basés sur l'idée de créer une division entre la logique et la présentation d'une page. Dans cette théorie, votre code javascript (ou java) ne devrait pas être concerné par le balisage affiché, et votre balisage ne devrait pas être concerné par la logique impliquée. Cette division est essentiellement la raison pour laquelle les gens critiquent les différents langages de modèles qui permettaient facilement de mélanger du code avec votre modèle (PHP / JSP / ASP).

React est basé sur des composants. Les auteurs de react soutiennent que la logique et la présentation d'un composant sont étroitement liées, et tenter de les diviser n'a aucun sens. Au lieu de cela, une page doit être brisée par des éléments logiques. Vous pouvez donc décomposer la barre d'en-tête, les commentaires, les articles, les questions connexes, etc. en composants séparés. Mais cela n'a pas de sens d'essayer de séparer la logique des questions connexes de la présentation.

La principale différence entre quelque chose comme JSX et quelque chose comme JSP est que JSP est un langage de modèle qui inclut un peu de java pour la logique. JSX est javascript avec une extension de syntaxe pour faciliter la construction de fragments de code html. L'accent est différent. Étant donné que JSX adopte cette approche, il finit par produire une approche plus agréable et plus propre, puis effectuée par JSP ou des amis.

Mais finalement, cela revient au fait que les personnes qui ont réagi n'aimaient pas les modèles. Ils pensent que c'est une mauvaise idée et que vous devriez mettre votre logique de balisage et de présentation au même endroit.

— Winston Ewert
source

Je ne me plains pas d'encapsuler la renderfonction au même endroit que la logique des autres composants. Je suis strictement préoccupé par la lisibilité du mélange de la génération d'éléments avec d'autres types de code.

— wrschneider

@wrschneider, en quoi une renderfonction de réaction est-elle différente dans les types de code mélangés par rapport à votre langage de modèle typique?

— Winston Ewert

3

En tant qu'étranger de React, je considérais JSX comme une autre "odeur de cadre" dans le zoo très encombré de puanteurs du cadre. Je ne suis toujours pas convaincu que ce ne soit pas le cas.

Je pense qu'une définition pratique de "utile" est qu'une bibliothèque / framework / pattern résout plus de problèmes qu'elle n'en provoque. Je ne suis pas encore convaincu que JSX corresponde à cette définition. C'est le proverbial "presser le ballon" ... vous écrasez un problème ici, il apparaît là-bas. Pour moi, JSX ne résout aucun problème particulier ... il est juste "différent".

La notion d'introduction d'une sémantique compilable qui nécessite un processus de construction formalisé est utile dans certaines circonstances: par exemple, la compilation MOINS de fichiers .css fournit une structure très nécessaire autour de css, qui est une structure hiérarchique avec des importations et des remplacements, donc étant très enclin aux «solutions de spaghetti». Mais les pré-compilateurs Javascript ... pas tellement.

— dwoz
source

"Une définition pratique de l'utile est ..." c'est un grand point. Et oui, JSX résout plus de problèmes que nous ne le pensons. Le composant React View est plus simple et expressif avec JSX. elle peut être testée à l'unité avec un rendu peu profond. Si vous dites que JSP a une odeur, il peut sentir et il a plus de chances d'erreurs. Et je ne suis pas agnest jsp.

— Sagar

Désolé, mais je ne vois pas comment cela répond à la question.

— sleske

Sleske, les adeptes de la critique littéraire l'appelleraient une "lecture intérieure" de la question. La question à la surface demande une comparaison, mais à l'intérieur, elle concerne les cadres. Ma réponse porte sur le concept de «cadres résolvant plus de problèmes qu'ils n'en causent». Le PO pourrait alors prendre mon commentaire, appliquer ce credo à sa situation particulière et unique, et décider si JSX est une aide ou un obstacle. On pourrait dire que votre déclaration soulève la question de savoir s'il y a une lacune dans la réponse ou une lacune dans votre compréhension, car l'un ou l'autre problème pourrait entraîner votre résultat exact

— dwoz

1

En bref:

Les développeurs frontaux devraient connaître les scripts et les modèles
JSX et JSP sont tous deux des langages de modèles
JavaScript est un langage de script
Java n'est pas un langage de script

Les références

— Paul Sweatte
source

0

Bien que je n'utilise pas JSX, d'après votre description, le travail du fragment JSX consiste à présenter les données, c'est-à-dire qu'il s'agit d'un composant d'affichage dans le langage MVC. Le fragment JSX ne sait probablement pas ou ne se soucie pas d'où proviennent les données, ce que vous voulez.

Une page JSP bien structurée ne contiendra que des directives JSTL comme vous le mentionnez. Les directives JSTL simplifient simplement vos JSP afin qu'elles ne soient pas encombrées lors de la récupération de la portée, de la vérification de la valeur null, etc.

Tout comme le fragment JSX; le seul travail du JSP devrait être de comprendre comment présenter les données qu'il a reçues sans se soucier de leur origine.

En résumé, que votre vue soit JSX ou JSP, si vous le faites correctement, votre vue ne présentera que des données.

Quant à savoir pourquoi vous pouvez déplacer la présentation vers le client au lieu de le faire sur le serveur, cela vous donne plus de flexibilité. Votre site Web peut obtenir ses données via des services Web (ReST par exemple) et être simplement un autre client. Si vous décidez plus tard que vous souhaitez une application Android ou iOS native, ils peuvent consommer le même ensemble de services Web que votre site Web.

— PhilDin
source

Notez que JSX peut être utilisé côté client ou côté serveur. La meilleure façon d'utiliser JSX consiste à restituer les contrôles initiaux sur le serveur, puis à effectuer des mises à jour DOM (en réponse aux appels de service) côté client. Quoi qu'il en soit, vous avez raison de dire que React est la couche d'affichage ( citant Facebook : "Beaucoup de gens utilisent React comme V dans MVC").

— Brian

La question spécifique est pourquoi React / JSX considère que c'est une bonne chose d'utiliser la syntaxe Javascript native pour les boucles / conditions alors que JSP a éliminé la syntaxe Java native (scriptlets).

— wrschneider

Désolé, j'ai raté ce point. J'ai commencé à composer une réponse mais j'ai réalisé que c'était simplement un cas de "votre supposition est aussi bonne que la mienne". Une belle syntaxe de couche de présentation pour JSX pourrait être utile, je peux seulement supposer que c'était important pour les concepteurs Java et non pour les concepteurs JSX.

— PhilDin