从Event到Action
-
用户通过UI界面产生的人机交互事件,我们习惯叫"Event事件",而"Event事件"背后的业务目的我们可以叫"Action动作",它们一个是因一个是果,一个是表一个本。
处理 Event 的 Handler 是UI逻辑,应当写在UI组件中;处理 Action 的 Handler 是业务逻辑,应当写在Controller里面。
举个具体的例子吧:"SubmitLoginForm|提交登录表单",通常要完成如下逻辑:-
验证输入是否有效;
-
验证当前用户是否已经登录;
-
请求后端API,并等待返回;
-
如果成功,保存用户信息,并跳回原页面;
-
如果失败,提示错误,并留在原地。
这是一个业务动作,因为它可以不依赖哪个具体UI而运行,用户可能通过“onClick事件”点击登录按钮来触发,也可能通过“onKeyPress”按下回车键来触发,甚至你可以直接让用户通过“Login命令”来触发。所以“onSubmitLoginForm()”应当写在Controller而非UI组件中。
UI组件中只有"onLoginButtonClick()"或"onEnterKeyPress()",而它们往往也就一句话,就是Dispatch一个Action来触发Controller中的“onSubmitLoginForm()”
将业务逻辑移出UI组件,这样UI层就变薄了,回归到了它的本质:只负责收集业务动作,不负责处理它。
-
改良Flux框架:传统的Flux框架也有痛点:全局中心化管理导致逻辑过于集中;
单实例、不销毁容易造成信息累积爆炸;DispatchAction机制过于简单,不适合处理前因后果的长流程业务。Elux正是针对以上痛点进行了改良:
虽然坚持全局中心化管理,但Elux提出“微模块”的概念,将应用拆分成独立自治的一个个“微模块”,每个微模块仅处理自己领域内的事情。
不再单实例,每次路由变化都会产生一个新的空白Store,然后重新挑选有用的状态挂载,类似一种垃圾回收机制。
提出了ActionBus的概念,让Action作为Model中的事件来广播。让Action的处理链条具备“协程”机制,更好的协同各业务动作之间的关联。 -
Elux践行的分层而治:正是因为遵循了轻UI、重Model的设计思想,让Elux可以挂接React/Vue等各种不同的UI框架,它们已经变得没那么重要了。
正式因为分离了UI逻辑和业务逻辑,让Elux可以用一种工程模式开发Web(浏览器)、Micro(微前端)、SSR(服务器渲染)、MP(小程序)、APP(手机应用)。
-
西南地区IT社群(QQ)
- 云南
- 【昆明网页设计交流吧】243627302
- 【昆明nodejs交流吧】 243626749
- 【VUE】838405306
- 【云南程序员总群】343606807
- 【昆明UI设计】104031254
- 【云南软件外包】15547313
- 贵州
- 【PHP/java源码/站长交流群】55692114
- 四川
- 【成都Java/JavaWeb交流】86669225
- 【vaScript+PHP+MySql】116270060
- 【UI设计/设计交流学习群】135794928
- 重庆
- 【诺基亚 JAVA游戏博物馆】 559479780
- 【PHP,Java,Python,C++接单】 442103442
- 西藏