组件设计原则
- 统一技术栈。
- 单一职责，一个组件只专注做一件事。
- 追求无副作用，输入一但确定，输出就是固定的。
- 可配置，一个组件要明确它的输入和输出分别是什么，同时入口处检查参数的有效性。
- 粒度适中，划分粒度的大小需要根据实际情况权衡，太小会提升维护成本，太大又不够灵活和高复用性。每一个组件都应该有其独特的划分目的的，有的是为了实现复用，有的是为了封装复杂度，实现业务清晰的目的。
- 适当的包体大小，便于页面快速加载。
- 完善的使用说明文档。
组件化的目标
- 代码复用，提升开发效率 根据业务特点，横向和纵向划分组件，以组件为单位承接业务需求。虽然以 UI 组件为主，但对于相对独立的功能，也进行了纵向的组件抽取。
- 组件独立开发维护，与各项目解耦 组件单独开发、调试、发布，供业务方调用，业务方只需专注业务本身。 更方便的组件调用，更合理的路由跳转 组件调用需明确输入、输出参数，并对参数进行校验并给出合理错误提示。
- 组件文档化，降低组件使用门槛 组件库需要有完善的使用说明文档，使业务方更加容易、便捷的使用。
研发设计规范
有以下5部分。
第一，KISS（Keep It Simple And Stupid）原则。它的核心理念是让代码尽可能简单，并且保持代码的可读性。开发人员判断组件是否符合KISS原则的关键并不是代码量，而是代码的可读性。如果代码可读性很好，使用者能在短时间内看懂，就说明该组件符合KISS原则。在大多数情况下，开发人员可以通过遵守代码规范、对函数进行清晰易懂的命名，以及添加说明性注释等方法来提高代码可读性。
第二，YAGNI（You Ain’t Gonna Need It）原则。它的核心理念是不要过度设计。例如，开发人员不要设计当前用不到的功能；不要编写当前用不到的代码。代码可以根据业务情况预留扩展点，但是不需要提前实现这些功能。
第三，DRY（Don’t Repeat Yourself）原则。它的核心理念是提高组件的复用性。同样功能的代码逻辑，只应该被实现一次。开发人员应该将公共部分抽象出来作为工具函数，从而提高代码的复用性和可维护性。例如，在大多数情况下，分子组件中的原子组件可以作为公共部分进行抽象，从而有效提高组件复用性。
第四，LOD（Law Of Demeter）原则。它的核心理念是降低组件之间的耦合性，尽量做到能不依赖就不依赖。如果需要依赖，那么也应该尽可能依赖抽象部分，保持依赖关系上的松耦合。如果能够保持松耦合，当依赖部分发生变更时就能够将影响降至最低。即便是不兼容式改动，开发人员也能以最低成本迁移。
第五，SRP（Single Responsibility Principle）原则。它的核心理念是一个组件应该只关注一个功能点。如果违反了该原则，就会导致组件内部出现大量的逻辑分支，从而使得逻辑混乱，组件难以拓展和维护。