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                }            },