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
1.6k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Angularプロダクト構築アンチパターン
ng-fukuoka Angular Meetup #2の発表資料です。
ponday
January 20, 2018
More Decks by ponday
See All by ponday
関数型でGoFのデザインパターンやってみる
honda
1
1.7k
TypeScriptの型表現
honda
10
3.1k
Web Componentsの今
honda
1
480
これまでのReact、これからのReact
honda
0
340
Gatsbyお試し
honda
0
140
styled-components or emotion?
honda
0
730
Web ComponentsとAngular
honda
0
160
Atomic Design周りについての私見
honda
1
810
え、まだWeb Componentsを未来の技術だと思ってるの?
honda
2
890
Other Decks in Technology
See All in Technology
【CEDEC2026】コードレビュー支援ツール開発から学ぶ:LLMを用いた業務システムの実践的な運用設計と誤出力対策
cygames
PRO
0
600
GitHub CopilotのFinOps- AI CreditのObservabilityと価値を生むためのエージェント設計
yuriemori
0
140
初めてのGitHub Actions / GitHub Actions at First
tooppoo
0
150
組織にどうSREを根付かせるか?〜IVRyの場合〜
abnoumaru
0
330
今こそ聞きたいソフトウェア設計 ドメイン駆動設計再入門
masuda220
PRO
17
6.4k
強化学習「理論」入門
enakai00
3
3.6k
【CEDEC2026】『Relink』を拡張せよ - 『GRANBLUE FANTASY: Relink - Endless Ragnarok』の開発速度と品質を守るCI運用
cygames
PRO
0
140
Webアクセシビリティ入門 2026
recruitengineers
PRO
2
430
SmartHR Engineering Team Deck
smarthr
0
340
え?フロントエンドエンジニアの ワイがインフラも!?
puku0x
1
390
システム思考で問題に対処する
yussak
0
180
攻撃と防御で学ぶAI時代のプロダクトセキュリティ演習
recruitengineers
PRO
6
1.5k
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Ruling the World: When Life Gets Gamed
codingconduct
0
290
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
360
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
330
Game over? The fight for quality and originality in the time of robots
wayneb77
1
240
We Are The Robots
honzajavorek
0
290
Code Reviewing Like a Champion
maltzj
528
40k
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
300
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
410
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
520
GraphQLとの向き合い方2022年版
quramy
50
15k
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 !!