共计 2343 个字符，预计需要花费 6 分钟才能阅读完成。
一个基于 React16、Antd、Mobx、Typescript 的前端脚手架。
传送地址：https://github.com/pablezhang/template-for-ts-react
为什么是 template-for-ts-react
目前市面上曾经有 create-react-app 等开箱即用的脚手架，但 create-react-app 一方面没有默认反对 typescript，另一方面，大量的的我的项目实际中，咱们曾经将Typescript、React16、Mobx、Antd 作为 React 我的项目的最佳实际。因而，咱们开始了这个我的项目，并把大量的后盾管理系统实际逐教训渐退出本我的项目中，咱们心愿该我的项目能够为后盾管理系统，提供一个疾速启动的脚手架、设计良好的模块实际。如果你对我的项目中有优良的倡议，欢送分割咱们。
src 文件目录构造
├─ App <br/>
├─ assets <br/>
├─ components <br/>
├─ packages <br/>
├─ pages <br/>
├─ services <br/>
├─ styles <br/>
├─ utils <br/>
├─ widget <br/>
├─ router.ts <br/>
Note<br/>
App —- 我的项目入口文件夹
assets —- 动态资源文件将爱
config —- 在代码逻辑中会重复读取并且只可读取的内容，如不同环境下的后盾服务地址、cookie中的要害 keyName 等等
packages —- 独立功能模块，通常除了第三方包，它不应该依赖任何模块。随着我的项目体量的逐步增大，它能够逐渐从我的项目中拆散成为一个独立存在的公有或私有的第三方包。
pages —- 页面文件：页面级组件，通常状况下咱们倡议一条 route 对应一个 page 文件夹，并且 route 名称与 page 名称保持一致。
services —- 零碎接口文件，咱们须要将零碎中所有用到的申请隔离在 services 文件夹下各个接口文件中。目标是，防止后盾接口变动而咱们需在在代码逻辑中追随更改。咱们将在下方具体阐明咱们设计理由。如果你看到了 ExampleService.ts 的内容感觉很奇怪，别着急，咱们会同样给出这么做的起因，也不要放心会加大你的工作量，咱们同样给出解决方案。
style —- 全局款式文件夹：全零碎的通用款式文件，如你的 theme.less common.less 等
utils —- 通用功能模块：通常是逻辑固定、大量复用的功能模块，如 request.ts、PinYin.ts 等固定输出固定输入的污浊功能模块
widget —- 部件模块：通常是固定不变的、没有性能逻辑的组件，如 Footer、Header 等 UI 组件。
router.ts —- 前端路由定义文件
接口隔离
设想你在工作中是否遇到过这样的场景：
接到需要后，前后端各自开发对应性能，2 天后汇报进度，后盾同学：”后端性能做好了，就等前端联调了“，前端同学：“前端性能做好了，就剩跟后盾联调了”。产品经理、项目经理听后大喜，向上汇报进度，前后端性能进度实现 80%。2 天后产品经理迟迟未收到提测邮件，去找前后端同学，发现他们还在联调，前端同学冤屈的说到：“后盾的接口有问题须要改接口或者改参数。同一个接口在 3 个页面里调用过，后端同学改一个 url，前端须要批改 3 个页面里的 url，并且再提交再公布，再测试”。
在这里不探讨前后端如何高效合作的问题。思考下前端在这种情景下，有哪些状况是能够防止的。把前端、后端别离看成两个功能模块 A 和 B 的情景，此时 A 依赖 B，而 B 并不依赖 A，同时 B 对外裸露的性能可能是变动的。此时咱们须要思考两个状况，1、B 提供的性能可能是变动的，咱们须要随时应答这种变动。2、咱们齐全不晓得 B 变动的可能性。应对于此，咱们须要将变动的局部隔离进来，将固定的局部封装起来。
思考下 Socket 通信，Socket两端不必思考对方是什么样的情景，Service设计的目标也是基于此，不管后盾接口的 url、参数如何变动，咱们的调用形式是不变的，如 ExampleService.getExampleList(...restPara)。
在一个用户治理的性能里，以后端须要删除一个用户时，前端的代码逻辑应该是：调用删除接口 –> 删除胜利 / 失败 –> 提醒并刷新。而不应该关怀这个接口 url 是什么，参数是什么。依据迪米特法令，咱们的性能应该只负责调用接口，不关怀如何调用到后盾的接口。至于参数，咱们应该尽早提前约定，或者预判须要参数。此时应答上述场景，咱们只须要批改 Service 文件即可，不必批改逻辑代码文件。
另外一个场景
在工作中，后盾同学提供了一份 swagger 接口文档。前端同学每次查问该文档调用某个接口。相当于，咱们从 swagger-ui 上摘录接口应用办法，设想大家在开发过程中是否遇到过以下问题：
- 调用接口发现接口报 404，费神费劲查看发现把单词拼错了~
- 调用接口发现接口报 400，认真比照 swagger 发现参数类型写错、参数名称写错~
- 一时粗心把申请类型写错了~
如果有 10 位开发同学调用过同一个接口，上述的犯错情景的次数会被放大 10 倍，重大节约前端的开发工夫。如果后盾须要批改某一个接口，他可能要告诉 10 个前端，或者某些情景下不敢批改该接口。因而咱们要将这些变动、机械抄录的内容隔离在
Service文件中。
主动感知接口
如果须要手动抄录 swagger 接口文件并保留在前端，这无疑是一个既无聊干燥又无人愿意的 ”dirty work”，而 auto-swagger 正是为了解决这种状况而呈现的，应用 auto-swagger 你能够在几秒内获取到全副的接口文件，而后盾接口变动时，咱们又能够很及时感知到接口产生了变动。