Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Angularプロダクト構築アンチパターン
Search
ponday
January 20, 2018
Technology
0
1.5k
Angularプロダクト構築アンチパターン
ng-fukuoka Angular Meetup #2の発表資料です。
ponday
January 20, 2018
Tweet
Share
More Decks by ponday
See All by ponday
関数型でGoFのデザインパターンやってみる
honda
1
1.3k
TypeScriptの型表現
honda
10
3.1k
Web Componentsの今
honda
1
430
これまでのReact、これからのReact
honda
0
320
Gatsbyお試し
honda
0
120
styled-components or emotion?
honda
0
690
Web ComponentsとAngular
honda
0
130
Atomic Design周りについての私見
honda
1
720
え、まだWeb Componentsを未来の技術だと思ってるの?
honda
2
840
Other Decks in Technology
See All in Technology
「改善」ってこれでいいんだっけ?
ukigmo_hiro
0
360
プロダクトのコードから見るGoによるデザインパターンの実践 #go_night_talk
bengo4com
1
2.7k
ソフトウェアエンジニアの生成AI活用と、これから
lycorptech_jp
PRO
0
520
20251007: What happens when multi-agent systems become larger? (CyberAgent, Inc)
ornew
1
460
FinOps について (ちょっと) 本気出して考えてみた
skmkzyk
0
150
All About Sansan – for New Global Engineers
sansan33
PRO
1
1.2k
Bill One 開発エンジニア 紹介資料
sansan33
PRO
4
14k
Azureコストと向き合った、4年半のリアル / Four and a half years of dealing with Azure costs
aeonpeople
1
200
『バイトル』CTOが語る! AIネイティブ世代と切り拓くモノづくり組織
dip_tech
PRO
1
130
ニッポンの人に知ってもらいたいGISスポット
sakaik
0
170
やる気のない自分との向き合い方/How to Deal with Your Unmotivated Self
sanogemaru
1
520
Dylib Hijacking on macOS: Dead or Alive?
patrickwardle
0
360
Featured
See All Featured
Done Done
chrislema
185
16k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
253
22k
Building a Scalable Design System with Sketch
lauravandoore
463
33k
For a Future-Friendly Web
brad_frost
180
10k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
BBQ
matthewcrist
89
9.8k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
The Power of CSS Pseudo Elements
geoffreycrofte
79
6k
Agile that works and the tools we love
rasmusluckow
331
21k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
What's in a price? How to price your products and services
michaelherold
246
12k
Transcript
Angularプロダクト構築アンチパターン ng-fukuoka Angular Meetup #2 / Jan 20, 2018 ponday(@ponday_dev)
Profile Honda, Yusuke (@ponday_dev) chibi-developer ng-fukuoka organizer Community TypeScript /
JavaScript / Kotlin RxJS / Angular Like
お仕事でもAngularを書いてます
その中で感じた (個人的)プロダクト構築アンチパターン
- あくまで個人的な見解ですので、Angular公式が推奨するもの ではありません - フロントエンドのみで約3万行の小~中規模アプリケーション開 発を通じての感想です。規模によっては不適切な場合があり ます。 ご注意
アンチパターン① Angular CLIを使わない
使いましょう
- 自前で環境構築してメンテするには覚悟が必要 - 追従が大変 - コード生成できない - (一応)脱出もしやすい - ng
eject webpack.config.js - IonicにもCLIがあるのでそっち使うほうが無難 アンチパターン① Angular CLIを使わない
アンチパターン② NgModuleがネストしている
モジュールBはモジュールAにインポートされるから... /A/A.module.ts /A/modules/B/B.module.ts
モジュールBはモジュールAにインポートされるから... /A/A.module.ts /A/modules/B/B.module.ts ←
- ネストしても良いことは少ない - インポートパスが長くなる - 再利用しにくい - ディレクトリ構造そのまま別のモジュールでインポートすると実態と合わなくな る -
モジュールはディレクトリ的にはフラットに アンチパターン② NgModuleがネストしている
アンチパターン③ コンポーネントを分割しすぎる
- header - my-button - view-container - foo-page - foo-toolbar
- foo-list - foo-list-header - foo-list-body - foo-footer - … - bar-page - bar-toolbar - bar-form - ...
- header - my-button - view-container - foo-page - foo-toolbar
- foo-list - foo-list-header - foo-list-body - foo-footer - … - bar-page - bar-toolbar - bar-form - ... 本当に必要...?
- header - my-button - view-container - foo-page - bar-page
いらないなら分けない
- 本当にそのコンポーネント再利用しますか? - 再利用できるコンポーネントは結構少ない - 最初はよく再利用される物だけ作る(ヘッダ、ボタンなど) - 再利用が必要になってはじめて分ける - コンポーネントの階層が深くなると状態の管理が面倒
- バケツリレーが長くなる - どのコンポーネントで状態が変更されるかわかりづらい アンチパターン③ コンポーネントを分割しすぎる
アンチパターン④ Module一つあたりの役割が大きい
モジュールは分けなくてもアプリは作れる
しかし、分けないとモジュールに紐づくソースが すごい勢いで増えていく
再利用したくなったり、 コードのまとまりが見えてきたら分けましょう
- 最初から分ける必要はない - コード量が増えるだけ - しかし、単体のモジュールを膨らませ続けると後々つらい - まとまりが見えてきたらリファクタリングをかねて分割を検討する - ライブラリとして提供する場合は小さく
- 設計段階で良く検討する - Angular Materialなども参考に (大体1機能 = 1モジュール) - 理想的にはそのモジュール単体で動作 アンチパターン④ Module一つあたりの役割が大きい
アンチパターン⑤ index.tsを作らない
TypeScriptでは、ディレクトリ直下にindex.tsがあると 勝手に読み込んでくれる
ここにexport文を書いておくといろいろ捗る
例えば... - /app - /toast - /services - toast.service.ts -
/components - toast.component.ts - toast.module.ts - app.component.ts - app.module.ts app.component.tsから使う
そのままだと... app.module.ts app.component.ts - インポートパスがディレクトリ構成に依存 - ディレクトリ構成を変えると外部のソースに影響 - 変更に弱い -
toast.component.tsは外部から使うものか分からない
ここにindex.tsを追加 - /app - /toast - /services - toast.service.ts -
/components - toast.component.ts - toast.component.ts - index.ts - app.component.ts - app.module.ts
中身はこれだけ index.ts
すると... app.module.ts app.component.ts - 内部のディレクトリ構成に依存せずインポートできる - 短く書ける - 内部の変更がしやすい -
公開されているAPIが明確
- TypeScriptの機能 - インポートが短く書ける - インポートパスがディレクトリ構成に依存しない - 外部に公開したいAPIが明示できる - 特にモジュールを分割するときに有効
アンチパターン⑤ index.tsを作らない
アンチパターン⑥ RxJSを何となく使う
(間違いなく)死にます
- Angular RxJS - AngularはRxJSに依存。いろいろなものがObservableを返す。 - AngularのディープなAPIより利用頻度はかなり高いはず - RxJSはむずかしい -
TypeScriptとはパラダイムが全然違う - 新しい言語勉強するのと良い勝負 - その場しのぎでコードを作ると間違いなく負債化する アンチパターン⑥ RxJSを何となく使う
使いこなしたい?
技術書典3で解説書出しました https://booth.pm/ja/items/659290
Thank you !!