angular6項目從零開始

　　前言：

　　angular框架接觸恰好一年，期間都是在前端組長的帶領下寫功能模塊的東西。如今公司同時進行兩個項目，終於有機會獨立接入一個項目了！雖有些擔憂不少東西不懂，但更多的是興奮和激動。能從0開始主導一個項目的開發，是極大的考驗也是極大的鍛鍊機會。在開發前的準備階段就已經一連串的疑問涌來了。因此，這注定是一個繁瑣的過程，故開個帖子記錄一下第一個項目的開發過程。做用一個是記錄開發過程當中遇到的問題，另外一方面也能夠藉此梳理開發思路。帖子主要目的是梳理思路，所以，可能會隨意記錄思路，文檔結構每段時間整理。

　　前期準備：

　　一、從新複習了typescript語言。angular就是typescript編寫的，所以首先弄懂他是有必要的。

　　二、學習了angular風格指南 https://www.angular.cn/guide/styleguide#style-guide 。在開發過程當中發現公司不一樣人寫的angular項目有不一樣的結構風格，接觸了公司ioa項目後感受那目錄機構太shit了，一堆index、modify的文件。每次找文件都讓人抓狂。所以此次本身親自操刀搭建框架，必須得有個風格的標準，那就是官方的標準啦！誰敢反駁我就讓他打臉(手動表情：斜眼笑)

　　三、根模塊引入了一些必要、經常使用的模塊，那麼，在子模塊裏，這些模塊還須要再次引入嗎？

　　四、路由特色：看路由這樣一個描述，不過路由器會把相似 URL 的路徑映射到視圖而不是頁面。 當用戶執行一個動做時（好比點擊連接），本應該在瀏覽器中加載一個新頁面，可是路由器攔截了瀏覽器的這個行爲，並顯示或隱藏一個視圖層次結構。而後我去對比了一下angular框架的應用和非angular框架應用的路由跳轉，非angular框架路由的跳轉有明顯的重加載過程。本框架下，不會出現頁面跳轉的頁面元素從新加載的閃爍，很是流暢，體驗好。牛批！

　　五、關於服務？始終有一個疑問，那就是到底有沒有必要處理服務模塊？官方相關文檔都是說應該把不是爲視圖服務的邏輯從組件中剝離出來，寫到服務去。好比接口數據獲取。我一直納悶，有這個必要嗎？接口獲取數據後常常須要和上下文有緊密的邏輯處理關係。入股獨立出去，不見得方便，反而複雜了！仍是我理解錯了？

　　答：看到http章節內容時，終於有了少量眉目！早該寫一些實際應用中的例子說明他的必要性了！https://www.angular.cn/guide/http 看了本章，終於知道爲何要寫服務文件了（至少是一個公共的），舉個例子，接口獲取失敗，不只僅是接口自己的問題，還多是網絡問題。在組件裏面處理的報錯通常都是接口的報錯而不是網絡問題的報錯。所以，君哥以前寫的服務文件就有對網絡報錯的處理，從嚴謹的角度看，這是必要的！好比那些40四、500錯誤。

　　搭建過程：

　　

　　一、angular建立新項目，啓動時rxjs報錯

　　二、公共樣式文件scss的引入。說到組件的組成部分，不禁得想到一個問題。以前的項目中發現公共樣式文件是必須的，一些經常使用的樣式作成公共樣式文件很是有必要。以前的公共文件都是在每一個組件引入的，這樣顯得極其繁瑣。那麼是否有辦法統一導入呢？

　　答：經過查找資料發現（參考http://www.javashuo.com/article/p-olyuwasm-em.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裏面引入相應的基礎文件。 


　　　

 　三、去除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
          }
      },

　　四、添加第三方組件庫，Ant Design。這個是公司規定使用的前端組件庫。安裝方式參照官網 https://ng.ant.design/docs/introduce/zh

　　五、路由、http服務、模塊的引入。原始框架搭建好後，我逐漸意識到一個問題，第一次搭建框架，直接全面搭建有點使人手忙腳亂。因此，爲什麼不換種思路呢。那就是，當須要什麼的時候咱們再去引入或者研究他。好比當我用到http服務的時候，再對fttp服務作引入和單獨的研究以及實踐。用到路由的時候再作路由的研究。仍是先從項目入手比較切合實際，等有了經驗，下次搭框架就能夠作到一步到位了。

　　六、導航風格的導入。其實ng-Zorro就提供了幾個很是美觀實用的導航模板，並不用本身造輪子。參考layout： https://ng.ant.design/components/layout/zh

　　七、依賴安裝的坑！安裝項目的總體依賴，千萬不要用cnpm！！！多是由於cnpm更新問題，基本都是會報各類錯誤，記得總體依賴安裝用npm！單個庫安裝用cnpm是沒問題的。

　　思路、靈感集合：

　　一、模塊的選擇。對比了一下新建的最原始腳手架和以前開發的項目，發現原始腳手架真的是名副其實原始，啥都沒有！那麼該如何添加那些須要的模塊、服務、組件呢？是須要什麼東西就一個個添加仍是有什麼參考依據呢？哪些模塊是在根組件引入的，哪些是在子組件引用的？

　　答：默認模塊和可選模塊。建立應用的時候爲了應用的精簡，默認只會引入程序運行必要的模塊。其餘大量可選模塊得按需手動引入。

 

 

 二、看angular風格指南的時候04-14，說永遠不要直接導入惰性加載的目錄。避免讓兄弟模塊和父模塊直接導入惰性加載特性中的模塊。那麼父級怎麼導入惰性加載的子模塊呢？

 三、對於複雜的模塊、組件應該把他們儘可能拆分，作ioa項目的時候發現一些複雜的模塊，例如項目模塊project寫在單文件裏面，十分龐大，幾百行的代碼。可讀性和維護性極差，代碼塊定位困難。能拆分就拆分。

 四、angular風格指南，05-15.把邏輯放到服務裏，堅持組件值包含於視圖相關的邏輯。what？！這什麼意思？這不是更加麻煩嗎？組件裏各個方法之間的互相引用，路由參數，等等這些怎麼解決？一連串的疑問跳出來。與視圖相關的邏輯這個如何區分？

 五、單套集成仍是多套並行？今天項目會議瞭解到這個項目，後臺是將各個子系統以微服務的方式單獨部署的。也就是沿用虛擬中心的那套方式。而虛擬中心的前端實現也是採用了多套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                }            },