## 本章小节 有意识的对已学习的知识进行回顾、总结、归类是个非常好的习惯。在学习的过程中，所以的知识点被我们随意的填充到了大脑这个广阔的房间里，知识点东一块、西一块，这使得大脑不太容易记住他们。而对知识点的总结、归类则相当于把房间的东西归整一遍，合并一下同类项，找一下规则。这样不但需要的存储空间不大，而且当我们想找某些知识点时，也能够非常轻松的找到他们。 ## 组件 在生成标准组件时，将生成以下四个文件： - 负责功能及与其它服务交互的控制器`app.component.ts`，该文件以`component.ts`为后缀，是个标准的typescript类型文件。 ➊ - 负责主体界面的V层文件`app.component.html`，该文件以`html`为后缀，是个标准的html文件。 ➊ - 负责主体界面样式的CSS文件`app.coponent.css`，该文件以`css`为后缀，是个标准的css文件。➊ - 负责协助开发、测试的单元测试文件`app.component.spec.ts`，该文件以`spec.ts`为后缀，表示其为一个标准的单元测试文件；同时以`app.component`为前缀，表示其对应测试的app组件。 ➋ 也就是说：其中前3个文件➊构成了一个标准的组件，而第4个文件➋则是组件的辅助文件。也就是说：如果我们不计划启动单元测试，则完全可以删除以`spec.ts`结尾的测试文件。这不会对我们的系统应用造成任何的影响。  所以当我们再提到某个组件时，就是指`xxx.component.ts` + `xxx.component.html` + `xxx.component.css`。 ## 运行组件 我们在本章中使用了`ng t`，`ng serve`来查看组件的运行情况，是由于在Agnular中我们并无法单独运行某个组件。所以若要运行组件，就必须将其放到某个**模块（Module）**中。 在运行`ng t`时，`TestBed`为我们提供一个测试**模块**，我们使用`declarations`将app组件放到了该**模块**，该模块虽然没有被显式的命名，但最后我们发现系统将命名为**DynamicTestModule**；在运行`ng serve`时，我们同样使用`declarations`将app组件放到了AppModule中。无论是**DynamicTestModule**还是**AppModule**它的本质都是模块，只能把组件放到模块中，才可以运行它。 ## 测试环境与开发环境 在发起数据请求时，我们在本章中分别为测试与开发测试引入了提供`HttpClient`的`HttpClientModule`，这说明测试与开发是完全独立的两个模块。即然是完全独立，那么它们便互不影响，互相透明。在一个模块中做的配置不会影响到另一个模块，所以如果想让某个配置在两个模块下分别生效时，需要设置两次。 当使用`ng serve`时，启用了开发环境，此时App组件属于App模块；当使用`ng t`时，启用了测试环境，此时App组件属于动态测试模块。App模块依赖于HttpClient，所以无论是开发环境还是测试环境，都需要在其启动的模块中引入提供`HttpClient`的`HttpClientModule`，否则将引发依赖注入错误异常。 当然了，你可能还总结了更多知识点，抽象出了这些点的共性。无论是理解对了还是错了，都将是我们当前的收获。只要自己总结的适用于当前所学，就是正确的学习方法。因为人类的正是在不断的证真、证伪中进步的。