1. 扁平的，面向数据的 state/props

扁平 props 也可以很好地清除组件正在使用的数据值。如果你传给组件一个对象但是你并不能清楚的知道对象内部的属性值，所以找出实际需要的数据值是来自组件具体的属性值则是额外的工作。state / props 还应该只包含组件渲染所需的数据（此外，对于数据繁重的应用程序，数据规范化可以带来巨大的好处，除了扁平化之外，你可能还需要考虑一些别的优化方法）。

2.更加纯粹的 State 变化

对 state 的更改通常应该响应某种事件，例如用户单击按钮或 API 的响应。此外它们不应该因为别的 state 的变化而做出响应，因为 state 之间这种关联可能会导致难以理解和维护的组件行为。state 变化应该没有副作用。

3.松耦合

组件的核心思想是它们是可复用的,为此要求它们必须具有功能性和完整性。

“耦合”是指实体彼此依赖的术语。

松散耦合的实体应该能够独立运行，而不依赖于其他模块。

就前端组件而言，耦合的主要部分是组件的功能依赖于其父级及其传递的 props 的多少，以及内部使用的子组件（当然还有引用的部分，如第三方模块或用户脚本）。

如果不是要设计需要服务于特定的一次性场景的组件，那么设计组件的最终目标是让它与父组件松散耦合，呈现更好的复用性，而不是受限于特定的上下文环境

4.辅助代码分离

一个有效的原则就是将辅助代码分离出来放在特定的地方，这样你在处理组件时就不必考虑这些。例如：

配置代码
假数据

5.及时模块化

我们在实际进行组件抽离工作的时候，需要考虑到不要过度的组件化
在决定是否将代码分开时，无论是 Javascript 逻辑还是抽离为新的组件，都需要考虑以下几点：

是否有足够的页面结构/逻辑来保证它？
代码重复（或可能重复）？
它会减少需要书写的模板吗？
性能会收到影响吗？
是否会在测试代码的所有部分时遇到问题？
是否有一个明确的理由？
这些好处是否超过了成本？

6.集中统一的状态管理

许多大型应用程序使用 Redux 或 Vuex 等状态管理工具（或者具有类似 React 中的 Context API 状态共享设置）。这意味着他们从 store 获得 props 而不是通过父级传递。在考虑组件的可重用性时，你不仅要考虑直接的父级中传递而来的 props，还要考虑 从 store 中获取到的 props。

由于将组件挂接到 store（或上下文）很容易并且无论组件的层次结构位置如何都可以完成，因此很容易在 store 和 web 应用的组件之间快速创建大量紧密耦合（不关心组件所处的层级）

react设计原理

单功能原则
  使用React的时候，组件或容器的代码在根本上必须只负责一块UI的功能。
我们不要定义一个具有许多功能的组件，这会导致组件的复杂性和难以维护，难以复用。
  一个比较合格的组件尽量保证在200行代码内完成。

单一数据源原则
  在分析一个组件内部数据的流动时，我们必须明确数据的来源和去向，以及相应的状态
我们不允许一个数据的存在多个来源。就如上面反模式中使用 prop 初始化组件状态一样，我们不允许组件内部的状态来源于props然后又受组件内部setState的控制。
尽量保持：
1）组件单方面接收props的变量，但不改变它；
2）组件内部维护state变量，外部组件不改变它。