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
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
ponday
January 20, 2018
Technology
1.6k
0
Share
Angularプロダクト構築アンチパターン
ng-fukuoka Angular Meetup #2の発表資料です。
ponday
January 20, 2018
More Decks by ponday
See All by ponday
関数型でGoFのデザインパターンやってみる
honda
1
1.6k
TypeScriptの型表現
honda
10
3.1k
Web Componentsの今
honda
1
470
これまでのReact、これからのReact
honda
0
340
Gatsbyお試し
honda
0
130
styled-components or emotion?
honda
0
720
Web ComponentsとAngular
honda
0
150
Atomic Design周りについての私見
honda
1
790
え、まだWeb Componentsを未来の技術だと思ってるの?
honda
2
880
Other Decks in Technology
See All in Technology
ルールルルルル私的函館観光ガイド── 函館の街はイクラでも楽しめる!
nomuson
0
100
バックオフィスPJのPjMをコーポレートITが担うとうまくいく3つの理由
yueda256
1
300
解剖"React Native"
hacusk
0
120
Oracle Cloud Infrastructure(OCI):Onboarding Session(はじめてのOCI/Oracle Supportご利⽤ガイド)
oracle4engineer
PRO
2
17k
20260410 - CNTUG meetup #72 - DiskImage Builder 介紹:以 Kubespray CI 打造 RockyLinux 10 Cloud Image 為例
tico88612
0
120
Oracle AI Database@Google Cloud:サービス概要のご紹介
oracle4engineer
PRO
6
1.3k
主催・運営として"場をつくる”というアウトプットのススメ
_mossann_t
0
140
あるアーキテクチャ決定と その結果/architecture-decision-and-its-result
hanhan1978
2
570
【Findy FDE登壇_2026_04_14】— 現場課題を本気で解いてたら、FDEになってた話
miyatakoji
0
880
Zero-Downtime Migration: Moving a Massive, Historic iOS App from CocoaPods to SPM and Tuist without Stopping Feature Delivery
kagemiku
0
230
プロダクトを触って語って理解する、チーム横断バグバッシュのすすめ / 20260411 Naoki Takahashi
shift_evolve
PRO
1
260
Bluesky Meetup in Tokyo vol.4 - 2023to2026
shinoharata
0
140
Featured
See All Featured
Ecommerce SEO: The Keys for Success Now & Beyond - #SERPConf2024
aleyda
1
1.9k
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
0
190
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
720
Agile that works and the tools we love
rasmusluckow
331
21k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
170
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.4k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
160
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Music & Morning Musume
bryan
47
7.1k
New Earth Scene 8
popppiees
3
2k
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
1
220
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 !!