私たちはVoximplantのReactを愛し、感謝しています。 誇大広告（React Nativeであるという理由だけで、新しいSDKについての1.5千のツイート）のためではなく、フレームワークが本当に便利だからです。 インターフェースを小さな孤立した部分に単純に分割するだけで、Jade / Pug、Web Components、さらにはAngularには欠けていました。
カットの下には、JetRubyエージェンシーの開発者がReactの印象を共有している記事の適合した翻訳があります：使用したもの、使用しなかったもの、使用する予定のもの。
ReactJSの使用を開始し、関連技術の海を消化してからほぼ1年が経過しました。 そして、私たちはあなたと私たちの経験を共有するためにここにいます。
最近、クライアント側のレンダリングとRails APIサーバーを使用するプロジェクトを完了しました。 全体的な印象は非常にポジティブです。
私たちが好きなもの：
- 良い明確なソース。 Reactの宣言スタイルにより、コードを理解しやすくなり、不要な複雑さを回避できます。 これはUIでの蓄積に努めています。
- サーバーコードとクライアントコードの明示的な区別。 フロントエンド開発者とバックエンド開発者の間でタスクを簡単に共有でき、それらは互いに重複しません。
- Virtual DOMテクノロジーのおかげで、ページの変更は非常に迅速に行われます（ゲームなどの縮退した場合や、インタラクティブなものを除きます）。 しかし、最近、著者がReactが遅いと主張する記事（たとえば、 この記事）に出くわすことが多いことに注意する価値があります。
- APIを開きたい場合は、そのためのSPAアプリケーションを開発することが最良のテストになります。 さらに、バックエンドと対話するコードは、1つまたは複数の個別のモジュールに移動できます。これは、FluxでハードコーディングされたAJAX要求よりもはるかに優れています。 たとえば、設定を操作するモジュールは、アプリケーションがprodで実行されているかステージで実行されているかに応じて、異なる要求を行うことができます。
- 多数の異なるFlux実装。 テクノロジーに遅れないようにしたい場合は良いことです。 何かをすぐにやりたいだけで、何を選ぶべきかわからないのは悪いことです。 一部の実装では複数の「ストーリー」を使用しますが、他の実装ではFRPまたはイベントで1つのグローバルオブジェクトを使用してコンポーネントを調整します。 いつでも好きなものを選択できます。 Fluxxorを選択しましたが、ストアの実装は使用せず、アクションのみを使用します。 状態を操作するには、1つのグローバルオブジェクトを使用するアプローチを選択し、Baobabライブラリを使用します。 外からは再複雑に見えますが、私たちは柔軟性が好きです。
当然、この新しい美しい世界では、すべてが美しいとは限りません。 それにもかかわらず、多くの問題が発生しました。
- よく管理され、すぐに使用できるコンポーネントの欠如。 もちろん、これは鶏と卵の問題です。React自体の人気が高まるにつれて、それらの数は増えていきます。 しかし、私たちは今ここに住んでいます。
- フォームと検証。 彼らは難しいです。 さらに、フォームを作成するための既製の高レベルライブラリはそれほど多くありません。
- このアプリケーションでは、多くのjQueryコードでカスタムテーマを使用しました。 Reactアプリケーションにシームレスに統合するのはそれほど簡単ではないことがわかりました！ 技術的には可能ですが、既製のコンポーネントまたはリソースがゼロからこれを行う場合、これを行うことはお勧めしません。 私たちのケースでは、ブートストラップに日付時刻ピッカーが必要でしたが、良いものが用意されていませんでした（必要な機能がすべて揃っていませんでした）。 そのため、適切なjQueryプラグインをReactコンポーネントとして設計する以外に選択肢はありませんでした。 このトピックに興味がある場合は、 こちらをご覧ください 。
私たちにとって正しいと思われるいくつかの技術的解決策と推奨するもの：
- 片側を使用します。 そして、ここに理由があります。 まず、複数のストアの主な問題は、それらの同期です。 別のストアからのデータが必要な、あるストアからのデータが必要な場合は、 waitFor（）関数を使用して明示的に登録する必要があります。 アプリケーションの成長に伴い、このような関係がますます増え、それらを管理するのが難しくなります。 状態管理に単一のストアを使用すると、このような問題が解決します。 このようなストアの良い候補は、バオバブライブラリの実装です。 フロントエンドに存在する一種のローカルデータベースと考えることができます。
- webpackを使用してモジュールをビルドします。 現在、このアセンブリには多くのソリューションがあります。例えば、browserifyまたはrequirejsとともにgruntまたはgulpがありますが、webpackはもう少し強力です。 ReactコンポーネントにCSS、画像、およびフォントを直接含めると、CSSをより管理しやすくすることができます。
- カーソルを使用して、Reactデータをコンポーネントに渡します。 この強力な抽象化により、中間データをコンポーネントの「チェーン」に転送する必要がなくなり、コードが大幅に簡素化されます。 バオバブのカーソルを使用しましたが、他にも多くの優れた実装があります。 バオバブが選ばれた理由は、 PureRenderMixinをサポートするReactとのシンプルさ、率直さ、既成の統合のためです。
次のアプリケーションで試したいこと：
バベルを使用するBabelは既にJSXでの作業に公式にReactを使用しています。 ただし、JSXを使用していない場合でも、Babelはフロントエンド開発に最適なツールです。 ブラウザでのサポートを待たずにES6とES7のこれらすべてのクールな機能を利用したくないのは誰ですか？
同型アプリケーションこれは現在の傾向です。 このアプローチについて聞いたことがない場合
は 、Airbnbチームからの
良いレビューがあり
ます 。 アイデアは、サーバー上でHTMLページをレンダリングし、クライアントに転送して（キャッシュとCDNを使用して）ブラウザーに即座に表示し、JavaScriptが読み込まれると、ReactJSが既にレンダリングされたページに「フック」し、アプリケーションが起動することです。
機能的リアクティブプログラミング（FRP）を使用して調整する（Flux Dispatcherとして）JavaScriptでFRPを使用するための優れたライブラリがいくつかあります（RxJS、Bacon、Kefir）。 主なアイデアは、変数を一連の変更として表現し、
map 、
filter 、
reduceおよび高階関数（別の関数を引数として取る関数）などの関数を使用してこれらの変更を結合
することです。 ユーザーインターフェイスの場合、このアプローチにより、イベントシーケンスをイベントストリームに変換し、そのようなフローをオブジェクトとして操作することができます。
状態管理の一方1つだけですが、大きな利点があります。 Reactコンポーネントにはローカル状態が存在しないため、UIを入力として1つの状態を引数として受け取り、この状態に対応するユーザーインターフェイス（より正確にはそのReact表現）を返す1つの純粋な関数（関数型プログラミングの用語）と見なすことができます。 実際には、このアプローチにより、タイムトラベルをリアルタイムでデバッグ、元に戻す、やり直しが可能になります。 ここで、それがどのように行われたかを見ることができます：
このアプローチにより、Webアプリケーションのテストとデバッグがまったく新しいレベルになります。 スクリーンショットや「再生手順」の長いリストはもう必要ありません。 バグが発生した場合は、アプリケーションの現在の状態をコピーして、開発者に渡します。
不変のデータ構造場合によっては、それらを使用すると、より高速なコードを記述できます。 さらに、変更可能なオブジェクトと値が不足しているため、バグが少なくなります。 Baobabは不変のデータ構造（永続的のみ）を提供しないという事実にもかかわらず、データツリーを直接変更することは推奨しませんが、このためにAPI関数を使用することを提案します。
画像の作成者（カットの前）はStefpet 、 Creative Commons 2.0です。