从Event到Action

[manrui589]

  用户通过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(手机应用)。