目的
Angularで開発を本格的に初めてから、疑問に思っていたけど放置してきた疑問を整理していく。
Styleの適用について
Q :Styleの適用方法について
コンポーネントに対して、共通のスタイルを適用したい場合、どういうアプローチがあるか。
Answers
コンポーネントにスタイルを適用するには、2つの方法がある。
1. Componentデコレータのstyles属性に直接Styleを記述する。
2. CopmenentデコレータのStylesUrls属性に適用したいCSSファイルのファイルパスを適用する。
この時、上記属性で指定したStyleは、コンポーネント以外には、影響を及ぼさない。
また、StyleUrlsには、複数のCSSを指定することができる。特定のコンポーネントだけで適用したいスタイルと、システム全体で統一的に利用したいStyleをそれぞれ指定することで、無駄なStyleの定義をなくすことができる。
参考
Angularでコンポーネントに「スタイルシート」を適用するには?(styles/StyleUrlsパラメーター)
ディレクトリ構造について
Q:ディレクトリ構造が壊滅的になってしまう。
Answers
アプリケーション構造とNgModuleをもとに、整理しなおす。
ファイルを見つけやすくする
- ファイル名をわかりやすくする。
- 反省点:命名規約作るべきだった。
- 1つのファイルに複数のコンポーネント、サービスが混在しないようにする。ただし、密接な関係を持つ機能の場合、このルールの例外となり得る。
- 反省点:Classが複数定義されているクラスがあった気がする。例外となるものか確認が必要。
- 1つのフォルダ(機能)でファイルが7つ以上になりそうな場合は、サブフォルダを作成することを検討する。
- コンポーネントは、ビューに必要なロジックだけにするように心がける。コンポーネントをできるだけスリムに保つ。
- ビューに必要ではない処理。例えば、HttpClientを使っての情報操作処理はサービス化して外だしする。
- テンプレートに処理を実装しない。処理はコンポーネントクラスに実装する。
- テンプレートのないプレゼンテーションロジックがある場合は、属性ディレクティブを使用する。
- 反省点:これは知らなかった。これでコンポーネントクラスをスリム化できるということ?今度使ってみよう・・・
サービス
- 反省点:これは知らなかった。これでコンポーネントクラスをスリム化できるということ?今度使ってみよう・・・
- サービスはシングルトン。
- データや機能を共有することができる。ステートフルなデータを共有するのに便利。
- 反省点:HttpClientの処理を外だしするためだけに利用していたが、データの共有もできることを知らなかった。
外部連携を実装する上で、特に重要な考え方があった。
コンポーネントの責任は、ビューに対する情報の表示と収集にあります。どのようにしてデータを取得するかに関心をもつべきではありません。
なるほど・・・
TODO
ディレクティブと、サービスを使った情報共有について初めて知った。次はこれについて深掘りする。