微信杂谈 - 组件开发的一些思考

[lencx]

📅 2021.12.22

lencx:
人们更倾向于根据场景来探索解决方案，成也场景，败也场景。收窄要解决问题的范围，可以降低复杂度，但也降低了普适性。我以前也一直觉得，要实现的东西应该尽可能的剥离业务，但是随着做的业务越来越多，发现业务其实才是核心。当把业务抽象之后，所谓的跨平台其实就是适配的问题。

我发现可能之前自己想错了，应该抽象的是业务而不是组件，组件只是业务的载体。

适配层（组件）要做的就是低耦合，用抽象的业务逻辑去驱动适配层。

其核心就是业务，怎么实现，是个技术问题。技术可以被替换，推翻。以不变（主业务逻辑）应万变（视觉及交互）。

---

产生的讨论

正人 (欧雷):
场景化方案基于通用化方案，不冲突

lencx:
其实我是发现可能之前自己想错了，要抽象的可能是业务而不是组件

🇨🇳 Promise (🇨🇳 Promise):
感觉其实是不同维度

正人 (欧雷):
所以通用方案的扩展机制很重要

正人 (欧雷):
都要抽象

正人 (欧雷):
所以为啥要 MV*，为啥要 DDD[吃瓜]

🇨🇳 Promise (🇨🇳 Promise):
通用化方案抽离的开发工具本身， 例如打包工具， 组件化是ui 的抽离，例如react、vue，ant

🇨🇳 Promise (🇨🇳 Promise):
想到一个以前的小品，把大象放进冰箱需要几步，答案是三步。 接下来会对这三步行为不端细化和抽离。为了适配不同的场景（放进其他的东西），就对三步的行为不端抽象，部分不同的做单独适配

lencx:
适配层（组件）我认为要做的就是低耦合，用抽象的业务逻辑去驱动适配层

🇨🇳 Promise (🇨🇳 Promise):
来驱动适配层怎么来理解

Shine.:
除非业务组件 其他的组件都应该是低耦合吧 就只敢一件事

Shine.:
不应该有任何业务逻辑什么的吧？

空:
不是有业务组件跟通用组件之分么

lencx:
个人理解：组件开发一般两种模式，无状态组件和业务组件，业务组件会耦合业务逻辑

lencx:
但是如果按照我说的，其实就不存在业务组件了，所有的组件基本和业务都不存在太大的耦合，也就是不会在组件里处理业务相关的东西

lencx:
组件都退化到通用，然后只负责数据的填充。交互其实就是一个个动作，给业务数据所带来的反应。

Shine.:
就是说组件不去处理业务 业务都在使用的时候去处理？

lencx:
在抽象的业务核心逻辑里处理，你可以理解为业务核心就是一个个纯函数

lencx:
组件只负责接收数据

Jack:
按我理解

Jack:
理想化状态下，组件就是个书包

Jack:
你给我啥书 我就装啥书

Jack:
具体你给我的是语文书 数学书 马列主义 还是什么其他的

Jack:
我不管

Jack:
我只管把书装进去 让你带着走

lencx:
对，书就是业务核心，组件只负责装

Jack:
这也不是我该管的

Jack:
理想情况下就是这样

Jack:
我该管的只是，你如果不装书，装炸药，那我就报错

🇨🇳 Promise (🇨🇳 Promise):
这就是抽象与具象的互斥点了

🇨🇳 Promise (🇨🇳 Promise):
在业务状态下，有时候需要保证书的放入和放出顺序

Jack:
是的 所以理想和现实还是有些差距

🇨🇳 Promise (🇨🇳 Promise):
书的放置位置和摆放形势

lencx:
所以可能需要有类似流程控制的东西吧

lencx:
我其实也没完全想明白

Jack:
这个见仁见智了 有的倾向于在外边整理完了再塞进去

Jack:
有的倾向于塞进去，背在身上，让书自己动

皓夜森林:
ui组件的逻辑层都应该是个纯函数，ui层就是只负责渲染。业务组件感觉更偏向于，处理某个特定业务，比如唤起第三方的支付，sdk的支付组件。这种

Shine.:
什么叫纯函数 你给我啥我返回啥 对数据不做处理？

皓夜森林:
很简单，你想想你这个组件能不能在别的项目直接用

Shine.:
我看网上解释有点太名词了

🇨🇳 Promise (🇨🇳 Promise):
现在大多数抽象层的处理，都是在外面处理外，整体放进去，但是也有要求这个单独执行动作的。

皓夜森林:
不管啥项目。都能直接用（运行环境允许的情况下）

Jack:
没有副作用的函数

Jack:
比如 sum（1，2，3）

lencx:
纯函数就是个黑盒，接收参数，内部一系列处理后，返回的就是格式化后的标准数据格式

Jack:
我如果输入123 那输出值永远是6

🇨🇳 Promise (🇨🇳 Promise):
我个人推崇的还是那种微内核的形式， 提供插件机制和默认机制。 同时保留执行 过程外部可以修改的api

皓夜森林:
你就理解为一个函数如果在输入一样的情况下输出永远不变那就是纯函数

皓夜森林:
const add = (a ,b) => a + b 这就是一个纯函数

皓夜森林:
let effectParam = 1
const add = (a, b) => a + b + effectParam

皓夜森林:
因为结果会受effectParam影响

皓夜森林:
这就不是一个纯函数

皓夜森林:
这个参数变了结果就变了 即使输入可能都是一样的输入

Jack:
effectParam也可能是某个api的返回值

Shine.:
哦 明白了

🇨🇳 Promise (🇨🇳 Promise):
像纯函数的编写，也是可以传入单纯的形参，或者传入一个改变执行函数作为结构的再次处理

Shine.:
我一直理解的是 不修改传递的参数那

皓夜森林:
我寄几玩我寄几的

皓夜森林:
你别搞我

皓夜森林:
这就是纯函数

lencx:
业务其实就是一大堆这样的纯函数，做什么功能，调什么函数，职责单一

Jack:
其实本质就是在做取舍

Shine.:
那我好像很多时候违背了这个

🇨🇳 Promise (🇨🇳 Promise):
能保证单一指责其实在团队中就有点难的

皓夜森林:
hook很多都是业务组件的逻辑层

Shine.:
看似代码少了

Shine.:
其实维护起来有点麻烦

Jack:
的确

皓夜森林:
那你的项目做大了就很难维护

Shine.:
一改都得变

皓夜森林:
这个是肯定的

Jack:
所以要考虑颗粒度

Jack:
这就又扯到很多其他方面了

Jack:
团队规模 业务复杂度 等等

皓夜森林:
我的话这种都是踩坑踩出来的

🇨🇳 Promise (🇨🇳 Promise):
这个本身就是一个很大的命题，把这个充满生机的世界在计算机中进行再造，本身就是厉害

皓夜森林:
最近改公司的支付...越发体会深刻

lencx:
支付的各种逻辑一旦耦合进 ui 里， ui 大改版就痛苦了

🇨🇳 Promise (🇨🇳 Promise):
其实理解好面向对象也是比较容易，抽象对象， 实例在进行业务适配。 提供插件机制提供实例运行