it-swarm.com.de

Warum ist JSX gut, wenn JSP-Scriptlets schlecht sind?

React.js bietet JSX als XHTML-ähnliche Syntax zum Erstellen eines Baums von Komponenten und Elementen. JSX wird in Javascript kompiliert. Anstatt Schleifen oder Bedingungen in JSX bereitzustellen, verwenden Sie Javascript direkt:

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

Was ich noch nicht erklären konnte, ist, warum dies als gut angesehen wird, wenn analoge Konstrukte in JSP als schlecht angesehen werden.

So etwas in JSP

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

wird als Lesbarkeitsproblem angesehen, das mit Tags wie <c:forEach> gelöst werden muss. Die Gründe für JSTL-Tags scheinen auch für JSX zu gelten:

  • es ist etwas einfacher zu lesen, wenn Sie nicht zwischen XHTML-ähnlicher Syntax (spitze Klammern, Verschachtelung) und Java/Javascript (Curlies, Kommas, Parens) wechseln.
  • wenn Sie die vollständige Sprache und Plattform für die Verwendung in der Rendering-Funktion zur Verfügung haben, können Sie weniger davon abhalten, Logik einzufügen, die nicht dorthin gehört.

Die einzigen Gründe, warum ich mir vorstellen kann, warum JSX anders ist, sind:

  • in Java hatten Sie einen Anreiz, das Falsche zu tun - JSP wurde im laufenden Betrieb neu geladen, daher war es verlockend, Code in JSPs einzufügen, um einen Wiederherstellungs-/Neustartzyklus zu vermeiden. Die Wartbarkeit wurde für die sofortige Produktivität geopfert. Das Verbannen von Scriptlets und das Beschränken auf einen festen Satz von Vorlagenkonstrukten war effektiv eine Möglichkeit, die Wartbarkeit zu erzwingen. In der JS-Welt gibt es keine solche Verzerrung.

  • JSP und Java Syntax ist klobig mit dem zusätzlichen <% ... %>, Um Java Code von der Elementgenerierung zu unterscheiden, und mit Javas nativer Syntax fehlt ein foreach -Konzept oder erstklassige Funktionen (bis vor kurzem). Die Syntaxstrafe für die Verwendung von nativem Javascript für Schleifen und Bedingungen in JSX ist (meiner Meinung nach) ungleich Null, aber nicht so schlecht wie bei JSP und wahrscheinlich auch nicht schlecht genug Gewährleistung der Einführung von JSX-spezifischen Elementen für Schleifen und Bedingungen.

Fehlt mir noch etwas?

22
wrschneider

In erster Linie waren die Leute, die JSX erstellt haben, nicht mit den Leuten einverstanden, die JSP nicht mochten. Siehe ihre Diskussion hier: Warum haben wir React erstellt? sowie Anzeigen von Daten

Vorlagen basieren auf der Idee, eine Trennung zwischen Logik und Darstellung einer Seite zu erstellen. Nach dieser Theorie sollte sich Ihr Javascript- (oder Java-) Code nicht mit der Anzeige des Markups befassen, und Ihr Markup sollte sich nicht mit der Logik befassen. Diese Unterteilung ist im Wesentlichen der Grund, warum Leute die verschiedenen Vorlagensprachen kritisieren, die es leicht ermöglichten, Code mit Ihrer Vorlage (PHP/JSP/ASP) zu mischen.

Die Reaktion basiert auf Komponenten. Die Autoren von react argumentieren, dass die Logik und Darstellung einer Komponente eng miteinander verbunden sind und der Versuch, sie zu teilen, keinen Sinn ergibt. Stattdessen sollte eine Seite durch logische Teile unterbrochen werden. Sie können also die Kopfzeile, Kommentare, Beiträge, verwandte Fragen usw. in separate Komponenten aufteilen. Es ist jedoch nicht sinnvoll, die Logik für die zugehörigen Fragen von der Präsentation zu trennen.

Der Hauptunterschied zwischen JSX und JSP besteht darin, dass JSP eine Vorlagensprache ist, die ein bisschen Java für die Logik enthält. JSX ist Javascript mit einer Syntaxerweiterung, um das Erstellen zu vereinfachen HTML-Fragmente. Die Betonung ist unterschiedlich. Da JSX diesen Ansatz unterstützt, führt dies zu einem schöneren, saubereren Ansatz als JSP oder Freunde.

Aber letztendlich kommt es darauf an, dass die Leute, die reagiert haben, keine Vorlagen mochten. Sie halten sie für eine schlechte Idee und sollten Ihre Markup- und Präsentationslogik an derselben Stelle platzieren.

11
Winston Ewert

Als Außenseiter von React betrachtete ich JSX als einen weiteren "Framework-Geruch" in dem überfüllten Zoo von Framework-Gestank. Ich bin immer noch nicht davon überzeugt, dass dies nicht der Fall ist.

Ich denke, eine praktikable Definition von "nützlich" ist, dass eine Bibliothek/ein Framework/ein Muster mehr Probleme löst, als es verursacht. Ich bin noch nicht davon überzeugt, dass JSX zu dieser Definition passt. Es ist das sprichwörtliche "Drücken des Ballons" ... Sie quetschen hier ein Problem, es taucht dort auf. Für mich löst JSX kein bestimmtes Problem ... es ist nur "anders".

Der Gedanke, eine kompilierbare Semantik einzuführen, die einen formalisierten Erstellungsprozess erfordert, ist unter bestimmten Umständen nützlich: Beispielsweise bietet die WENIGER Kompilierung von CSS-Dateien eine dringend benötigte Struktur um CSS, eine hierarchische Struktur mit Importen und Überschreibungen sehr anfällig für "Spaghetti-Lösungen". Aber Javascript-Pre-Compiler ... nicht so sehr.

3
dwoz

Zusamenfassend:

  • Von Front-End-Entwicklern wird erwartet, dass sie sich mit Skripten und Vorlagen auskennen
  • JSX und JSP sind beide Vorlagensprachen
  • JavaScript ist eine Skriptsprache
  • Java ist keine Skriptsprache

Referenzen

1
Paul Sweatte

Obwohl ich JSX nicht verwende, besteht die Aufgabe des JSX-Fragments, basierend auf Ihrer Beschreibung, darin, die Daten darzustellen, dh es ist eine Ansichtskomponente in der MVC-Sprache. Das JSX-Fragment weiß vermutlich nicht, woher die Daten stammen, von denen Sie möchten.

Eine gut strukturierte JSP-Seite enthält nur JSTL-Anweisungen, wie Sie bereits erwähnt haben. JSTL-Direktiven vereinfachen Ihre JSPs nur, damit sie nicht mit dem Abrufen aus dem Gültigkeitsbereich, dem Überprüfen auf Null usw. überladen sind. Es ist überraschend, wie viel Unordnung dies beseitigt, und es ermutigt Sie auch, sie übersichtlich zu halten.

Genau wie das JSX-Fragment; Die einzige Aufgabe der JSP sollte es sein, herauszufinden, wie die empfangenen Daten dargestellt werden können, ohne sich Gedanken darüber zu machen, woher sie stammen.

Zusammenfassend lässt sich sagen, dass Ihre Ansicht nur Daten enthält, unabhängig davon, ob es sich bei Ihrer Ansicht um JSX oder JSP handelt.

Dies gibt Ihnen mehr Flexibilität, wenn Sie die Präsentation auf den Client verschieben, anstatt sie auf dem Server auszuführen. Ihre Website kann ihre Daten über Webdienste (z. B. ReST) abrufen und nur ein weiterer Kunde sein. Wenn Sie später entscheiden, dass Sie eine native Android oder iOS-App) möchten, können diese dieselben Webdienste wie Ihre Website nutzen.

0
PhilDin