前端mv框架下(目前写的是vue),对组件抽象的思考

前沿:

  抽象是门大学问。前端mv框架中,以组件化的概念为主。经常会考虑抽象到组件级别,进行复用。合理的抽象,能提高效率,减少业务逻辑视图的耦合程度。不合理的抽象,则会增加代码的复杂程度。

遇到的问题

 合理的抽象是很难的,需要不断的思考,才能做到最合适的抽象。在b+项目中,遇到了一些问题。

  1、有些组件,ui和逻辑都可复用。ui抽象了,对应逻辑没抽。这样在复用这个组件的适合,逻辑部分的代码没有复用到,得另外复制粘贴一份。   

  2、有些组件,ui可复用,逻辑不可复用。抽象成一个组件,ui是实现了复用,但是业务逻辑得配置参数使用,导致switch case 无限增多。

我所理解的抽象思维:

  1、基础抽象,适用于所有的项目。

    首先,从功能的纬度去抽象。抽象一些具有某一特定功能的ui组件。比如说,button,日期选择器,列表等,这些都是具有特定功能的模块,单独可抽象为一个组件模块。这种抽象的最终结果就是最终能抽象出一整套ui库。例如elemntui,antd等。这一层是

  2、业务模块的抽象,根据业务逻辑判断。

    在具体项目中,除了从功能模块先抽象最基本的一层。还可以从业务逻辑的纬度去进行一层业务模块的抽象。判断可抽象的依据是,ui具有一致性且业务逻辑也一致性(主要判断条件)。一个的反面例子,假如有三个模块,每个模块的列表都是长得差不多,但是三个模块的业务逻辑是不一致的,比如说接口调的不一样。这种情况下,虽然ui很像,但是逻辑不一样,就不合适抽象组件进行复用。一个正面例子,假如有一个多个下注按钮,ui稍有不同,但是实现的逻辑都是下注。那么就适合做抽象。

总结:

  功能性逻辑情况有限,所有是可配置并可抽象的。业务型逻辑的情况可能无限,不合适去做配置实现抽象。所以,在业务中能抽象的必要条件是,业务逻辑必须具有一致性。如果ui也一致,则可抽象成组件。如果ui不一致,则单独抽象逻辑部分(这vue中可用minxins引入公共逻辑)。

上一篇:【一天一道LeetCode】#223. Rectangle Area


下一篇:关于android源码包下makefile编译以及使用STL库相关问题