前端代码中,哪些可以抽象,哪些不可以?

抽象的目的绝对不是复用,而是为了清晰的设计。从某种意义上讲,抽象分为两种,一种是绝对抽象,只有神态,没有实体,另一种是轮廓抽象,或者半抽象,有了基本的架子,留下空间去具体化。前一种我们常称之为接口interface,后一种我们常称之为抽象类abstract class。对于前端代码而言,在传统前端开发模式中,不存在这两种中的任何一种,对于abstract class则可能存在一些雏形,例如:

class Some {
stay() {
throw new Error('stay should be overrided')
}
}

此类处理虽然可行,但是在最终代码中会多出来许多没有用的代码,增加代码量。只有在我们引入ts之后,才有了真正的抽象代码。例如:

abstract class Some {
abstract stay(): void
}

这段代码定义了一个抽象类,它不能被new实例化,只能被extends扩展。扩展时,带有abstract前缀的成员必须被实现,否则编译阶段会报错,而在最终生成的代码中,不存在这些abstract成员,这样就可以使代码量最小化。

在具体业务中,哪些内容可以抽象,哪些不可以呢?

其实对于前端而言,基于interface的抽象(业务层面)几乎没有,我们很少会去写一个用于描述业务的interface,而且这完全没有必要。我们大部分情况下使用abstract class进行抽象,甚至在大部分情况下,不需要abstract,直接使用class进行抽象。这里抽象脱离了技术层面的抽象,而是对业务进行抽象,同时由于大部分前端场景中,同一业务是固定不变的,因此,这类抽象可以被具体实现。例如对于同一对象实体,我们直接对其进行建模。再例如,我们直接对数据请求进行建模。对于数据的操作,我们进行建模。总之,你会发现,抛开界面和交互的一切,都是可以进行建模处理的,这个部分全部可以抽象出来,在代码中形成一块封闭的可扩展的代码块,需要时被取出来使用,不需要时不import,对当前毫无影响。

最麻烦的是界面和交互的抽象。

先看下交互的抽象,由于交互动作往往会引起界面的变化,所以我们在对交互进行建模时,就必须预留下可产生界面变化的abstract成员,从而可以使界面产生变化。例如:

abstract class SomeView extends View {
@inject(SomeController)
controller: SomeController

abstract confirm(message: string, onOk: Function): void

deleteItem(id) {
this.confirm('确定删除吗?', () => {
// 执行删除
})
}
}

上面代码中,我们预留了一个confirm方法,对于具体的某个view而言,必须扩展这个confirm方法来,为什么要留呢?因为confirm往往需要弹出一个对话框,同时,这个对话框一定是一个中间态,用户点击它的按钮之后,一定还会有后续界面变化。这种界面的流动过程,无法通过简单的处理来实现。当然,如果你想具体化,还可以借助react的state,例如:

class SomeView extends View {
state = {
showConfirm: false,
deleteItemId: null,
}

deleteItem(id) {
this.setState({ showConfirm: true, deleteItemId: id })
}

handleDeleteItem() {
// 执行删除动作
}
}

通过以上方式确实可以做到提供完整的动作,但是这就意味着必须按照react的状态管理模式进行编程,而且对于使用方来说,一个动作的方法太多了,在实现时,不仅要调用deleteItem还要再调用handleDeleteItem。不过,从另外一个角度看,这似乎又是正确的一种做法。

最后看下界面的抽象。这个时最难的,因为不同端端界面呈现是不一样的。比如PC和APP上。但是我们也不是不能做,其前提是开发者,或者项目的架构师,在前期规划了非常细腻的业务组件,我们所有的业务开发,基于已有的业务组件进行,我们写代码,更想写配置或DSL,比如下面:

<Page>
<ProjectBasicInfo />
<ProjectMembers />
<ProjectDeals />
<Tabs>
<CompanyInfo />
<FinancingInfo />
</Tabs>
</Page>

这样一段代码,更像是一个页面的结构描述,至于每一个部分都具体展示什么内容,怎么展示,界面交互怎样,PC和APP上的差异,全靠业务组件内自己去实现,通过这种方式来进行界面的抽象,可以最大程度的抹平不同端的差异,但是对团队和架构师的要求会比较高,当然收益也是显而易见的,就是效率很高。