无视图交互模型,用代码完成需求文档的模型化描述

在工作中,不同开发者思维方式不同,低级开发者需要等到设计稿完成之后,才能启动开发,中级开发者会根据交互稿利用系统风格就可以启动开发,而高级开发者,从参与需求讨论开始,就可以开始启动开发了。是什么让开发者无需在视图界面的引导下,就可以完成部分编程呢?模型!

模型化描述系统

模型,是现实客观事物的抽象和表示。一类事物,所拥有的共性,经过抽象后以代码的形式进行描述,就是模型。以模型的方式描述一类事物形成的体系,就是模型化描述系统。在描述事物过程中,我们往往需要在模型中提供事物共性的各个因子,因子的自身特性,以及因子与因子之间的联系。

在前端语境中,我们很少讲模型,因此,我们只能从能看到的界面开始编程。缺乏对业务对象的抽象能力,导致前端工作者在具体业务中,“只是一个画界面的”,而不能参与到真正的业务推动中,而很多前端工作者也认为,这个部分是后端人员的工作,导致工作中对业务一知半解,bug层出。

构建前端业务对象模型,不需要特别复杂的设计,用class就可以构建了,例如:

class GoodNameMeta extends Meta {
  default = ''
  type = String
  maxLength = 50
}

class GoodPriceMeta extends Meta {
  default = 0
  type = Number
  min = 0
}

class GoodModel extends Model {
  static name = GoodNameMeta
  static price = GoodPriceMeta

  increasePrice(inc) {
    this.price += inc
  }
}

在这个代码中我们定义了一个商品的模型,拥有 name, price 两个字段,在前面,这两个字段的具体规则也通过 Meta 进行了定义。

在模型中,有时候会打破字段与字段的边界。例如,a 字段对 b 字段有依赖,当 b 字段的值发生变化时,a 字段也应该发生响应的变化。这种逻辑应该在哪里定义呢?看上去,我们应该在模型块内进行某种逻辑设计,为了自动完成这个联动效果,还需要做一些联动设计。但是,如果讲关于 a 字段的逻辑,从 a 字段的定义集合中脱离出来,那么,单纯阅读 a 字段的 meta,就无法真正阅读出它的全貌。因此,在模型设计时,我们以模型因子为单元,进行最基础的编程设计。

无视图交互模型

我们面对设计稿,可以做视图层编程。但是,在大部分设计稿中,并不能动态的描述用户交互的效果。也就是说,设计稿也不是万能的,还要结合交互稿才能明白具体某些细节的全部面貌。但是,有的时候更坑,设计稿交互稿都没有反应某些细节全貌,必须阅读需求文档才能复原其全貌。我们怎么应对这种情况,或者说,我们怎么在即使没有视觉稿的情况下,也可以完成部分编程?

通过对需求文档中的具体描述,进行模型化描述,从而完成在无视图的情况下的代码构建。比如,需求文档中提到,“点击该按钮时,该商品被加入到购物车中”这样一句话。那么,我们怎么把这个需求点实现为代码呢?

class GoodDetailController extends Controller {
  static good = GoodModel
  shoppingCart = ShoppingCart.get()

  ShoppingCartButton(props) {
    return [
      'button',
      {
        onClick: () => this.shoppingCart.addGood(this.good)
      },
    ]
  }
}

在这个模型中,包含了“商品”“购物车”“按钮”三个因子,其中购物车是全局实例,通过 get() 获取。在这段描述中,没有视图层面的编程,但是,我们完成了对需求文案的描述,并且开发者也很容易读懂。

在 ShoppingCartButton 中,我返回了一个可被 React.createElement 使用的数组,用以表示该描述的实际逻辑。也就是说,在无视图交互模型中,并非完全不考虑视图层,而是暂时不考虑视图层的布局、样式、动效等,只对交互对象的交互效果产生的业务逻辑(而非交互逻辑)进行描述。另外,交互模型的功用是为视图层提供封装好的交互逻辑,因此,它本身应该具备响应式能力,当其所持有的状态发生变化时,自动更新视图,而视图更多是对状态的反应和用户输入事件的反应。

事件流

“视图是对状态的表示”,是当代前端的一个重要范式,也就是公式“UI=f(state)”。这个范式影响了我们前端开发的大部分场景。但是在这个公式中,存在缺陷,UI 只受控于 state,当 state 发生变化时,UI 也随之变化。问题在于,state 为什么会发生变化?在前端语境下,引起 state 变化的大部分原因,是用户的交互行为,也就是点击、输入等事件。大部分情况下,开发者认为事件一定是来自 UI 的,这是一种误解。实际上,事件本身并不是 UI 的一部分,只是,在前端场景下,我们应用的入口都是界面,所以用户的操作,也基本上是在界面上完成。除了用户在界面上的操作事件外,由定时任务、websocket等系统预设产生的事件,也会带来 state 的变化,因此,可以将公式进行展开,即“UI=f(Event)(state)”,其中 f(Event) 是对事件的编程过程,而 f(Event) 才组成了上面 f(state) 中的 f,即对 state 进行操作的处理逻辑,在 react 环境中,我们可以认为 f=react,也就是“UI=react(Event)(state)”。用户交互事件虽然是在界面上产生,但是 UI 仅仅只是提供了一个窗口,事件并非 UI 的一部分,也就是说,理论上,UI 编程不应该包含事件相关的编程。

那么,我究竟应该怎么看到“事件”这个东西?

RxJS 是我一直喜欢的一种事件编程的方式。通过事件流的形式,我们将事件处理独立出来,不再像以前一样,依附或混杂在 UI 编程中。当然,除了 rxjs 之外,还有其他方式管理事件到 state 的这个过程,比如 xstate。但是,在我这里,通过 rxjs 提供的这套编程思维,可以帮助我解决很多问题。通过对“事件”本身进行抽象,你会发现,我们口口声声说的“事件”,其实包含了多个过程:事件触发->事件处理->事件影响。在我们以前的编程中,我们基本上用一个事件监听的回调函数完成上述整个过程。但是,实际上这些过程是可以拆解的,经过拆解后,事件本身的编程就成为一套独立体系,和 UI 编程完全分开来,再结合上一节无视图交互模型,我们会发现,我们不再需要再在 UI 编程中处理和业务相关的事件逻辑(和交互相关的事件逻辑还是需要处理,比如需要处理渐隐渐显效果、拖拽效果、移动效果等)

class GoodDetailController extends Controller {
  static good = GoodModel
  shoppingCart = ShoppingCart.get()

  static addToShoppingCart$(stream) {
    stream.pipe(take(4)).subscribe(() => {
      this.shoppingCart.addGood(this.good)
    })
  }

  ShoppingCartButton(props) {
    return [
      'button',
      {
        onHit: this.addToShoppingCart$,
      },
    ]
  }
}

注意看 this.addToShoppingCart$ 这个流,我直接将它绑定到 onHit 上,当这个按钮被点击时,就会触发这个流,那么就会走流的管道逻辑,最后,再在它的 subscribe 中,对当前交互模型上的状态进行修改,修改后,就会通过内置的逻辑,触发视图的更新。通过 rxjs 的算子,可以实现形式非常复杂,但是代码却很简单的事件流处理。我们可以自己将计算过程进行拆解和抽离,通过算子的形式,交给不同的 stream 去处理。我在实现时,用 rxjs 的 Subject 实现,所以,stream 之间的串联也很方便,例如 a$.subscribe(b$),这样就可以让事件触发脱离原始的 UI,通过事件串联另外一个事件,让事件触发也可被复用。例如:

class GoodDetailController extends Controller {
  static update$() { ... }
  static start$(stream) {
    stream.pipe(...).subscribe(...)
    stream.subscribe(this.update$) // 当 start$ 被触发时,update$ 也会被触发
  }
}

结语

我在 2019 年初的时候,在内部分享中梳理了前端框架的发展,当时,我认为对事件的缺失是当代框架的一个缺陷,下一阶段的框架会补足这一部分,认为类似 cycle.js 这样的框架会火。但是当时我忽视了一点,即前端开发的窗入口一定是视图层,一切不从视图层出发的框架,都会碰一鼻子灰,除非这个框架不以创建界面为目标。但是我用了很久的事件,都没有找到一个方法,将事件这个逻辑从 UI 编程中抽离出来,直到今年,才终于解决这个问题,弥补了当初对整个前端框架编程的勾勒。

在实际编程中,我并不确定这种真正符合 MVC 的编程方式是否会被接受,因为在前端中,不同层次的开发者接受不同方式的程度也是不同的,如果可以直接通过 V 层编程完成,有些人是永远不会用 MVC 的。但是,我相信,在适合的场景条件下,真正的 MVC,将会对项目长期维护带来非常大的裨益。

2021-01-02 155 , ,

为价值买单

本文价值1.55RMB