绕过技术聊"跨端"......
开门见山,我知道有很多业界大佬或组织深耕在跨端开发领域中,小弟才疏学浅,就不在技术层面故作姿态了,今天跟大家绕过技术、仅从架构思想上聊跨端开发。
跨端的本质是复用
跨端开发很难吗?一点都不难,你财大气粗可以每个端都招一组人马开发就得了,多少端都不是事儿。所以我们在此聊的跨端其实是如何节省人力成本、时间成本而进行“跨端复用”。
这是一个开放的话题,不只是开发技术上可以聊,架构思想上可以聊,甚至团队管理、资源分配上也可以聊...
为什么不能跨端
我们回头想想应用为什么不能跨端呢?思维逻辑是无国界的,你可以借助任何一种语言来描述与表达,而 Javascript 运行时又被多种运行平台广泛支持,按理说跨端应当不难呀。
这个魔障就是 UI/UE,这是一个感性的东西、它灵活多变、不但不存在标准反而还追求个性。各端都坚守自己用户习惯、设计风格、传统文化、个性表现、默认优化、方言约定等等,这已经不是技术范畴的事了,即便你强行抹平了,也只能顾此失彼...
为什么后端接口不需要跨端开发?(即便需要也仅仅是个 BFF 适配层)。因为后端是面向业务逻辑的开发,而前端是面向 UI 界面的开发。
所以最简单的跨端思路就是:
直面 UI 的个性化,把这层基于感性的、非标准的东西剥离出来,并尽可能削薄它。
从理想主义到现实主义
虽然Write once run anywhere...
是很多人追求的梦想,但我不推崇它,因为即便是你做到了,你也可能失去平台优化、失去个性色彩、在平台生态中沦为二等公民。
那么退而求其次Learn Once, Write Anywhere...
,不追求那么完美,能复用业务逻辑
、解题思路
、应用骨架
、核心代码
,也是知足常乐的。
从业务逻辑到领域模型
应用的核心是什么?是游戏规则,是业务逻辑,一个应用不管运行平台怎么变化,它的业务逻辑总是通行不变的。如果我们再进一步对业务逻辑进行领域建模,去掉那些花里胡哨的修饰、让业务模型变得抽象、纯粹、精炼,那么我们将得到一个最有价值的、最稳定坚固的、放之四海而皆可行的核心逻辑。
至于 UI 表现要个性化?要平台化?那就重新作件漂亮的外衣呗...
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 或是其他也是可以接入的:
抛砖引玉,你也许不会真的使用它,但它或许能给你带来新思路...
评论