Replies: 1 comment 1 reply
-
短时间内强行多次改版。。。第一版,数据是数据,业务是业务,交互是交互;第二版,数据是数据,业务和交互混合;第三版,数据业务交互混合。。。PM&UI大声呼喊:我们的产品月越来越符合用户需求;前端coder小声嘀咕:终于又盖了一座屎山。 |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
背景
但就我自身经历及接触项目而言,项目还是停留在如何编写组件的层次上,简单的实现一些复用。一些历史项目因为需求的迭代,功能在不断增加,写代码的人员也在不断更替,交接。就会导致最后的接手项目的人痛苦不堪,
重构?不现实,时间不够,之前的需求也不清楚。继续保持?就面临着怎么去在原项目之上继续迭代。进退两难...在之前的需求毫不知情的情况下,如何完成需求功能的迭代,UI 改版?只能通过全局搜索一些关键词,关键字去一步步向上 debug 源码。如果代码中牵扯过多的业务逻辑,就完全懵逼了,没人知道之前的需求是什么?_?!!!
以 React 为例,因为每个人都有自己对组件的理解,不同的人站在不同的维度去封装,就导致最后的项目结构,代码结构也是千差万别。
无状态组件
: 不涉及过多状态交互,很容易实现,大家的思路都差不多。有状态组件
: 一旦涉及到状态,业务逻辑,交互。一个组件就变得不再可控。每个人的风格也都体现的淋漓尽致!return
出不同的组件 ╥﹏╥props
,属性有时候多到令人发指,有数据,方法,状态,自定义的 xxx,各种传递。 o(╥﹏╥)o思考
我对数据的理解,它既贴近于业务层,也耦合着交互层,如果不能很好的分离组织这三层,很可能牵一发而动全身。所以数据是核心,既是业务的核心,也是组件的核心。
数据 (DataSource)
,交互 (Action)
,UI视图 (View)
三层。function
形式存在。数据处理
和UI 视图
中。在数据处理中,调用 (Call)
方法;在 UI 中,绑定 (Bind)
事件及状态。UI 层尽量不直接处理或少处理源数据。举例
React Hook
为例:查看 DEMO 演示
总结
数据与 UI 的解耦,其实就意味着业务逻辑与 UI 组件视图的解耦。当组件要跨平台,或者 UI 大换肤时,我们只需要实现标准的数据接收组件就可以了。业务功能对应的其实就是一个个数据处理函数和 UI 组件的组合,通过事件去触发或者绑定一些状态。当数据处理或组件不满足需求的时候,我们只需要去扩展对应的函数或组件。
Beta Was this translation helpful? Give feedback.
All reactions