web-dev-qa-db-ja.com

JSPスクリプトレットが悪いのにJSXが良いのはなぜですか？

React.jsは、コンポーネントと要素のツリーを構築するためのXHTMLのような構文としてJSXを提供します。 JSXはJavascriptにコンパイルされ、JSX本体でループや条件を提供する代わりに、Javascriptを直接使用します。

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

私がまだ説明できなかったことは、JSPで類似の構成が悪いと考えられているのに、なぜこれが良いと考えられるのですか？

JSPでこのようなもの

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

_<c:forEach>_のようなタグで解決できる可読性の問題と見なされます。 JSTLタグの背後にある理由は、JSXにも当てはまるようです。

  • xHTMLのような構文（山かっこ、入れ子）とJava/Javascript（中かっこ、コンマ、括弧）を切り替えない場合は、少し読みやすくなります。
  • レンダリング関数内で使用できる完全な言語とプラットフォームがある場合、そこに属していないロジックを配置することを思いとどまらせることは少なくなります。

JSXが異なる理由を私が考えることができる唯一の理由は次のとおりです。

  • javaでは、間違ったことをするインセンティブがありました。JSPはホットリロードされるため、再構築/再起動のサイクルを回避するために、JSPにコードを配置したくなりました。保守性は、即時の生産性のために犠牲にされました。スクリプトレットを追放し、テンプレート構成の固定セットに制限することは、実質的に保守性を強化する方法でした。 JSの世界にはそのような歪みはありません。

  • JSPとJava構文は、Javaコードを要素の生成と区別するために余分な_<% ... %>_を使用し、Javaのネイティブ構文ではforeachコンセプトまたはファーストクラスの関数（最近まで）。JSXでループと条件付きのネイティブJavascriptを使用する構文ペナルティはゼロではありませんが（私の意見では）、JSPほど悪くはなく、間違いなく正当化するには十分ではありません。ループと条件のJSX固有の要素の紹介。

他に何か不足していますか？

javascriptreadabilityjspreactjs
22
wrschneider

主に、JSXを作成した人々は、JSPを嫌う人々と意見の相違がありました。こちらのディスカッションをご覧ください： なぜReactを作成したのですか？ および データの表示

テンプレートは、ページのロジックとプレゼンテーションの間に分割を作成するという考えに基づいています。この理論では、JavaScript（またはJava）コードは表示されるマークアップに関係するべきではなく、マークアップは関連するロジックのいずれにも関係するべきではありません。この分割は、基本的に、コードをテンプレート（PHP/JSP/ASP）に簡単に混在させることができるさまざまなテンプレート言語を批判する理由です。

Reactはコンポーネントに基づいています。 reactの作者は、コンポーネントのロジックとプレゼンテーションは密接に関連しており、それらを分割しようとしても意味がないと主張しています。代わりに、ページは論理的な断片によって分割されるべきです。したがって、ヘッダーバー、コメント、投稿、関連する質問などを別々のコンポーネントに分割することができます。しかし、プレゼンテーションから関連する質問のロジックを分割して試しても意味がありません。

JSXのようなものとJSPのようなものの主な違いは、JSPがJavaのロジックを含む）テンプレート言語であることです。 JSXはこのアプローチを採用しているため、JSPや友人が実行するより優れた、よりクリーンなアプローチを生成することになります。

しかし、結局のところ、反応した人々はテンプレートを好まなかったという事実に帰着します。彼らはそれらが悪い考えであり、あなたはあなたのマークアップとプレゼンテーションロジックを同じ場所に置くべきだと思っています。

11
Winston Ewert

Reactの部外者として、私はJSXを、非常に混雑したフレームワークの動物園の悪臭のなかでさらに別の「フレームワークのにおい」であると見なしました。私はこれがそうではないことをまだ確信していません。

「有用な」の実用的な定義は、ライブラリー/フレームワーク/パターンが原因よりも多くの問題を解決することです。JSXがその定義に適合しているとはまだ確信していません。それはことわざの「風船を絞る」です...あなたはここで問題をつぶします、それはあそこに飛び出します。私にとって、JSXは特定の問題を解決していません...それは単に「異なる」だけです。

形式化されたビルドプロセスを必要とするコンパイル可能なセマンティクスを導入するという概念は、状況によっては役立ちます。たとえば、.cssファイルのLESSコンパイルは、CSSの周りに非常に必要な構造を提供します。 「スパゲッティソリューション」の傾向が非常に強い。しかし、Javascriptプリコンパイラー...それほどではありません。

3
dwoz

要するに：

  • フロントエンドの開発者は、スクリプトとテンプレートについて知っていることが求められます
  • JSXとJSPはどちらもテンプレート言語です
  • JavaScriptはスクリプト言語です
  • Javaはスクリプト言語ではありません

参照

1
Paul Sweatte

私はJSXを使用していませんが、説明に基づいて、JSXフラグメントの役割はデータを表示することです。つまり、MVC用語ではビューコンポーネントです。 JSXフラグメントはおそらく、データがどこから来たのかを知らないか、気にしていません。

よく構造化されたJSPページには、あなたが言及したようにJSTLディレクティブのみが含まれます。 JSTLディレクティブは、JSPを単純化して、スコープからのフェッチ、nullのチェックなどで乱雑にならないようにします。これにより、乱雑さがどれだけ取り除かれ、雑然としないようにすることもできます。

JSXフラグメントと同じです。 JSPの唯一の仕事は、どこから来たのかを気にせずに、受け取ったデータを表示する方法を理解することです。

要約すると、ビューがJSXであるかJSPであるかに関係なく、適切に実行している場合、ビューはデータを表示するだけです。

プレゼンテーションをサーバーではなくクライアントにシフトする理由については、これにより柔軟性が高まります。 WebサイトはWebサービス（ReSTなど）を介してデータを取得し、別のクライアントになることができます。後でネイティブのAndroidまたはiOSアプリが必要になると決めた場合、それらはあなたのWebサイトと同じWebサービスのセットを消費できます。

0
PhilDin