Seija
首页
Travellings
登录
注册
首页
文章
为什么elm的结构并不是最合理的?
## 取消了组件 并不是说取消了组件就算完全不对的,而是他取消了组件但是并没有给出组件所有的替代功能。**如果说逻辑是守恒的,一个组件等量的概念并不单纯的是一个View函数,单纯的使用View函数来完全对应组件概念是完全错误的。** 我们知道在传统UI设计中一个组件分为三部分 1. `View` 组件的显示部分 2. `ViewModel` 组件的View数据 3. `Controller` 组件的显示逻辑部分 举一简单的例子假如有一个CheckBox。 他的`View`部分是根据`IsCheck`生成View的函数 他的`ViewModel`是`IsCheck` 他的 `Controller`是处理点击事件修改`IsCheck` ### 没有ViewModel造成的问题 `elm`只有`View`函数,但是一个组件并不单纯的是一个View函数。一个组件要有自己的**View数据**。elm给出的方案是统一的一个大`Model`。这样就造成了**UI数据和业务数据的耦合**。 我们假设有两份数据 * 一份是业务数据 * 一份是UI数据 这两份数据并不是完全重合的。我的业务数据只是部分需要映射到UI数据,我的UI数据很多都是独立的和业务数据完全无关。例如我的业务数据不会关心UI上的某个按钮被激活后是什么颜色,也不会关心当前UI上是显示的哪个页签,更不会关心UI上的动画播放到什么状态了。 所以在`elm`里面ViewModel这个关键的概念完全是缺失的。 ### 没有组件的Controller造成的问题 `elm`里面任何View触发的事件都会派发到统一的`update`函数离去,这就造成了UI的组件逻辑也要写到`update`里去。这同样造成了**业务逻辑和UI逻辑的耦合** 假如说我有一个TabController但是我并不关心TabController什么时候切换也不关心TabController当前选择是什么,但是我们还必须把TabController的切换逻辑写到`update`里面去。这样不但污染了我们的业务逻辑代码也使我们无法提供一个统一的组件抽象。 ## 那么函数式呢? 要知道纯函数式是根本不提倡有副作用的,函数式社区对应UI提出的解决方案是FRP,但是FRP是不是适合UI还是没有验证过的(注意这里说的是纯FRP而不是各种自称的FRP)。 在FRP里有一个`Behavior`的概念。一个`Behavior`根据时间向前变化,当某个时间处有一个`Event`的时候这个对象会修改他根据时间变化的方式。 这有点让人联想到`Behavior`其实是一个对象。 所以这里衍生了两个分支: 1. 那么把`Behavior`这个概念提升到组件层面是否可行呢? 2. 我们为什么要那么关心是不是函数式,我们的目的难道不是做UI领域的合理抽象吗?
登录
登录
注册
最热文章
引擎中Template DSL的设计思考总结
10-19
ReaderT 设计模式
04-23
非主流引擎开发不出来 (n+1) : purescript侧结构设计
04-04
FRP系统的设计
03-17
非主流引擎开发不出来 (1) : 轻骨架
02-11
非主流引擎开发不出来 (0) : 引擎定位
12-09
Rust的ECS库specs
11-20
Haskell类型类高级扩展详细说明
05-31
CMake 速览
05-29
尼采导读:超人与永恒轮回
02-24
为什么elm的结构并不是最合理的?
02-20
React速览
02-20
尼采命运之爱
02-18
AspNetCore 速览
02-17
由Haskell和面向对象引出的关于抽象的思考
12-26
二进制文件压缩工具upx
12-24
Reflex介绍
12-17
Web的前端渲染和WebApi
12-16
前端FRP框架深度踩坑
12-16
Yesod - RESTful (11)
12-16
链接
github
gitee