这种二次封装的方式，并没有任何不妥。事实上，所有组件都是在基础的HTML组件上进行的二次封装。唯一需要注意的是，原有组件的开源协议(License)是否允许我们用在商业项目上，是否一定要开源。
即使我们直接使用第三方的UI库，也需要对UI组件进行封装，以隔离系统与组件间的依赖。未来，如果依赖的第三方组件库出现了问题，我们只需要替换组件层，不需要进行大规模的代码修改。
组件的二次封装不外乎两种模式，可以直接使用设计模式来说明：
1.中介者模式，用一个中介对象（中介者）来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。对于一个新组件，可以不加修改地直接引用原来的组件。例如，我们定义了一个<aofe-button>组件，它提供了与原来组件一致的属性、输入、和输出。在开发的时候，只需要引用原来的组件即可。未来即使再次替换成新的组件，也只需要引用<aofe-button>即可。
2.装饰者模式，在不改变原类文件及不使用继承的情况下，动态的将责任附加到对象上，从而实现动态拓展一个对象的功能。这种设计模式为原有的组件提供了我们需要的功能的接口，如果某个组件的属性、输入、和输出不符合API规范，那么我们就创建一个新的接口，来保证它符合规范。在未来，我们也不需要花费时间在修改代码上。我们仍然可以调用<aofe-button>这个组件，只是它支持了更多的输入和输出。
两种模式结合之下，我们就可以将原来的所有组件做一层代理。原来我们应该调用的组件接口是<react-xxx>，现在都改成了<aofe-xxx>。我们一旦决定对所有组件进行处理，就会产生新的模式。
釜底抽薪模式。如果有些组织想拥有自己的组件库，而当前又没有时间和精力，那么这种釜底抽薪的模式，倒也是颇为合适的。只需要在有余力的时候，一个接一个地替换原有的组件即可。随着时间的推移，我们便可以完成对所有组件的替换。而在这个过程中，它对于组件库的使用方法是无感知的，使用方只需要升级相应的版本即可--前提是，API兼容做的好。
在我们决定封装的那一刻，也决定了我们将编写一个新的组件库。
即使有了组件库，结合之前的风格指南，我们也难以设计出风格一致的系统。组件库存在的一个主要问题是，虽然它们提供了组件的概述，但是通常会给解释留下很多空间--组件可以以各种方式组合，看上去是一致的，但是从设计上来看是不一致的。因此，我们需要更多的东西来帮助我们构建出更一致的应用。