AngularJSの大規模プロジェクトで1年間働いた後、このプロセスで学んだ教訓を共有したいと考えています。 まず、Angularが好きです。 それは私のニーズを完全に満たし、1ページの「ファットクライアント」のための信頼できるフレームワークが必要になったときに、近い将来完全に切り替えると思います。 彼は素晴らしいです。 ワールドクラスのチームが取り組んでおり、コミュニティは素晴らしいものであり、Webアプリケーションを作成するための機能の完全な組み合わせを含んでいます（またはコミュニティに提供しています）。
コード編成
束は小さい。 当初、私のアプリケーションは、Angularサイトのテンプレートプロジェクトに似ていました。 大量のコードを含む大量の無関係なファイル。 John ResingのSimple Classesの継承から、個別の機能ブロックへの分割に移行しました。 このアプローチは、プロジェクトで小さな継承の深さを維持している間、うまく機能します。 さまざまな種類のクラスを含み、「汚れた靴下の箱」に似た巨大なフォルダーの構造に悩まされていました
-プロジェクト -コントローラー --- someController.js --- someOtherController.js --- ... --- someController99.js
コントローラーを備えたフォルダーの例が頭脳を作ります。 私の新しいルール：特定のファイルを見つけるために頭の中でアルファベットをソートしているのを見つけた場合、フォルダー内のファイルが多すぎる可能性があります。
今、私はよりモジュール化された方法でプロジェクトを構築し始めました。 機能または機能領域の個々の部分には、主に必要なファイル/クラス/オブジェクトのみが含まれます。 理想的な世界では、これらのモジュールは完全に分離され、再利用可能な「メタコンポーネント」として他のプロジェクトで使用できます。 これは、モジュールが依存する一般的なユーティリティ、ヘルパー、またはその他の同様のファイルのセットもおそらく必要とするため、達成するのが難しい場合があります。 再利用が前提条件でない場合、すべてのものとすべてのものの絶対的な分離に多くの時間を費やすことはありませんが、水準が上がったら、その方法を考えます。
Cliff Meyersは、 大規模なAngularアプリでのコードの整理に関する素晴らしい記事を執筆しました。
素晴らしい強力なディレクティブ
今、私はディレクティブはAngularのキラー機能だと思います。 これらは、UIロジックを含む素晴らしい小さなパッケージです。 HTML構文を拡張する機能により、非常に柔軟で強力になります。 間違いなくディレクティブを使用しますが、できる限り頻繁には使用しません。
Angularディレクティブのお気に入りの機能の1つは、リンクする機能です。 それらをHTML属性として設定することにより、ディレクティブを使用して、マルチレベル機能を備えた複雑なウィジェットを作成できます。 機能レベルが互いに競おうとするとき、コインの裏返しが時々現れますが、一般的に指示は驚くべきものです。
今日プロジェクトを開始した場合、ディレクティブ、視覚コンポーネント、および動作の構成に関するいくつかの深刻な考えに注意を払うでしょう。 人気の視覚指向フレームワークをAngularディレクティブでラップするプロジェクトはすでにいくつかありますが、この本格的なコンポーネントセット全体を自分で使用する方法を考える必要はまったくありません。 アプリケーションの主なコンポーネントは何ですか？ 主要なコンポーネントがアプリケーション全体で共通であり、HTMLおよびCSSの一括コピーアンドペーストではないようにディレクティブを設計する方法。 これらのコンポーネントは、今後の作業にどのように使用できますか？
それらについてのビデオを見たことがない場合は、John Lindquistのegghead.ioにアクセスして、一連のディレクティブを見てください。 すべてのビデオは素晴らしく、指令に関する話は有益です。
フレームワークを知る
このプロジェクトを始めてから、確かにしばらくの間、Angularの内臓を掘りました。 ソースコードは読みやすく、十分にテストされているため、Javascriptを理解している人にとっては、 読むのは魅力的です。
掘り下げながら、できる限りそのデバイスを知るようにした。 多くのことはまだ私にとってブラックボックスのままであり、開発者を信頼しているという事実にもかかわらず、私はまだアプリケーションの作成中に何が起こるかを理解する必要性を感じています。 これが私の目下の目標の1つであるため、将来、Angularが内部でどのように機能するかについて何かお話しできることを願っています。
脇に置いて、私はJickeryで同じことをせざるを得ないと感じています。 非常に多くのコード、非常に短い時間。
組立
残念ながら、このプロジェクトでは、アセンブリにMavenとJAWRを使用する必要がありました。 それは本当の戦いであり、「まともな」集会を作ることができませんでした。 移行を支援するツールをいくつかまとめることができましたが、フロントエンドにMavenを使用することはお勧めしません。
今日プロジェクトを開始した場合、私は間違いなくYeomanを使用してテンプレートを簡単に作成し、生活を楽にしました。
CSS
これはAngularに直接関係しているわけではありませんが、Angularプロジェクトのもう1つの重要な側面ですので、これに少し時間をかけたいと思います。
1年前、私の態度は「f CSS」（fはデュース）であったことを認めます。 彼は怖がり、私にそのような嫌悪感をもたらしました。 明らかに、それは無知に起因するものであり、私は昨年CSSレイアウトで遊んでみました。 CSSと私が幸せに暮らせる場所を見つけたので、私の態度はもはや「f CSS」ではなく、「SCSS」のように聞こえます（sはトリプルです）。
「 SCSS 」構文は、単純なCSSで私の脳の多くの問題点をカバーし、明確さを大幅に強化しました。 さらに、 コンパスは、スタイルを操作することによるまったく新しい種類の苦痛を排除する、いたずらな不純物の束を追加します。
将来的には、SASS / Compassをより深く掘り下げ、それらの表現力豊かなスタイルの機能と、前述のAngularのモジュールおよびコンポーネントレベルの作業を組み合わせたいと思います。 SMACSSがスタイルを操作および整理する方法を説明する基本的な標準を提供するように、より整理されたアプローチをスタイルシートに使用したいと思います。
現時点では、CSSと私は完全に調和しています。 私は無知を克服しました。これは明らかに、強い関係を築くための鍵になりました。 どうなるか見てみましょう。 一度に一度。
おわりに
1ページのWebアプリケーションを作成する場合は、Angularが適しています。 アプリケーションの構造をできるだけ早く決定することが重要です。 コードをモジュールとコンポーネントに分割して、ディレクティブの力を最大限に活用し、再利用の可能性を最大限に高める方法を決定します。
ディスカッションに参加したい場合は、 Hacker Newsの記事にコメントを残すことができます。
PSロシア語圏の聴衆にとって、コメントはもちろんここにあります:-)
PPS オリジナル記事