绕过技术聊"跨端"......

1,314 阅读4分钟

我正在参加跨端技术专题征文活动,详情查看:juejin.cn/post/710123…

开门见山,我知道有很多业界大佬或组织深耕在跨端开发领域中,小弟才疏学浅,就不在技术层面故作姿态了,今天跟大家绕过技术、仅从架构思想上聊跨端开发。

跨端的本质是复用

跨端开发很难吗?一点都不难,你财大气粗可以每个端都招一组人马开发就得了,多少端都不是事儿。所以我们在此聊的跨端其实是如何节省人力成本、时间成本而进行“跨端复用”。

这是一个开放的话题,不只是开发技术上可以聊,架构思想上可以聊,甚至团队管理、资源分配上也可以聊...

为什么不能跨端

我们回头想想应用为什么不能跨端呢?思维逻辑是无国界的,你可以借助任何一种语言来描述与表达,而Javascript运行时又被多种运行平台广泛支持,按理说跨端应当不难呀。

这个魔障就是UI/UE,这是一个感性的东西、它灵活多变、不但不存在标准反而还追求个性。各端都坚守自己用户习惯、设计风格、传统文化、个性表现、默认优化、方言约定等等,这已经不是技术范畴的事了,即便你强行抹平了,也只能顾此失彼...

为什么后端接口不需要跨端开发?(即便需要也仅仅是个BFF适配层)。因为后端是面向业务逻辑的开发,而前端是面向UI界面的开发。

所以最简单的跨端思路就是:

直面UI的个性化,把这层基于感性的、非标准的东西剥离出来,并尽可能削薄它。

从理想主义到现实主义

虽然Write once run anywhere...是很多人追求的梦想,但我不推崇它,因为即便是你做到了,你也可能失去平台优化、失去个性色彩、在平台生态中沦为二等公民。

那么退而求其次Learn Once, Write Anywhere...,不追求那么完美,能复用业务逻辑解题思路应用骨架核心代码,也是知足常乐的。

从业务逻辑到领域模型

应用的核心是什么?是游戏规则,是业务逻辑,一个应用不管运行平台怎么变化,它的业务逻辑总是通行不变的。 如果我们再进一步对业务逻辑进行领域建模,去掉那些花里胡哨的修饰、让业务模型变得抽象、纯粹、精炼,那么我们将得到一个最有价值的、最稳定坚固的、放之四海而皆可行的核心逻辑。

至于UI表现要个性化?要平台化?那就重新作件漂亮的外衣呗...

model-reusable.jpg

UI的职能

UI的职责只有2个:输入与输出,仅此而已。它是指令的收集者和结果的反馈者,而不应当成为指令的执行者。

当你秉承这个思路,那么UI层/UI框架就无足轻重了。我前几天发过一篇文章:炮打司令部,别让一个UI框架把你毁了,阐述了前端过度依赖UI框架,把UI框架当成应用的骨架,从而导致代码混乱,耦合紧密、更使你的应用失去通用性。

怎么落地

最关键的就是要分层架构,解耦UI逻辑和业务逻辑、写薄UI层:

  • 首先,可以借助于一个跨平台的MVC框架分层而治。
  • 其次,编写代码的时候注意不要再面向UI事件了,改为面向业务动作。
  • 最后,将业务逻辑从UI层中彻底移出。

具体做法可以参考:炮打司令部,别让一个UI框架把你毁了,主要就是:

  • 从 State 到 Model
  • 从 Event 到 Action

实例演示

最后,为了证明这种思想并非纸上谈兵,可以看看我的开源框架:Elux-基于“微模块”和“模型驱动”的跨平台、跨框架『同构方案』,正是基于以上思想而设计。可以使用React/Vue/其它第三方框架,可以用来开发:Web(浏览器)、Micro(微前端)、SSR(服务器渲染)、MP(小程序)、APP(手机应用)。

安装方法:

npm create elux@latest 或 yarn create elux

小程序开发默认使用的TaroJS,原理是把TaroJS当成一个第三方UI框架,理论上uni-app或是其他也是可以接入的:

@elux/cli-init@2.1.1
新建项目: /Users/hiisea/work/elux/aaa
totally [44P] templates are pulled from ...

? 请选择平台架构 
  CSR: 基于浏览器渲染的应用 [16P] 
  SSR: 基于服务器渲染 + 浏览器渲染的同构应用 [8P] 
  Micro: 基于Webpack5的微前端 + 微模块方案 [8P] 
❯ Taro: 基于Taro的跨平台应用(各类小程序) [8P] 
  RN: 基于ReactNative的原生APP(开发中...) [4P] 

抛砖引玉,你也许不会真的使用它,但它或许能给你带来新思路...