ホームページ > 記事 > ウェブフロントエンド > JavaScript テクノロジー スタックの見通しについての詳細な紹介
新しいフロントエンド プロジェクトを計画している場合、または既存のプロジェクトをリファクタリングしている場合は、現在のフロントエンド開発環境が以前のものではなくなっていることを認識する必要があります。React、 という選択肢が多すぎます。 Flux、Angular、Aurelia、Mocha、Jasmine、Babel、TypeScript、Flow... 本来の目的は開発を簡素化することですが、事実上学習コストが増加し、将来のプロジェクトのメンテナンスに不確実性をもたらします。
幸いなことに、この現象は薄れつつあり、適者が生き残るということで、優れたプロジェクトが徐々に定着し、開発手法が明確になってきています。一部の開発者は、上記の技術をベースにしたフレームワークを開発に使用しようとしていますが、これにより学習コストもある程度削減されます。
この記事では主に、私が Web アプリケーション開発に関与し、推奨しているいくつかのテクノロジーを紹介します。その中には技術的に物議を醸しているものもあるため、各テクノロジーの簡単な紹介と分析のみを行います。これらの意見はすべて私の個人的な経験とコミュニティとの接触に基づいているため、必要に応じて使用してください。
React は頂点に達しています:
コンポーネント化により、アプリケーションの開発と保守が容易になります
学習曲線は平坦で、コア API は簡潔かつ明確で、学習が簡単です
JSX 構文は型破りで、JavaScript の機能を最大限に活用しており、Flux と Redux に自然に適応しており、多くの優れた開発ツールに貢献しています。バインディング方法は、複雑なアプリケーションにより適しており、高品質です
サーバーサイドレンダリングをサポートしています
React は、Ember、Aurelia、Angular などの機能豊富なフレームワークと比較して万能ではありませんが、React の開発環境より堅牢に。現時点では、React の使用はテクノロジーの選択ではなく、より効率的かつ効果的な生産性を提供するビジネス プラクティスです。
ビューレイヤーを開発できるようになったので、アプリケーションの状態とライフサイクルを管理するために他のツールを使用する必要があります。ここで推奨されるツールは Redux です。
これらの問題を解決するために、Flux パターンを模倣する一連のフレームワークが派生しました: Fluxible、Reflux、Alt、Flummox、Lux、Nuclear、Fluxor...
現在、開発コミュニティによって広くサポートされている 1 つの実装リダックスです。 Redux では、ほとんどのコンポーネントは純粋に機能的なコンポーネントであり、集中ストレージとリソース センターは 1 つだけです。 Redux のインスタンス メソッドは、データ全体の運用と保守を担当します。 Flux と比較すると、Redux の考え方はより明確です。
Redux を取り巻くエコシステムは、Redux 自体と同じくらい堅牢です。素晴らしい開発ツールから強力なメモ化ツール reselect まで、Redux 開発コミュニティは開発者に必要なものをすべて提供します。
開発者は本能的に Redux テンプレートを抽象化しようとする可能性がありますが、これには多くの利点がありますが、やみくもに試すのではなく、ニーズを明確に理解した上でテンプレートをカプセル化してください。
ES6 と Babel
CoffeeScript の機能の多くは ES6 と同様の構文を持ち、ES6 は実装標準であり、JavaScript の将来の開発方向を表すため、CoffeeScript を放棄する時期が来ました。
最新のブラウザはすでに ES6 のほとんどの機能をサポートしています。 Babel は、ES6 を ES5 に変換するための強力な変換ツールです。さらに、トランスコーディングの程度は、ターゲットブラウザに応じて調整できます。
では、型システムはあるのでしょうか? TypeScript と Flow は両方とも JavaScript の静的型システムを提供します。静的型チェックを使用すると、エラーを効果的に検出し、テストの量を減らすことができます。現時点では、これについては様子見のアプローチをとることをお勧めします。
TypeScript は、JavaScript を C# や Java の方向に発展させるために最善を尽くしていますが、代数データ型などの多くの高度な型システム機能が欠けています。さらに、Null は Flow ほど効率的に処理されません。
それに比べて、Flow はより強力で、より多くのエラー タイプをキャプチャしますが、設定が困難です。さらに、新しい JavaScript 機能のサポートは Babel よりも弱く、Windows システムはサポートされていません。
私の個人的な観点から言えば、型システムはフロントエンド開発の重要な部分ではありません (ここでは議論の余地があるかもしれません)。型システムがより堅牢で Babel に優しいものになるまで、様子を見ましょう。
もう一つの議論の余地のないツールは ESLint です。 ESLint は ES6 構文をサポートし、React プラグインも提供します。これはもはや単なる コード レビュー ツール ではありません。現在、JSLint は廃止されており、ESLint は独自のクラスで JSHint と JSCS を置き換えることができます。
開発者は独自のニーズに応じて ESLint を設定できますが、ここでは AirBNB の開発仕様に従って設定することをお勧めします。または、ESLint airbnb config を直接使用することもできます。もちろん、この仕様にはまだ欠点がありますが、チームのコード全体の一貫性を維持することで、コードの可読性を効果的に向上させることができます。
ESLint に慣れたら、開発者はそのルールを詳しく試してみることをお勧めします。 ESLint がキャッチするエラーが多いほど、製品の安定性は高くなります。
Bower のことは忘れて、NPM に任せましょう。 Browserify や Webpack などのビルド ツールは、Web 開発における NPM の地位を間接的に高めました。 NPM を使用すると、バージョン管理がより簡単になり、Node.js エコシステムとの連携が強化されます。現在の CSS の処理はまだ十分に完成していません。
デプロイメントサーバー上でビルドを実行する方法について考えているかもしれません? Ruby の Bundler とは異なり、NPM はワイルドカードを使用してファイルを取得し、コード開発中およびプロジェクトのリリース前にサードパーティのパッケージを任意に変更できます。シュリンクラップ ファイルを使用して、プロジェクト内のサードパーティの依存関係を固定します。出力の一貫性を向上させるために、ユーザーのシュリンクラップを使用することをお勧めします。さらに、開発者は、Sinopia などのツールを使用して独自のプライベート NPM サーバーをホストすることも検討できます。
Babel は ES6 モジュール構文を CommonJS に変換します。 CommonJS は実証済みの構文であり、安定性と汎用性を意味します。さらに、ツリー シェーキングなどのメカニズムを使用して静的コード分析を実現できます (Webpack 2.0 と Rollup はすでにこの機能をサポートしています)。
何百ものスクリプト タグをページに追加することに満足しない場合は、ビルド ツールを使用してページのリソースをパッケージ化してみる必要があります。さらに、NPM サードパーティ パッケージのブラウザー サポートを有効にするために、いくつかのツールが必要になります。ここでは、Webpack を使用することをお勧めします。
1 年前、開発者は、JavaScript ベースの RequireJS、Browserify、Webpack ソリューションなど、上記の作業のために選択できるツールをまだ数多く持っていました。さらに、ES6 モジュールに最適化されていると言われている RollupJS もありました。
今試しています すべてのツールを使用した後、開発者には Webpack を選択することを強くお勧めします:
設定を通じてさまざまな状況に対処できます
主流のモジュール読み込み方法 (AMD、CommonJS、グローバル) をサポートします
内部機構は修復可能
CSSを処理可能
包括的なキャッシュシステム
ホットリロードをサポート
ほとんどのリソースをロード可能
効率的なパフォーマンス最適化ソリューションを提供します
Webpack は、コード分割と遅延読み込みをサポートし、大規模な単一ページ アプリケーションの処理にも非常に優れています。
しかし、Webpack の学習曲線は非常に急であることは注目に値します。しかし、一度学習すれば、最も強力なビルド システムを自由に使えるようになります。
Gulp と Grunt はどうですか?それに比べて、Webpack はさまざまなリソースの処理に優れています。他の種類のビルド タスクを実行する必要がある場合は、Gulp と Grunt が引き続き役立ちます。 Webpack の実行などの基本的なタスクについては、NPM スクリプトを直接使用することをお勧めします。
JavaScript には、オプションの単体テスト ツールが多数あり、それぞれが安定していて堅牢です。単体テストにのみ使用する場合は、既存のツールでニーズを完全に満たすことができます。
一般的なテスト ツールには、Jasmine、Mocha、Tape、Ava、Jest などが含まれます。それぞれに独自の長所があります。
テストフレームワークに対する私の要件は次のとおりです:
デバッグが簡単なようにブラウザで実行できる
高速実行
非同期テストの処理が簡単
コマンドでの使用が簡単line あらゆるアサーションおよびデータ シミュレーションと互換性のある
サードパーティ ライブラリを使用します
最初の基準では、Ava と Jest は除外されます。
私は、Chai アサーションの豊富なフル機能プラグインと、Mocha の非同期サポートが気に入っています。特定の問題を回避するには、Dirty Chai を使用することを強くお勧めします。 Webpack の mocha-leader プラグインを使用すると、開発者はテストを自動化できます。
React については、開発者は AirBNB の Enzyme と Teaspoon を参照できます。
私は Mocha の機能がとても気に入っています。最も基本的な機能だけが必要な場合は、この記事を参照して Tape について学ぶことができます。
JavaScript には Java や .NET のようなコア ツール ライブラリがないため、開発者は主に外部から外部ツール ライブラリを参照します。
現在、Lodash はそのようなツールのリーダーです。さらに、遅延実行特性により、利用可能なツールの中で最高のパフォーマンスを発揮します。 Lodash を使用する際にすべてのリソースを参照する必要はなく、開発者は必要に応じて機能を使用できます。バージョン 4.x では、Lodash は関数型プログラミングを好む開発者向けに「関数型開発」モードを提供します。
関数型プログラミングに精通している場合は、Ramda について学ぶことができます。このライブラリを使用する場合は、いくつかの Lodash 関数を参照する必要がある場合があります。
多くの React ベースのアプリケーションは jQuery を使用しなくなりました。古いプロジェクトを維持している場合や、jQuery に依存するサードパーティ ライブラリを使用している場合を除き、それを使用する必要はなくなりました。
私はプロジェクトをシンプルにし、コード内でフェッチのみを使用することを好みます。 fetch は Promise に基づいており、Firefox と Chrome は両方ともこのインターフェイスをカプセル化します。他のブラウザの場合は、Putty スクリプトを提供する必要があります。ブラウザーとサーバー間で機能の一貫性を保つために、isomorphic-fetch を使用することをお勧めします。
もちろん、他の優れたサードパーティライブラリを使用して非同期にデータを取得することもできますが、私はfetchで十分だと思います。
Isomorphic JavaScript は、クライアントとサーバーの両方で実行される JavaScript を指し、パフォーマンスを向上させ、SEO を促進するためにサーバー上でページを事前レンダリングするためによく使用されます。同型 JavaScript は React を使用して実装できますが、これは単純ではありません。プログラムが複雑になり、開発者が利用できるツールやサードパーティ ライブラリが制限されます。
電子商取引 Web サイトなどの B2C サイトを構築している場合は、同型 JavaScript の使用が必要になる場合があります。ただし、内部サイトや B2B アプリケーションの場合、パフォーマンスは最も重要なことではないため、同型 JavaScript はそれほど重要ではありません。
最近、API をどうするかについて誰もが考えているようです。誰もが RESTfull API の使用に便乗しており、SOAP は過去のものになりました。現在、業界には HATEOAS、JSON API、HAL、GraphQL など、さまざまな API プロトコルが存在します。
GraphQL を使用すると、クライアントは任意のクエリを実行できます。 Relay と組み合わせると、クライアントの状態とキャッシュをより適切に処理できます。ただし、GraphQL サーバー インターフェイスを作成するのは依然として難しく、ドキュメントのほとんどは Node.js 用です。
Netflix の Falcor は、サーバー側の要件を軽減しながら、GraphQL/Relay と同様の機能を提供するようですが、現在開発者プレビュー段階にあり、実際の開発ではまだ使用されていません。
既知の仕様にはすべて独自の欠陥があり、複雑すぎるもの、データの読み取りのみを処理できるが更新はできないもの、REST とは大きく異なるものもあります。多くの開発者は自分で開発することを選択しますが、それでも上記の問題に遭遇します。
上記の完璧な解決策はないと思いますが、API については私なりに理解しています:
予測可能、一貫性プロトコルに従う
1 つのクエリで複数のエンティティの取得をサポートする
更新操作をサポート
デバッグが簡単
使いやすい
これまでのところ、上記の基準をすべて満たす解決策は見つかりませんでした。
RESFfulを使用している場合は、Swaggerを参照してAPIを記述することをお勧めします。
Electron は、フロントエンド テクノロジーを使用してデスクトップ プログラムを構築できます。GitHub チームによって作成された Atom エディターは Electron に基づいています。基本的に、Electron は内部で Node.js をカプセル化します。これにより、Chrome ウィンドウを開いて UI をレンダリングでき、オペレーティング システムのローカル API にアクセスすることもできます。ブラウザーにはサンドボックス メカニズムがありません。開発者は、Electron を通じてアプリケーションをパッケージ化して配布できます。
これは、クロスプラットフォーム ソフトウェアを作成し、上記のすべてのツールを利用する最も簡単な方法です。さらに、Electron には完全なドキュメントと活発な開発コミュニティがあります。
nw.js という名前は聞いたことがあるかもしれませんが、長年存在していますが、それに比べて Electron はより安定しており、使いやすいです。
これは Electron、React、ホットリロードに基づいたテンプレートです。試してみてください。
私が Twitter でフォローしている人々の一部を紹介します:
Dan Abramov、Redux の作成者
Christopher Chedeau、非常に活発な React 開発者、現在 Facebook で働いています
Jeff Morrison、の 1 人Flow の中心的な貢献者
Sebastian Markbåge、React の作成者の 1 人
Pete Hunt
React
さらに注目に値するものについては、React インフルエンサーを参照してください
そうですPate Hunt の Learning React を読むことをお勧めします!
Dan Abramov が一連のビデオ チュートリアルをリリースしました。Redux 入門を強くお勧めします。さらに、ダンは上記よりも詳細なウォッチリストを公開しました。
Mark Erikson の React/Redux リンク コレクションも素晴らしい学習教材です。
JavaScript エコシステムは急速に発展しており、ますます強力になっています。 React のベスト プラクティスは定着しつつあり、周囲のツールの責任と機能がますます明確になってきています。
覚えておくべき最も重要なことは、シンプルにして、必要な場合にのみ使用することです。
アプリケーションに 2 つまたは 3 つの画面しかない場合は、ルーティング システムを使用する必要はありません。単一ページのアプリケーションを作成している場合は、Redux さえ必要ありません。単純な CRUD プログラムを作成する場合は、Relay を使用する必要はありません。ES6 を学習している場合は、Async/Await やデコレーターを深く理解する必要はありません。React の学習を始めたばかりの場合は、使用する必要はありません。ホットリロードとサーバーサイドレンダリング; Webpack を初めて使用する場合は、コードを分割して複数のリソースをマージする必要はありません。Redux を学習しているだけの場合は、Redux-Form と Redux-サガ。
シンプルにして、一度に 1 つのことを実行してください。
以上がJavaScript テクノロジー スタックの見通しについての詳細な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。