react项目代码结构

总述：

1.各人的代码彻底分开，创建自己的api文件、组件文件夹、仓库文件夹、页面文件夹、工具函数文件等，仅保留极其少的公共文件

2.各人写的代码负责到底，实现方式充分发挥创造性，框架不限制具体实现方式

3.为什么不按业务组织代码，而是按人组织代码？

1）页面完全按业务组织代码，也是最应该组织的

2）api是一个没有逻辑的js文件，类似于目前项目中的css文件，无论怎么组织都不是瓶颈

3）组件类似于一个自定义ui库，不和业务挂钩，自定义组织方式

4）仓库可以按业务组织代码，也可以按人组织代码，也可以按其他形式组织代码，这块字段特别少，不是瓶颈。如果这块字段特别多，首先需要重新考虑一下你的设计，而不是如何组织他。如果故意设计这么多字段，那要分析仓库自身的逻辑，再考虑如何组织代码。这块其实是完全独立的，类似于apple的appStore，可以随意组织，便于使用即可。

如果一个公司有100个前端如果组织开展工作？

1.100人分成10组，1组10人

2.使用react脚手架创建10个项目，分别传到10个git仓库，分头开发

3.做一个首页，上面有10个链接，可以链接到这10个项目

4.团队之间如何共享代码？可以使用npm共享代码。建议使用已经比较成熟的技术库，而不是自己团队开发公共的代码库

自己负责的业务如何全部交接给另一个人？

页面部分并没有什么特殊的，正常接手即可。api文件没有逻辑，略过。重点是自己封装的组件和自己负责的仓库。回想一下我们是如何“接手”antd里的ui组件的。既然已经有antd ui组件了，我们为什么要自己封装的ui组件呢？原因很简单，antd的组件不能满足需求。自己封装的组件好使吗？其他人员会使用我的组件吗？有bug吗？升级了怎么办，向下兼容吗？有在线文档吗？在github上star过万了吗？继续写bug吧，别做梦了。

解决方案：

自己封装的ui组件从使用方式上看类似于antd,但是质量是很差的。react组件就是一个函数，一个函数只做一件事，并且把他做好就行了。接手的人可以随意修改你的函数，也可以创建一个类似的函数，能用的就用，不能用的删了就得了。这就是解决方案。仓库的核心是actionCreator.js里处理异步的函数，处理方式和自定义组件一样。