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.2k
TypeScriptの型表現
honda
10
3.1k
Web Componentsの今
honda
1
430
これまでのReact、これからのReact
honda
0
310
Gatsbyお試し
honda
0
120
styled-components or emotion?
honda
0
680
Web ComponentsとAngular
honda
0
130
Atomic Design周りについての私見
honda
1
700
え、まだWeb Componentsを未来の技術だと思ってるの?
honda
2
820
Other Decks in Technology
See All in Technology
Introduction to Bill One Development Engineer
sansan33
PRO
0
260
[SRE NEXT 2025] すみずみまで暖かく照らすあなたの太陽でありたい
carnappopper
2
470
サイバーエージェントグループのSRE10年の歩みとAI時代の生存戦略
shotatsuge
4
1k
毎晩の 負荷試験自動実行による効果
recruitengineers
PRO
5
180
衛星運用をソフトウェアエンジニアに依頼したときにできあがるもの
sankichi92
1
1k
united airlines ™®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedhelp
1
470
How Do I Contact Jetblue Airlines® Reservation Number: Fast Support Guide
thejetblueairhelpsupport
0
150
AI エージェントと考え直すデータ基盤
na0
20
7.9k
ソフトウェアテストのAI活用_ver1.25
fumisuke
1
610
安定した基盤システムのためのライブラリ選定
kakehashi
PRO
3
130
モニタリング統一への道のり - 分散モニタリングツール統合のためのオブザーバビリティプロジェクト
niftycorp
PRO
1
520
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
18
7.6k
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
It's Worth the Effort
3n
185
28k
Designing for humans not robots
tammielis
253
25k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Faster Mobile Websites
deanohume
308
31k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
What's in a price? How to price your products and services
michaelherold
246
12k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
BBQ
matthewcrist
89
9.7k
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 !!