常见问题

为什么我们需要另一种架构？

我们也问过这个问题！所以我们为此写了一个更长的回答：“为什么选择 Workflow？”。

我如何参与和/或贡献？

• Workflow 是开源的！
• 请参阅我们的CONTRIBUTING 文档以开始。
• 敬请关注！我们正在考虑为开源贡献者建立一个公共 Slack 频道。

这不就是 React/Elm 吗？

React 和 Elm 架构都对这个库产生了很大的影响。然而，这两个库都是用 JavaScript 编写的。Workflow 是用 Kotlin 和 Swift 编写的，并且面向这两种语言，利用了这些语言的特性，并将从这些语言使用的便利性作为一个主要设计目标。两者之间有一些架构上的差异，我们可以在下表中简要了解：

	React	Elm	Workflow
模块化	组件	用于代码组织的 Module，但并非以相同方式“可组合”。	一个 Workflow 类似于 React 的 Component
状态	每个 Component 都有一个 state 属性，该属性可以直接读取，并通过 setState 方法更新。	在 Elm 中，状态称为 Model。	Workflow 有关联的状态类型。状态只能在 props 改变时或通过 WorkflowAction 更新。
视图	Component 都有一个 render 方法，返回一个元素树。	Elm 应用都有一个 view 函数，返回一个元素树。	由于 Workflow 不绑定到任何特定的 UI 视图层，它们可以具有任意的渲染类型。render() 方法返回此类型。
注入的依赖项	React 允许父组件将“props”传递给子组件。	不适用	在 Swift 中，Workflow 通常是 structs，需要通过其父级提供的依赖项和配置数据进行初始化。在 Kotlin 中，它们有一个独立的类型参数 (PropsT)，总是从父级传递下来。Workflow 实例也可以注入依赖项，并能与依赖注入框架良好配合。
可组合性	Component 由其他 Component 组成。	不适用	Workflow 可以拥有子项；它们控制其生命周期，并可以选择将子项的渲染结果合并到自身的渲染中。
事件处理	DOM 事件监听器连接到 Component 上的函数。	update 函数接收一个 Msg，根据事件修改状态。	可以将 action 发送到 Sink 以更新 State。

这与 MvRx 有何不同？

除了非常特定于 Android 和 Rx 之外，MvRx 只解决每个屏幕的视图建模问题。Workflow 的主要灵感来自于需要在拥有几十甚至数百个屏幕的应用中管理和组合导航的需求。

这看起来很巧妙。我还能坚持传统的开发方法吗？

当然！Workflow 的设计目的是使复杂的应用架构对于大型开发团队来说可预测且安全。我们相信它即使对于小型项目也能带来好处，但构建软件绝不是只有一种正确的方法。我们建议遵循最佳实践并使用适合您项目的架构。