對於寫過 React 來說的人一定對 component 不陌生，在 Angular 一樣有這樣的概念存在，而且可以說是組成 Angular app 的核心。一個畫面可以由多個 Component 共同組合成，而且這些 Component 可能有機會一直被重複使用。另外，依照 component 的職責，還可把他去區分成 Container components 與 Presentational components。

用 component 的方式思考

在比較傳統的前端開發方式，很習慣以整個網頁的思考方式寫程式。如果以 component 的方式思考，一開始會把 UI 拆解成 component 層級，以我們將開發的後台系統為例：

可大致將畫面拆成這 5 個部分，當然每個部分都還有可能可以拆的更小，像是 sidenav 就可能可以在拆成 1 種按扭 component。該怎麼判斷是否拆得夠小呢？可以仔細檢視該 component 是否只負責做一件事情，如果做很多事情，就可能是他又要拆解的時候了！

Component 的樹狀結構

在把這些 component 組合在一起的時候，會產生樹狀的結構。以剛剛的 main 為例，他的內部有 product-list、edit-product 兩種 component。

依職責區分 Components

當專案較複雜和 component 切得比較細的時候，component 樹的結構會很容易很多層，這時候職責與狀態的管理就會非常的重要，若子層的 component 直接去修改到父層狀態，後續的維護會很難追蹤，而且這樣的子層 component 會很難重複使用。比較好的方式是把 component 區分成 Container components 與 Presentational components。而 Container components 通常有以下特性：

• 會與 service 溝通(後面會提到)
• 將 data 傳給子 components (Presentational components)
• 接收來自子 components 的使用者事件
• 為最高層級的路由 components (並非每次都是，路由的部分後面再提)

至於 Presentational components 只要關注在呈現 UI 與將使用者事件委派給上層 components 處理就好了。

結語

網路上有許多介紹 Angular component 的文章，本篇簡單介紹 component 的思考方式，若一開始沒搞懂，很容易寫出很多非常相似的 components 又混雜多種關注的邏輯，這樣就失去 component 能被重複使用的優勢了。下一篇將會帶來一些實作，讓這些概念更加清楚。