基于MVC的范式写React应用

从大约两年前开始写 nautil,从一开始主要目标是创造一个跨平台开发的框架,现在来看,这个目标开始有所转变了。以前觉得跨平台开发是趋势,是一项重要工作,是亮点,但随着时间的推移,我越来越觉得,跨平台是一种技巧,而不是一种技术。在我长期以来的开发中,我逐渐意识到,项目工程的可靠性是团队/个人开发的重中之重。如何让一个项目的代码组织更加合理呢?特别是以 react 为基础的应用中,怎么去更好的组织码流(代码顺序和引用)?

代码写的多了以后,追求一种抽象的范式。所谓范式,是在方法范畴层面更广的风格。我发现在前端领域,react 和 angular 是两个极端,react 是只关注视图更新,不断深入,寻找各种方式提升视图更新性能,但是在工程性上完全放飞,性能代码量全部由开发者自己去处理。而 angular 反过来,它根本不关注(或者说不是卖点)视图更新问题,angular 沿用了 angularjs 时代的脏检查思路,只是做了优化,做到了没有 digest,只需要一次检查;而在工程性方面,angular 想尽一切办法约束开发者,因此,angular 的语法多得多,所以学习曲线比较漫长,但是我个人认为收益会很大,其中,引入 typescript 以静态类型语言的风格编写应用程序,会让应用更加健壮(但编程的灵活性降低,同时增加了类型编程的麻烦/乐趣),引入 rxjs 让事件处理从原始的 single push 模式升级为 multiple push 模式,增加了事件处理的灵活性;angular 具有 module 和 service 的概念,module 可以认为是一个业务模块(和 react 中的 component 概念相似但不同),包含该模块的所有信息,并通过工具进行解析构建;service 为模块提供处理能力,可以通过 angular 特殊的依赖注入完成比较魔法的写法。

而在 react 的生态中,除了 nextjs 比较知名外,还没有比较成熟的工程框架方案。而且 nextjs 走 ssr 路线,更像是以前的 php 换 nodejs 来过一遍,而非纯前端(运行时)的方案。于是,我想写一个框架来融合各种优秀理念(大部分其实还是我自己的),提供一种可靠的工程性框架的可能性。市面上其实也有一些自称为 react 框架的方案,比如 dva,但是实际上大部分 react+redux+react-router 的项目,就可以称自己为框架,但是,这类框架仍然停留在视图层编程的层面,没有上升为工程性框架,没有提供真正的编程范式。而写 nautil 之初是为了实现跨端开发,但是,随着慢慢深入开发,我发现 nautil 有可能成为真正的对标 angular 的 react 工程性框架

首先,前端应用需要区分数据、界面和事件,而类似 dva 之类的框架,你按照它的写法,永远只会写出把业务逻辑最终杂糅在视图组件中。没有区分数据和界面,是前端项目目前最大的问题。举一个简单的例子,在一段明显只描述业务逻辑的代码块中,你很容易找到一两句用来处理界面的代码,比如打开一个弹窗、颜色变化等。而 nautil 则首先要求开发者有分层的概念在里面,从代码层面看,就是有关业务的代码写在一个或多个文件中,有关界面的代码写在一个或多个文件中,这两者绝对不会出现直接的联系,这也就是 MVC 中的 M 和 V,同时,需要有一个东西将它们串联起来,也就是 C。在 nautil 中编程,很像传统的 MVC 编程,需要写 .model.js, .controller.js,看上去又回到了 MVC 的老路,但是有一点,这里我们避免了一些坑,我们不可能直接照搬后端的 MVC 概念,后端的 C 才是请求的入口,而在前端 V 才是入口。所以在前端 module 中必须存在视图组建,但可以不存在 controller 和 model。

其次,关于事件,我认为是大部分前端容易忽略的一个点,很多人认为事件就是事件,很简单,没必要整那么复杂。但是在实际开发中,事件几乎串联了所有业务和交互,可以说,没有事件处理就没有这个应用。但是大部分编程,都只有事件回调函数,在 react 中通过 on 开头的一些回调来获得 DOM 的事件回调。但是,回调函数的方式比较钝,当一个动作可能引发一连串非线性的反应的时候,回调函数是不可能解决的。举个例子,比如我们有一个场景,当用户点击 A 时弹出一个弹框,当点击 B 时需要先放大 B 元素然后再相当于点击 A。这里点击 B 就是一个会带来一连串非线性的反应的场景,在 jquery 时代,我们可以通过 trigger A 的 click 来达到这个目的,但是在 react 中,我们无法做到这个效果。而在 nautil 中,我引入了 rxjs 来解决事件处理。普通的回调函数是 single push 模式,只能处理单一线性的任务,而 rxjs 是 multiple push 模式,可以处理多向离散任务,同时,由于 rxjs 的 Subject 既是观察者也是被观察者,所以多个事件之间可以轻松串联起来。在 v0.30 之前,我在 Component 中使用 on/off/emit 作为事件的处理工具,但是这种命名仍然是传统的事件注册与回调的意味,因此,我改为了 subscribe/unsubscribe/dispatch,虽然只是名字的改变,但体现了事件流处理的理念的转变。

最后,Controller 的发明也是非常有意思。一个 controller 观察模型,保管一些用于完成事件到数据交互的组件,这些组件只完成交互(事件->数据),而不完成布局和样式,所以细小碎片化,但是却形成了另外一种模式:业务不仅包含数据描述,还包含交互描述。通过 Model+Controller,我们可以很好的还原需求文档中有关业务逻辑的描述(一般需求文档除了描述业务数据本身,还会描述用户的某一个交互所带来的数据变化,而在这个描述中,往往还没有给出具体的界面效果)。所以,在我看来,一个 Controller 其实是一个交互模型,这个交互模型的基础,就是拥有基于 rxjs 的事件流管理机制。基于这种思想,一个 module 除了视图组件和样式文件之外,其他的都是模型(包括 Service 在内,因为它为业务服务)。只有视图组件是为界面服务的,这就导致我们的开发方式与以往的 react 开发方式具有极大的不同,这个不同非常非常大!可以说,视图组件的编写,只占到整个应用的一小部分,而真正的大头应该是在 Model+Controller 上,这也符合我们对“业务系统的重点是这实现业务”的朴素认知。

2021 年已经 5 月了,今年我做 Robust 的期数特别少,因为手上的工作比较多,同时,我也逐渐发现,要完成一些具有挑战的项目逻辑是比较困难的,不是有了想法和行动,就能做到尽善尽美,特殊的场景实在太多了,想要做一个完完全全通用化的功能模块,几乎是不可能的,这也意味着,未来还有很长的路要走,而且是不可替代的。

已有3条评论
  1. 1188 2021-05-07 13:35

    nautil看着确实有意思, 有能跑起来的demo吗

    • 否子戈 2021-05-07 13:49

      打算写一个 beautiful-admin 的 demo,有什么建议么?

      • 1188 2021-05-08 13:51

        希望能尽量简单点, 方便理解其中的各种概念.