浅谈web前端 隔离:二次封装

WinerChopin 2020-06-03

在一个成熟的项目里,自己开发组件是一种方式。另一种方式,则是使用现成的组件。可是现成的组件往往也不一定能满足我们的需求。如果没有满足自己的“轮子”,那么就造一个。而许多时候,我们也不需要自己去创造一个“轮子”,直接在别人提供的组件上,添加自己需要的特性,便可以完成自己的功能。

这种二次封装的方式,并没有任何不妥。事实上,所有组件都是在基础的HTML组件上进行的二次封装。唯一需要注意的是,原有组件的开源协议(License)是否允许我们用在商业项目上,是否一定要开源。
即使我们直接使用第三方的UI库,也需要对UI组件进行封装,以隔离系统与组件间的依赖。未来,如果依赖的第三方组件库出现了问题,我们只需要替换组件层,不需要进行大规模的代码修改。

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

相关推荐