前言：
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
}
},