GSS 技術部落格
在這個園地裡我們將從技術、專案管理、客戶對談面和大家分享我們多年的經驗，希望大家不管是喜歡或是有意見，都可以回饋給我們，讓我們有機會和大家對話並一起成長！
若有任何問題請來信：gss_crm@gss.com.tw
- 這篇要來針對各類 Component 作一些設計上的原則說明:
- AppComponent
- KISS(Keep it simple, stupid)
- 如果可以的話，最好什麼邏輯都不要有
- 想像它只是其他 Component 的容器
- 用來打整個 App 的基底
- 這個 component 的 template 是整個 app 的底
- 之後的範例會再說明是如何運用這個 component 當作基底的
- 避免在這載入資料
- 建議載資料的部份交給需要用到那個資料的 component 處理
- Global 的資料像是 token 或是使用者 session 可以放在這，但建議還是不要在這塞太多 Global 的東西，除非 App 很小，切出去會增加過多的複雜度
- KISS(Keep it simple, stupid)
- Display Component
- 應該會是我們最常用到的 component 類型
- 大部份第三方套件的 component 都是屬於這種，因為它耦合度最低
- Guidlines
- 解耦
- 別跟其他的 component 耦合
- 只跟傳入的資料耦合
- 彈性
- 這個 component 愈單純愈好，不要用一堆設定檔跟選項控制它
- 如果真的需要，再加上，剛開始從簡
- 別載入資料
- 資料的唯一來源就是 @Input
- 主動伸手要資料是不對的行為
- Clean API
- 只靠 @Input 來取得資料
- 適時發出事件通知，讓資料得以傳到別的 component 中
- 透過 service 提供設定的預設值
- 如果一定要設定預設值，不要在每次使用 component 時才傳入，統一透過 service 設定就好
- 解耦
- 資料 Component
- 處理、取得、接收資料，通常這部份會交給 service 做就是了
- Guildlines
- 選擇洽當的 Lifecycle hook 載入資料
- 別擔心重覆使用的問題，因為一定會跟特定 domain 的資料或邏輯耦合
- 思考這個 Component 可以如何準備或處理 Display Component 的資料
- 將商業邏輯封裝在內
- Route Component
- 直接路由到的 component 就是 Route Component
- Guidelines
- 可以在這載入資料，或靠資料 Component 取得
- URL 中的參數最好的處理地點就是這
- 小結
- 理論派的說明到這篇告一個小段落
- 接下來會針對這些理論實一個 Data Center
- 理論派的說明到這篇告一個小段落
相關文章
評論
尚無評論