Reactに良い言葉を言う

親愛なる読者の皆さん、こんにちは！



私たちはあなたを喜ばせます-Reactライブラリに関する悪名高いStoyan Stefanovの本はすでに完全に翻訳されています









大規模なJavaScriptトランク上のこの若い芽は慎重に宣伝するのに役立つと考えたため、レビューと少し熱狂的な記事を読むことをお勧めします。



ReactはすでにJavaScriptフレームワークの中で最も有望な主人公の1人になっています。 このツールはシンプルで使いやすいですが、それにもかかわらず、Reactの有用性を証明するメリットを明確に表現することは非常に困難です。 プロジェクトの著者自身でさえ、それを開発し始めて、彼らはそのような質問に全く答えることができなかったことを認めました。



Reactのピークに対する2つの主な異議は次のとおりです。

1. その不完全さ-Reactは、MeteorやAngularとは異なり、「フルスタック」フレームワークではありません。 ルーター、モデルのシステム、およびフレームワークを持っているはずのその他の多くの機能はありません。 MVCの「V」のみを実装していると彼らは言いますが、これは私が話をするケースとは程遠いです。
2. その構文は、ここではHTMLとJavascriptが混在しています。 プログラマーはJSXを見て、「でも...なぜ？」と尋ねます。 また、CSSミキシングを好む人もいます。

これらの問題の両方を強調するとともに、Reactの長所のいくつかに焦点を当てます。 さあ、行こう！



それでは、Reactとは正確には何ですか？



Reactは、コンポーネントを作成するためのJavaScriptライブラリです。 各コンポーネントには「外観」があり、これはrenderメソッドとgetInitialState



定義されたいくつかの状態によって設定されます。 外観は現在の状態によって異なります。 それは本質的に、すべてです。 そして、これがReactを説明するのが非常に難しい理由です-多くの人にとって、それはまさに「不完全さ」の感覚を引き起こします。



例：

 Counter = React.createClass getInitialState: -> count: 0 increment: -> @setState(count: @state.count + 1) render: -> <div> { @state.count } <button onClick={ @increment }>+</button> </div>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、ボタンがあり、クリックすると、incrementメソッドが呼び出されます。 increment



メソッドはsetStateを呼び出すため、現在の番号よりも1つ多い新しい番号が設定されます。



setState



メソッドsetState



コンポーネントを再びsetState



ます。 これは、Reactとそのクローンが同様のツールと異なるのはこのためです。 実際、Reactは「仮想DOM」と呼ばれるドキュメントのオブジェクトモデルをメモリに保存し（「シャドウDOM」はわずかに異なる現象です）、そのDOMとブラウザーに表示されるものとの差を計算します。 この違いに基づいて、作成する必要がある変更のリストが作成されます（ createElement



想像してください）。次に、これらの変更が適用されます。



もちろん、Reactでは、プロパティ（小道具）、タグのさまざまな属性など、他の多くの概念を理解する必要がありますが、DOMは最も重要です。



Reactandとは何ですか



不完全さ。 良いか悪いか



Railsが登場したとき、彼らの「満腹感」が特に宣伝されていました（そのような言葉があればいいのですが）。 それ以来、同等の自給自足であることが判明した選択肢はありません。なぜなら、Railsにはデータベース抽象化のレベル、ルーティングシステム、テンプレートエンジンなどがあるからです。



私の知る限り、最初の選択肢は、理由からのキャンプでした-コードの読み取り行で構成されるマイクロフレームワーク。 それに続いて、シナトラ、チェリーパイ、フラスコ、エクスプレスなどが続きました。 しかし、実際には、それらはすべてフレームワークの概念をエミュレートし続けており、わずかに薄くなっているだけでなく、偏りが少ないように書かれています。 しかし、これらのツールは、大騒ぎしていないため販売されており、比較的小さなアプリケーションの開発に便利です。



Reactを区別する不完全性は根本的に異なります。 Reactは単なるLite Angularではなく、根本的に異なるものです。 それは特定のタスクの非常に良い仕事をします：それはウェブコンポーネントで動作します。 したがって、プロジェクトの大きさについて話すのは間違っています。 ちなみに、Reactはパフォーマンスに重点を置いて作成されました。それは、それを実行するFacebookコメントシステムです。したがって、Reactは間違いなく巨大な規模で作業することができます。



考えるべきことは次のとおりです。本格的なフレームワークが必要ですか、さらに、Reactに基づいて必要なすべてのコンポーネントを整理できますか。 まず、マシンインターフェイスのサイズは本質的に重要ではないことに注意してください。 1GBフレームワークをダウンロードする必要があるが、出力が柔軟で高速なアプリケーションである場合、これは問題ではありません。 一方、フロントエンドのサイズは非常に重要です。 フレームワークからの追加の負荷は、すぐに最終結果に影響します。



Reactには、完全なフレームワークのように見える優れた機能が他にもあります。 ReactでBackboneモデルを混合する多くの例を知っています。 ルーティングを追加するための優れたライブラリがあります 。 しかし、Reactコミュニティーの主な成果の1つはもちろんFluxです 。ただし、これはアプリケーションアーキテクチャへのアプローチというよりもツールキットではありません。



Reactは略語MVCの単なるVですか？



アンドレ・メデイロスが壮大なプレゼンテーションで述べているように、Reactの機能はVに限定されるものではありません。事実、Reactコンポーネントには状態があるため、そのようなコンポーネントはある意味でモデルです。 Medeirosが強調しているように、状態の変化に関する入力の表示を提供するため、同時にコントローラーの機能、またはビューの機能も備えています。 また、コンポーネントは他のコンポーネントと情報を交換し、それらに依存します。 そのため、モデルとコントローラーに適したライブラリを探す必要はありません。そのような意見は間違っています。



また、Reactにはこれらのすべてが不可欠な概念（コンポーネント）の形で含まれているため、責任分担が不十分に実装された、複雑で関連性の高いコードを作成するための最も広い可能性が開かれます。



Medeirosは、MVIの原則（ Model-View-Intention）を採用することでこれらの問題を解決することを提案しています。つまり、Web開発へのかなり独特なアプローチを促進します。 このアプローチの実装の1つはLoopと呼ばれます 。



HTMLとJSを混在させる理由 ...何？ CSSも???



10年前、Web開発には、HTML、JS、およびCSSの分離という独自の神聖な牛がありました。 3つのテクノロジーはすべて、個別のファイルとディレクトリに単独で存在する必要がありました。 これらのファイルは、インクルードを使用して行われた相互参照のみが可能です。



この分離がどれほど調和しているかに関係なく、これは単なる技術の区別であり、責任ではありません。 React Castはこのアプローチに疑問を抱いており、コンポーネントレベルで分離が行われるべきであることを明確に規定しています。 コンポーネントにはさまざまなテクノロジーを混在させることができますが、各コンポーネントは適切にカプセル化および適合された要素であり、論理的に見え、論理的に機能します。 そのような機能のフレームワークにさまざまな技術や言語が関与している場合は、そうです。



これはすべて拒否を引き起こす可能性があり、私の意見では、これは最も不合理な偏見によって説明されます。 ほんの数時間であなたはそれに慣れます。 インターネットで見つけたReactに関する意見はすべて本質的に同じです。 突然、2つの開いているファイルを隣接するタブに保持する必要がなくなり、生産性が劇的に向上します。

CSSをコンポーネント領域に完全に移動することさえ主張しています。 ブランディングする前に、このテーマに関するクリストファーチェダウの興味深いプレゼンテーションをご覧ください。



反論



ここにはエコシステムがあります。



私はこの記事を書いていますが、ReactはGitHubでEmberを打ち負かしました。 それはバックボーンに劣り、当然、Angularですが、「競合他社」よりもはるかに速く成長します。



ReactはFacebookプロジェクトであり、Facebookコメントシステムとほとんどの会社のプロジェクトが実装されています。 さらに、ReactはPinterest、AirBnB、 Khan Academy 、その他多くのスタートアップで広く使用されています。 さらに、AtomエディターはReactの上に構築されており、MicrosoftはReactをサポートしています。



したがって、JavaScriptツールの技術的展望の主流について話すことができる限り、Reactがすでに主流であることを証明しようとしています。 これは、プロジェクトがエコシステムに成長するかどうかに関係なく、プロジェクトのサポートについてあまり心配する必要がないことを意味します。 Reactのライブラリのクラウドがあることを既に確認できます-今のところ、それらの品質を判断するのは難しいです。



コードを判断しやすい



Reactを支持する主な議論の1つは、その論理に関連しています。 これは非常に真実の声明であり、その重みと重要性を過小評価すべきではありません。



私の意見では、コードを判断することは、その中の弱い部分と強い部分を分離できるだけではありません。 これは、問題認識から論理的に、どこで何が起こっているか（イベント、データストリームなど）を理解し、これらの要素を迅速に評価し、最後に問題を排除することを意味します。



興味深いのは、プログラムの品質を考えるとき、バグの数だけでなく、一般的にアジャイルで「バグがあってはならない」という考えだけでなく、バ​​グを修正するのにどれくらい時間がかかるかについても注意を払う必要があります。 このアイデアを習得した私は、1年後にしか取り除くことができなかったバグを思い出しました。 それはひどいメモリリークを引き起こし、特にピーク負荷でプログラム全体を大幅に遅くしました。 バグの数だけから進んでいくと、そのような欠陥はほんの一握りになりますが、決定自体は非常に悪いものになります。



したがって、バグを修正する期間は、コードを判断することが難しいかどうかを示します。 バグを修正するのに多くの時間がかかる場合、これは開発者が問題を発見する前にかなり対処しなければならないことを意味します-そしてその逆も同様です。



Reactを使用すると、コードの説明が簡単になり、いくつかの理由が同時に発生します。 メイン-DOMステートレス。 例として、従来のjQueryでの切り替えの実装方法を検討します。

 // html <section> <div class="toggled">HERE I AM</div> <button class="toggler">Toggle!</button> </section> // coffescript $('.toggler').on 'click', -> $('.toggled').toggle()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一見、すべてがシンプルです。 しかし、ここで問題があります。divが表示されているかどうかをどのように確認しますか？ はい、言うことができます：「ボタンボタンを偶数回クリックすると、ボタンが表示され、そうでない場合は表示されません。」

 Toggler = React.createClass getInitialState: -> visible: true toggle: -> @setState(visible: !@state.visible) render: -> <section> { @state.visible && <div>HERE I AM</div> } <button onClick={ @toggle }>Toggle!</button> </section>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして今、状況は根本的に変化しています。 あなたは言うことができます：「それが見えるならば、それは表示されます。」 鉄則：あなたのコードが理解しやすいなら、このコードで何かを表現することははるかに明確になります。



再利用



これは魔法の言葉です。 バックエンドの世界では、コードフラグメントの再利用が現実です。 たとえば、宝石や卵などです。 しかし、クライアント側では、新しいプロジェクトごとにすべてを再度組み立てる必要があるように見えるかもしれません。 実際、DOMバイパスツールやURLパーサーなどを再利用するのは簡単ですが、コンテンツ自体に関しては、各プロジェクトが異なって見え始め、レイアウトの各要素は独創性であり、「1つのサイズにすべて適合」しません。



あるプロジェクトから別のプロジェクトにコンポーネントが移行するのを見たことはありませんが、通知やボタン、さらに記事やリストなどの「分子」または「オーガニック」なものを含むウィンドウのようなアトミックエンティティが存在する理由はわかりません視覚的なデザインをマークアップや動作から分離した場合、タスクを「そのまま」使用することはできません。



異なる企業で同じ開発が繰り返し使用され、コンポーネントが実装された無料のライブラリを人々がどのように書くかを見るのは興味深いでしょう。 良い例はMaterialUIです。



プロジェクトの成長



私が取り組んだクライアント側のプロジェクトの多くは、当初非常に小規模でしたが、その後大幅に成長しました。 いくつかはリファクタリングを経て完全に異なる構造を獲得したか、ある時点で、その中に即興構造が導入されました。これは、増大する複雑さに対処するのに役立つと思われました。 どちらの場合も、そのような作業には多くの時間と労力が必要です-ただし、重要なリファクタリングと同様に、開発を大幅にスピードアップできます。



コンポーネントベースの開発の重要な特徴の1つは、プロジェクトのこれらの段階と非常に有機的に調和していることです。 コンポーネントの小さなセットときちんと整理されたデータフローで開始されたプロジェクトが、このような根本的な変更を必要とすることは想像できません。そのすべての部分は非常に安定しています。



以上です。 実際、ここではFluxトピックについてはほとんど触れませんでしたが、これはすでに完全に異なる記事の素材です。