新しい角度を選んだ理由

私の記事では、新しいAngularをエンタープライズアプリケーションの基盤として使用した経験を皆さんと共有したいと思います。 新しいAngularはReact、Vue、または他の人気のあるライブラリよりも優れているというスピーチは、この記事には含まれませんが、もちろん、競合他社と比較します。 すべてのソリューションには長所と短所があり、あるプロジェクトに適しているものは、別のプロジェクトで活気づくことができます。 そのため、新しいAngularが私たちを引き付けたものを説明する前に、開発ですでに使用しているものについて少しお話しします。

私たちの主なプロジェクトは長い開発パスを持ち、すでに時代遅れのテクノロジーであるマリオネット+バックボーン+コフィスクリプトで構築されています。 数年前、私たちはそのようなスタックでプロジェクトを開発することが非常に困難になったことに気付き、フロントエンドエコシステムで代替案を研究し、そこで「獣」をどのように移行できるかを考え始めました。

プロジェクトの作業を開始して、現在人気のあるReact + Redux +スタック[Reselect、Redux-Saga、Redux-formなど]を選択しました。 これは、新しいスタックを選択する最初の試みであり、残念ながら失敗しました。何年も前にマリオネットほど便利ではなかったようです。 約6か月前の調査の結果、私たちの選択は新しいAngularに落ち、私たちはそれに満足しています。 新しいAngularは会社のメインプロジェクトでは使用されていませんが、将来的にはこのソリューションへの移行に支障はありません（Coffeescriptの巨大なコードベースに止められない限り）。 それで、新しいAngularで見つけたものとそれが好きだった方法を見てみましょう。

重要度ではなく、ポイントがランダムに表示されます。 もちろん、ソリューションの利点を考慮するものから始め、最後に欠点についてお話します。

長所

角度はフレームワークです

これは私たちにとって最も重要な利点の1つです。 5年前に会社でプロジェクトを始めたとき、クールで全体的な製品を構築するのは簡単だと思いました。 なんて素朴なんだ！ :)より多くの人々がプロジェクトに接続するほど、一般的なスタイルとアーキテクチャにソリューションの「動物園」全体を持ち込むのにより多くの時間を費やしました。 これは、Marionetteが開発者を制限することのないプリミティブのセットにすぎないため、Marionetteが私たちに与えた自由のためです。

すべての人は異なっており、誰もが好きなように製品のコードを作成します。 この問題に苦労していないとすぐに、コーディングスタイルを導入し、コードを修正し、アーキテクチャの説明を作成しましたが、同僚の1人から非標準のソリューションに出くわすことがあり、プロジェクトを同じ開発とアーキテクチャに戻すために多大な労力を費やす必要がありました。

その後、Reactの開発時間があり、ReduxとFluxが私の助けになったようです。 はい、これにより、これらのモデルの変更がコード全体に散在することを心配する必要がなくなりましたが、問題の1つはまだ残っていました。 私は、製品に引きずり込まれたライブラリーのセット全体を追わなければなりませんでした。 私たちのスタックは、その多様性とアプローチに満ちていました。

次に、Angularに切り替えました。 その柔軟性にもかかわらず、開発者にとってはかなり制限的なフレームワークです。 また、非常に多くの可能性が含まれているため、プロジェクトに新しいライブラリを導入することは私たちにとって非常にまれなイベントになり、制御が容易になりました。 Angularチームが提供するコーディング標準の存在により、私は完全に息を吐き、リラックスし、開発により多くの時間を割くことができました。

もちろん、Angularではカオスを作成できますが、パフォーマンスを評価するとき、または再利用しようとすると、誤って構築されたコードがすぐに表示されるため、これは非常に困難です。 より厳しいフレームワークを用意できたらうれしいのですが、残念ながら、拡張する可能性は失われますが、したくありません。 私には、Angularで妥協点が見つかったようです-これはすべてのマリオネットを許可しているわけではありませんが、難しいExtjsは許可していません。

CLIシステムの可用性

もちろん、これは角度のキラー機能とはほど遠く、Reactにも独自のcli（react-starter-kit）がありますが、それにもかかわらず、ボイラープレートを選択するのに時間を費やすよりも、コンソールクライアントを使用して新しいソリューションの研究を開始する方がはるかに簡単です何かが機能しない理由を見つける。 さらに、コンソールクライアントには、最小限のアプリケーションテンプレートをすぐに生成し、開発モードまたは運用モードでコードを簡単に実行し、テストを実行できるという大きな利点があります。

もちろん、これはすべてエントリのしきい値を下げ、ファイルの場所やアプリケーションの「スケルトン」の記述について（ある程度まで）考えずに、すぐにビジネスコードの記述を開始できるようにします。 また、Angularのユーザーに敬意を表する必要があります。コンソールクライアントはemberjsクライアントの上に構築されています。 昔々、私はエンバーに出会い、彼らのコンソールクライアントの利便性に喜んで驚いていましたが、これは私がその時に気づいた唯一のエンバーの利点でした。

タイプスクリプト

Typescriptが最初に登場したとき、その目的を理解せず、型チェックはすべて「巧妙」であると信じていました。また、不正なデータ転送による多くの欠陥はありませんでした。 時間が経つにつれて、気が変わり、フローパッケージをReactプロジェクトに導入することさえ試みましたが、1週間の苦労の後、私たちはあきらめ、それなしで生きることができると決めました。

次に、Typescriptで完全に記述されているAngularに注目し、もう一度操作してみませんかと考えました。 Typescriptに切り替えて最初に感謝したのは、es6をbabelや他のトランスパイラーの設定で不必要に大騒ぎせずに簡単に使用できることでした（そして、次の更新でコードアセンブリが壊れないという確実性）。 コードを記述するだけで、コンパイラはそれらを問​​題なくes5に変換します。

しかし、何よりも、IDEでのコードの記述がはるかに便利で楽しいものになったことを嬉しく思います-自動補完が正しく機能し、コードコンテキストを離れることなくメソッドのドキュメントを見ることができ、コードが自己ドキュメント化されました。 メソッドに渡すオブジェクトの種類をコメントで記述する必要はなくなりました。これによりTypescriptが提供されました。

少し後に、インターフェイスとデコレータの魅力に感謝しました。 はい、もちろん、Reactを使用してTypescriptで記述できるため、Angularのユニークなプラスではありませんが、フレームワーク自体がTypescriptで記述されている場合、コードのシームレスな統合が可能になります。

コンポーネントアプローチ

現在のほとんどすべてのソリューションはコンポーネントアプローチパラダイムを使用しており、Angularはそのようなソリューションを提供する最初の企業ではありません。 ただし、Angularアプローチを他のソリューションのアプローチと比較すると、いくつかの違いがあります。

• htmlマークアップ用の新しいタグを作成できるだけでなく、既存のタグを変更することもできます。 Reactを使用するとき、階層内に不要なhtml要素がなくてもクリーンなマークアップを作成できたのは、いつもとは程遠いものでした。これは、レイアウトデザイナーを非常に悩ませました。 Angularでは、属性を介して既存のhtmlタグの動作を変更できます。これにより、マークアップがよりクリーンで快適になります。

  
  
  
  
  
  
  

• 別のファイルにレイアウトを作成できます。 私たちの会社では、JS開発者はHTMLを課すことを本当に好まないので、タイプセッターがあります。 JSとes6の知識がなくてもReactコードのレイアウトに携わったとき、彼にとっては地雷原を歩いているようなものでした。 Reactにはマークアップをレンダリングする機能があることは知っていますが、多くのJS関数によってコードが生成されると、それほど単純ではありません。 JSを教えるよりも、注意を払う必要のないもの（もちろん指示について話す）をタイプセッターに説明する方が簡単であることがわかりました。 Pipeを使用することで、データ処理の複雑なマジックをすべてコーダーから隠すことができ、小さなディレクティブが散在しています。

  
  
  
  
  
  
  

• Change DetectorのパラメーターまたはCSSクラスでのコンポーネントの動作を変更することにより、コンポーネントの動作をカスタマイズできます。 さらに、基本コンポーネントから継承すると、すべての設定が保存されます。 したがって、1つのパラメーターで変更不可能なオブジェクトの比較モードで変更検出器の動作を有効にし、そのような基本コンポーネントから継承する場合、変更検出器メカニズムの不要なサイクルを回避できます。 もちろん、これには、開発者が基本クラスから継承するときに行うことを理解する必要があります。 スタイルのカプセル化により、多くのコンポーネントの1つで次に選択されたクラスの名前を選択するという苦痛を回避できました。

  
  
  
  
  
  
  
• コンポーネントが入力で受け取ることができるパラメーターと、そこから取得できるイベントを指定できます。 その後、追加のパラメーターをコンポーネント入力に渡そうとすると、コンパイラーは、コンポーネントがそのようなパラメーターについて何も知らないことを知らせます。 これにより、外部コンポーネントを使用する際のエラーを回避できます。 もちろん、ReactにはPropTypesがあり、これを使用してコンポーネントの入力を制御することもできるため、Angularはここでは一意ではありません。

Rxjs

AngularはRxJSライブラリの上に構築されており、使用しないのは奇妙でした。 しかし、このライブラリに初めて出会ったとき、私たちはぞっとしました。 データの処理チェーンを正しく記述する方法を見つけるのに数日かかりました。 結果は、このライブラリに何かを書き込もうとしたことがある人だけが読むことができるコードです。 それは私たちをとても怖がらせて、RxJSの使用を放棄することさえ考えました。

少し時間が経って、ドキュメントを何度か読み直し、動作中のライブラリを試し、それに慣れました。 RxJSライブラリを使用すると、データ処理で非常にクールなことができ、ほとんどの場合、コードは意図したとおりに動作します。 確かに、今でも、6か月後、私はこのライブラリの完全なパワーを完全には知らないことを理解しています。 しかし、その後、私はそれを使用することを拒否する可能性は低いことを理解しています。

もちろん、RxJはReactに埋め込むことができますが、フレームワークで同じものを使用する場合、たとえば、Angular HTTPモジュールを使用してバックエンドを操作するなど、フレームワークにコードを簡単に関連付けることができます。

依存性注入

依存性注入はほぼすべての場所でAngularで使用されているという事実から始めなければなりません。つまり、非常に大きな境界内でフレームワークの動作を変更することができます。

さらに、AngularのDIは柔軟性が高いため、Singleton、Factory、Facadeなど、よく知られている多くのパターンを実装できます。 コンポーネントの相互作用から、モーダルウィンドウやユーザーへの通知を表示するサービスの作成まで、あらゆる場所でDIを使用しています。 そしてもちろん、バックエンドでのすべての作業は、サービスとDIを通じて構築されます。

私はそれを使ったネガティブな経験があるので、reduxアプローチの支持者ではありません-（プロジェクトの1つで、大量の定型コード、多くの場合、大規模なreduxサガハンドラーとスローダウンするゲッターの遅延にうんざりしていました）。 おそらくそれを間違って使用したかもしれませんが、それはポイントではなかったようです。 このスタック全体をインターフェイスを使用して完成したプロジェクトに組み込みましたが、新しいものは構築せず、バックエンドで作業を強化して、すべてを状態プロセッサおよび副作用プロセッサに便利に適合させました。

しかし、Angularに戻ります。 reduxアプローチは必要ないが、いわゆる「trueの単一状態」にしたい場合は、Angularでサポートされているサービス、RxJSコンポーネント、およびUniderectialデータフローを使用できます。 コードははるかにコンパクトであり、reduxアプローチよりも悪くありません。 時間が経つにつれて、コードをほとんど変更することなく、それをリデュースアプローチに変換できるようになります。 このアーキテクチャが最終的にどのように見えるかについては、 こちらをご覧ください 。

モジュール

Marionettejsで初めてモジュールに出会い、信じられないほど便利でした。 モジュールを多数のファイルに分割します-個別にコントローラー、個別にビューなど そして、マリオネットが私のためにすべてをまとめた後。

Reactでプロジェクトを開発しているとき、モジュールについてよく覚えていましたが、Reactにはすぐに似たものは何もありません。そのようなものを検索したり実装したりする時間はありませんでした。 これに対して、Angularは最初からモジュールの概念を提供します。 また、コードベースとのコラボレーションが大幅に簡素化されます。 ビジネスコンポーネントのすべての部分をモジュールに収集するだけで、別の開発者がそれを使用するには、モジュールをコードに追加するだけです。

モジュールにはコンポーネント用の独自の名前空間があるため、外部コードで誰かが「内部」を利用できることを心配する必要はありません。 これは、残りのコードからの優れた抽象化レイヤーです。 そしてもちろん、他の開発者が使用できるように、必要なコンポーネントを外部にエクスポートする機会があります。

さらに、モジュールはコードを文書化するための優れたツールです。 もちろん、モジュールを使用する機能があり、それらについて知る必要があります。 最初の機能は、モジュールで定義されたサービスがアプリケーション全体にアクセス可能であり、これらのサービスの名前に注意する必要があることです。 Angularは、衝突を避けるために、新しいJS標準のSymbolタイプの類似物を使用したソリューションを提供します。

2番目の機能は遅延読み込みモジュールに隠されており、そのようなモジュールから読み込まれたサービスはモジュール内でのみ利用可能です。 これは、製品がプラグインシステム上に構築されており、サービスへの妨害されないアクセスが必要なため、回避策を模索するかなり不快な機能です。 アプリケーションの開始時にサービスを早期にプリロードするため、この機能を除外しました。

フレームワークの開発とそのサポート

Reactとは異なり、Angularはたった1人の株主であるGoogleによって開発されており、私たちにとってこれは重要です。 スタックの開発は本質的にコミュニティによって行われているReactの経験から、選択されたライブラリがサポートされなくなったり、欠陥を修正する率が非常に低いことが何度かあり、これにより開発が遅くなりました。

あるライブラリを別のライブラリに変更しなければならず、ライブラリをフォークして独自の変更を加える必要が何度もありました。 はい、Angularでこれに影響されませんが、ここではフレームワーク自体に多くの要素が含まれているため、サードパーティのライブラリははるかに少なくなっています。 Angular自体の欠陥については、緊急の必要がある場合に、Angularチームからの有料サポートを使用できます。これは、問題の解決や別の解決策の発見に役立ちます。 しかし、もちろん、これは少しの予算を費やす必要があります。

これらはAngularが持つすべての利点ではなく、私たちにとって重要と思われる利点だけです。 さらに、AngularはコードをWebWorkersに変換する機能を備えているため、マルチスレッド化、サーバーサイドレンダリングなどが可能になります。 現在、これらの機能は必要ありませんが、必要な場合は、コードを大幅に変更せずにいつでも使用できるのは素晴らしいことです。

短所

他のソリューションと同様に、Angularは理想的な製品とはほど遠いものであり、もちろん短所もあります。

かなり平凡なドキュメント

ドキュメントがありますが、その品質には多くの要望があります。 多くの場合、ドキュメントを開くと、クラスメソッドの名前が表示されますが、クラスメソッドの機能や方法についての説明はありません。 説明が存在する場合でも、生きている例がなければ、いずれかの方法を使用する方法を理解することは常に可能とは限りません。

Angularでコンポーネントを動的に作成しようとした人は誰でも私を理解するでしょう。 いくつかのことがドキュメントに欠けているため、目標を達成する方法を理解するにはコードを掘り下げる必要があります。 しかし、時間の経過とともにこの問題は解消され、ドキュメントが追加されると思います。

大量の結果コード

すぐにAngularを使用する場合、出力では多額のモジュールが得られ、そこから憂鬱と悲しみが生じます。 しかし、ドキュメントを少し掘り下げると、出力のコードのサイズを大幅に削減する多くのソリューションを見つけることができます。 そして、いくつかのアプローチがあります。

• 使用していないモジュールを除外します。 たとえば、Angularが提供するアニメーションまたはフォームを使用しない場合、これらのパッケージを一緒にドラッグする必要はありません。 プロジェクトのビルド時にツリーシェーキングを使用することもできます。これにより、コードから未使用のパーツが除外されます。 たとえば、これにより、プロダクションコードに含めるRxJSのサイズが大幅に削減されます。

  
  
  
  
  
  
  

• AOTコンパイルを使用します。これにより、コードからランタイムコンパイラが除外され、非常に重くなります。 確かに、これは、コンポーネントを動的に生成しない場合にのみ可能です。 ただし、この場合でも、コンパイラを別のモジュールに移動して個別にロードできます。

  
  
  
  
  
  
  
• 遅延読み込みモジュールを使用します。 Angularルーターは、ボックスからの遅延読み込みモジュールで動作し、モジュールを読み込むための戦略を選択したり、独自のモジュールを作成することもできます。 デフォルトでは、モジュールは最初にアクセスされたときにのみロードされますが、モジュールのロードをバックグラウンドで設定できるため、モジュールによってロードされたセクションへの移行が高速化されます。

私たちにとって、このマイナスは特に重要ではありません。アプリケーションは6か月ごとにリリースされ、大きな負荷はなく、ブラウザーのキャッシュが私たちを救うからです。 そして、誰かがモバイルデバイスからそれを使用することを想定していません。このため、別個のネイティブアプリケーションを作成する方が良いでしょう。

複雑なエントリのしきい値

Angularは非常に洗練されたフレームワークです。 一方では、cliを使用して、簡単にコードの記述を開始できますが、他方では、変更検出機能の動作方法などのドキュメントを学習しなくても、非常に最適でないコードを作成したり、まったく機能しないことさえできます。

また、このマイナスを渡さず、遅延ロードモジュールのサービスが別のモジュールで表示されない理由を理解しようとして多くの時間を費やしました。 Angularの複雑さに加えて、RxJsライブラリは多くの時間を費やしました。これは簡単に理解できるものではありませんが、価値があります。

おわりに

上記に基づいて、Angularは大規模なアプリケーションの構築を恐れることのできない真の企業フレームワークになったという結論に達しました。 これは主に、RxJとTypescriptの選択など、正しく行われた決定のチェーンであるAngularの最初のバージョンでの経験の理解と、行われた決定の整合性によるものでした。

Reactは良いアイデアの集まりですが、すぐに使える機能が多くないため、多くの場合、誰もがコミュニティから提供される機会から自分の「モンスター」を作ります。 その結果、新しい開発者が複雑なプロジェクトに参加する時間はAngularの時間よりもはるかに長くなり、多くの場合、近隣のチームでさえ問題を抱えています。 しかし、繰り返しますが、これは純粋に私たちの意見であり、私たちの経験と創造されたプロジェクトに由来しています。 Angularを選択する場合、開発の速度と、開発者がコードを変更して製品を前進させることができる速さが重要です。