组件开发中，如何将数据和UI解耦，是最重要的工作。
组件开发过程中，时刻谨记、思考是否符合以下的原则，可以帮助你开发一个更完善的通用组件。
你的组件是否符合只实现一个职责，并且只有一个改变状态的理由？
如fetch请求和渲染逻辑，应该分离。因为fetch请求时会造成组件重新渲染，渲染时的样式或数据格式变化，也会引起组件重新渲染。
单一职责可以保证组件是最细的粒度，且有利于复用。但太细的粒度有时又会造成组件的碎片化。
因此单一职责组件要建立在可复用的基础上，对于不可复用的单一职责组件，我们仅仅作为独立组件的内部组件即可。
组件开发要服务于业务，为了更好的复用，又要从业务中抽离。
下面代码实现了需求A：实现一个基础的select组件：menu：是select的下拉列表，menu上面的div是select的选择框头部，包含一个值和一个箭头。
虽然B的交互模式和A一模一样，但因为二者在DOM结构上的巨大差别，导致我们无法复用上面的这个Select来实现它。只能去修改源代码、或重新写一个符合需求的组件。
因此组件开发时最好的做法是放弃对DOM的掌控，只提供最基础的DOM、交互逻辑，将DOM的结构转移给开发者。
下面的代码是Antd的组件DropDown，可以看到只有最基础的DOM，提供了多个渲染函数和处理逻辑。
减少访问全局变量：因为它们打破了封装，创造了不可预测的行为，并且使测试变得困难。可以将全局变量作为组件的props，而不是直接引用。
我们想要实现一个Table组件，Table组件包含行数(RowCount)、header、body。
Table的数据源data、行数RowCount，都来自props；Table内部的排序函数，需要的状态sortPerperty、ascending来自state；
Table的操作包括onRowClick，来自props；排序setSortProperty，来自state；
UML类图如下所示，可以直观的了解组件的UI层结构，数据流动和处理函数，写代码时再也不怕会重构了^_^
为了让下一个接手的同事更好的理解代码，我们有时会在核心代码中，添加必要的注释，让代码更清晰。
letparams={pageNum:pageNum,pageSize:pageSize,status:4,//参照：ROBOT_STATUS,0-新导入，1-审核中，2-审核通过，3-审核未通过，4-上架，5-下架title:search,queryType:0//0--只查询列表，1--查询申请状态};代码如上，阅读代码时，你能快速了解各个字段的含义，但你会额外分心去看注释，思路被打倒，导致中断了整个函数的逻辑分析。
因此，假数据、非技术说明文档、配置代码，建议放在代码外，而不要放在核心代码中，会影响用户体验。
给组件传递props时，建议用更扁平化的props，而不要用嵌套的对象或数组。