前言：
angular框架接觸剛好一年，期間都是在前端組長的帶領下寫功能模塊的東西。現在公司同時進行兩個項目，終於有機會獨立接入一個項目了！雖有些擔心很多東西不懂，但更多的是興奮和激動。能從0開始主導一個項目的開發，是極大的考驗也是極大的鍛煉機會。在開發前的准備階段就已經一連串的疑問涌來了。所以，這注定是一個繁瑣的過程，故開個帖子記錄一下第一個項目的開發過程。作用一個是記錄開發過程中遇到的問題，另一方面也可以借此梳理開發思路。帖子主要目的是梳理思路，因此，可能會隨意記錄思路，文檔結構每段時間整理。
前期准備：
1、重新復習了typescript語言。angular就是typescript編寫的，因此首先弄懂他是有必要的。
2、學習了angular風格指南 https://www.angular.cn/guide/styleguide#style-guide 。在開發過程中發現公司不同人寫的angular項目有不同的結構風格，接觸了公司ioa項目后感覺那目錄機構太shit了，一堆index、modify的文件。每次找文件都讓人抓狂。因此這次自己親自操刀搭建框架，必須得有個風格的標准，那就是官方的標准啦！誰敢反駁我就讓他打臉(手動表情：斜眼笑)
3、根模塊引入了一些必要、常用的模塊，那么，在子模塊里，這些模塊還需要再次引入嗎？
4、路由特點：看路由這樣一個描述，不過路由器會把類似 URL 的路徑映射到視圖而不是頁面。 當用戶執行一個動作時（比如點擊鏈接），本應該在瀏覽器中加載一個新頁面，但是路由器攔截了瀏覽器的這個行為，並顯示或隱藏一個視圖層次結構。然后我去對比了一下angular框架的應用和非angular框架應用的路由跳轉，非angular框架路由的跳轉有明顯的重加載過程。本框架下，不會出現頁面跳轉的頁面元素重新加載的閃爍，非常流暢，體驗好。牛批！
5、關於服務？始終有一個疑問，那就是到底有沒有必要處理服務模塊？官方相關文檔都是說應該把不是為視圖服務的邏輯從組件中剝離出來，寫到服務去。比如接口數據獲取。我一直納悶，有這個必要嗎？接口獲取數據后經常需要和上下文有緊密的邏輯處理關系。入股獨立出去，不見得方便，反而復雜了！還是我理解錯了？
答：看到http章節內容時，終於有了少許眉目！早該寫一些實際應用中的例子說明他的必要性了！https://www.angular.cn/guide/http 看了本章，終於知道為什么要寫服務文件了（至少是一個公共的），舉個例子，接口獲取失敗，不僅僅是接口本身的問題，還可能是網絡問題。在組件里面處理的報錯一般都是接口的報錯而不是網絡問題的報錯。因此，君哥之前寫的服務文件就有對網絡報錯的處理，從嚴謹的角度看，這是必要的！比如那些404、500錯誤。
搭建過程：
2、公共樣式文件scss的引入。說到組件的組成部分，不由得想到一個問題。之前的項目中發現公共樣式文件是必須的，一些常用的樣式做成公共樣式文件非常有必要。之前的公共文件都是在每個組件引入的，這樣顯得極其繁瑣。那么是否有辦法統一導入呢？
答：通過查找資料發現（參考https://www.cnblogs.com/yujunhua/p/6762256.html），應用的基礎樣式或者說全局樣式是自動生成了的。但是，突然發現，使用ng new 默認創建的應用，生成的styles是css類型的，所以要改成scss或者less類型，有兩種方法，（1）一種是在創建應用的時候配置 ng new My_New_Project --style=scss （2）另一種方法是直接修改styles.css的后綴名，同時修改angular.json。（3）ps：第三方樣式引入也是在該處引入。比如bootstrap的樣式。 （4）全局樣式並不是說都寫在styles.scss里面，而是可以在styles.scss里面引入相應的基礎文件。
3、去除spec文件。用ng generate創建的組件都是默認有component.spec.ts文件的，這是測試文件。在過去的開發中發現都是用不上的。他有一個不好的地方就是礙眼！煩死了！那就把他干掉！參考網上方法，實測有效 http://www.nbsite.cn/qdjs/153
方法：在angular.json文件下找到schematics屬性，配置相應的值。
"schematics":{ "@schematics/angular:component": { "styleext": "scss", "spec": false }, "@schematics/angular:class": { "spec": false }, "@schematics/angular:directive": { "spec": false }, "@schematics/angular:guard": { "spec": false }, "@schematics/angular:module": { "spec": false }, "@schematics/angular:pipe": { "spec": false }, "@schematics/angular:service": { "spec": false } },
4、添加第三方組件庫，Ant Design。這個是公司規定使用的前端組件庫。安裝方式參照官網 https://ng.ant.design/docs/introduce/zh
5、路由、http服務、模塊的引入。原始框架搭建好后，我逐漸意識到一個問題，第一次搭建框架，直接全面搭建有點令人手忙腳亂。所以，為何不換種思路呢。那就是，當需要什么的時候我們再去引入或者研究他。比如當我用到http服務的時候，再對fttp服務做引入和單獨的研究以及實踐。用到路由的時候再做路由的研究。還是先從項目入手比較切合實際，等有了經驗，下次搭框架就可以做到一步到位了。
6、導航風格的導入。其實ng-Zorro就提供了幾個非常美觀實用的導航模板，並不用自己造輪子。參考layout： https://ng.ant.design/components/layout/zh
7、依賴安裝的坑！安裝項目的整體依賴，千萬不要用cnpm！！！可能是因為cnpm更新問題，基本都是會報各種錯誤，記得整體依賴安裝用npm！單個庫安裝用cnpm是沒問題的。
思路、靈感集合：
1、模塊的選擇。對比了一下新建的最原始腳手架和之前開發的項目，發現原始腳手架真的是名副其實原始，啥都沒有！那么該如何添加那些需要的模塊、服務、組件呢？是需要什么東西就一個個添加還是有什么參考依據呢？哪些模塊是在根組件引入的，哪些是在子組件引用的？
答：默認模塊和可選模塊。創建應用的時候為了應用的精簡，默認只會引入程序運行必要的模塊。其他大量可選模塊得按需手動引入。
2、看angular風格指南的時候04-14，說永遠不要直接導入惰性加載的目錄。避免讓兄弟模塊和父模塊直接導入惰性加載特性中的模塊。那么父級怎么導入惰性加載的子模塊呢？
3、對於復雜的模塊、組件應該把他們盡量拆分，做ioa項目的時候發現一些復雜的模塊，例如項目模塊project寫在單文件里面，十分龐大，幾百行的代碼。可讀性和維護性極差，代碼塊定位困難。能拆分就拆分。
4、angular風格指南，05-15.把邏輯放到服務里，堅持組件值包含於視圖相關的邏輯。what？！這什么意思？這不是更加麻煩嗎？組件里各個方法之間的互相引用，路由參數，等等這些怎么解決？一連串的疑問跳出來。與視圖相關的邏輯這個如何區分？
5、單套集成還是多套並行？今天項目會議了解到這個項目，后台是將各個子系統以微服務的方式單獨部署的。也就是沿用虛擬中心的那套方式。而虛擬中心的前端實現也是采用了多套angular框架實例組成的。那么，現在有兩個問題。（1）本項目是集合在一套框架里實現還是分成多套？虛擬中心分成多套適合多人單獨開發，而本項目只有一人開發。（2）多套實例之間是如何實現共享用戶信息和登錄狀態的？（3）單套集成是否使項目過於龐大，跟多套有無區別？是否能用懶加載的方式解決資源占用問題？
"schematics":{
"@schematics/angular:component": {
"styleext": "scss",
"spec": false
},
"@schematics/angular:class": {
"spec": false
},
"@schematics/angular:directive": {
"spec": false
},
"@schematics/angular:guard": {
"spec": false
},
"@schematics/angular:module": {
"spec": false
},
"@schematics/angular:pipe": {
"spec": false
},
"@schematics/angular:service": {
"spec": false
}
},