Flux 设计模式和良好实践

Posted

技术标签:

【中文标题】Flux 设计模式和良好实践【英文标题】:Flux design pattern and good practices 【发布时间】:2017-12-04 11:40:52 【问题描述】:

这将是一篇很长的文章,包含我的问题,并以我最近创建的第一个 Flux 项目的示例为后盾,使用 Alt 实现。我将把它分成两部分,并尝试列举我的问题,以便更容易回答。如果您知道我可以阅读该主题的好地方 - 请分享。我已经完成了阅读,但我发现很难找到有关一般信息的信息。最佳实践。我们开始吧。

第 1 部分:一般问题

1) 每个视图组件

有多个商店

单个容器(或高阶组件)依赖多个商店是一种好习惯吗?这可能会导致组件状态中有很多未使用的属性。那是问题吗?如果是这样,我可以得到这样的状态:

//constructor
this.state =  
    field1: // from Store1
    field2: // from Store2


//componentDidMount
Store1.listen(this.updateFromStore1)
Store2.listen(this.updateFromStore2)

//updateFromStore1
this.setState(
    field1: state.field1
);

我认为这种方法可以很好地将 stores 之间的数据分开 - UserStore 只会保存有关用户的信息,dataStore > 将仅保存有关其数据类型的信息。每个组件都可以从所有商店获取所需的任何东西。或者应该更像 - 每个 container 都有自己的 store,这会导致数据重复,但项目更干净。

2) 对多个组件

使用单个store

例如 - FormStore,它负责保存有关我们应用程序中每个表单的信息。我们表单的所有字段都保存在那里,只有当前安装的组件(例如UserRegister)的那些被初始化和使用。这可能会导致很多未使用的字段在 state 中具有 null 值,但同样我们可以防止这种情况发生,如果我们只选择我们正在使用的字段,如上所述。

3) 什么应该负责加载初始数据?

我设计我的应用程序的方式是,当组件挂载时,它会触发 action 方法,该方法调用服务器获取数据,然后触发 SuccessFail 动作,这会更新 商店。但我在某处读到 stores 可以在内部获取初始数据,然后 actions 将仅用于更改该 data。如果商店要为此负责,应该在何时以及如何工作?

4) 动作的概念:

操作是应该驱动一切,还是仅在我们更新数据时才需要。例如,我尝试在操作内重定向,但我得到 同时操作错误,因为我重定向到的组件会在 componentDidMount 内触发操作以获取更多数据。如果 store 在内部处理初始数据,这可能不是问题。

5) 使用 actionsstores,减少传递大量道具:

例如,我的用户逻辑(登录、注销)由App 容器 组件处理。在App 下我有Navbar,然后是NavbarUserMenu。如果用户已登录,此用户菜单必须显示“Profile”和“Logout”,以及“Login”、“Register”。因此,我没有一直传递两个函数和一个布尔值——我在NavbarUserMenu 中使用UserActionsUserStore。我知道这种用户身份验证方法不是很好,但这只是最简单的例子。

第 2 部分:我在最近的应用中遇到的问题

1) 用户授权

基于

URL 的限制很简单。我在 container 之上使用了另一个 HOC,如果没有登录用户,它会监听 UserStore 并重定向到登录页面。但是我如何在我的组件链中隐藏一个按钮?我使用了相同的方法(但不是重定向,我只是没有渲染按钮)。但这有点违反 Flux 的规则,即所有 actionstores 都应该由 容器组件 操作> 仅限。有没有更好的方法。

2) 自包含 statefull 组件

Flux 文档说,最好的情况是所有 视图组件 都是 无状态。但是如果我有一个可扩展的视图组件呢?例如,我有一个盒子,带有书籍摘要和阅读更多按钮。按下按钮时,框会展开并显示附加信息。我的解决方案是在组件内部保持一个独立的状态,该组件包含特定于组件的信息。从逻辑上讲,我认为不保存实际数据的商店没有任何意义。有什么想法吗?

3) 位于组件链中较低的表单

这可能与 2) 类似,但我认为形式有点不同。例如,我有电影列表,在每部电影上,您都可以单击“评论”按钮,该按钮将显示 cmets 和表单,以添加新评论。如何处理该表格?独立的逻辑和状态?我所做的是将 comment 字段添加到我的 FormStore,并重用它和 FormActions(相同的 actions商店我用于我的应用中的每一个)。

【问题讨论】:

感谢您为您的问题付出了很多努力,但您同时提出了太多问题。每个问题都应该与特定事物有关。 @TomFenech 所以我应该把它分成 5-10 个不同的主题?这很奇怪。在我看来,每个人都可以过来说:“第2节:问题3:hisThoughts”。我真的不知道还能把这个放在哪里。在通量库上的 Git 问题 中看起来很傻。 您的许多“具体问题”实际上并不是问题。这些看起来像是没有具体答案的讨论点,而不是具有特定解决方案的编程问题。我不确定它适合哪里,但这并不意味着它适合这里! @TomFenech 并不是要不尊重,事实上,您正在回答,这意味着您比我更活跃并且更了解这个论坛,但我之前看到过非常受欢迎的抽象主题。通常是我的非常具体的问题,人们不喜欢,因为从他们的角度来看,我只是没有做足够的研究,而我只是没有得到我读到的一半的东西,因为我很新鲜。你会建议我把它拿下来吗? 我不会急于做任何事情,也许别人认为你的问题很好,我只是告诉你我的想法。 【参考方案1】:

只是对第 1 节 1) 的快速回答

我不知道您使用的是哪种通量实现,但是拥有不同的存储(比如用户存储和数据存储)与拥有一个具有以下根结构的存储并没有太大区别: 用户:...,数据:...

只要您可以注册到商店中的特定对象,它的行为就会相同。

这个问题围绕着“我的信息的生命周期有什么不同”。

例如,我通常将一些信息(例如“用户名”)存储在本地存储中。为了方便我将所有应该在本地存储的数据一起收集到一个特定的存储中,该存储将自行序列化 + 最初重新加载自身。

我看不出每个组件有 1 个存储的意义,如果数据只是内部数据,那么使用状态就足够了。

【讨论】:

你在现场。我忘了提,我正在使用 Alt。分离 UserStore 和 DataStore 背后的想法是避免过度复杂化存储内部的数据结构。我认为这可能会导致更大数据出现问题。例如,如果要检索我需要的东西,我必须进行大量过滤和循环。

以上是关于Flux 设计模式和良好实践的主要内容,如果未能解决你的问题,请参考以下文章

10个有关RESTful API良好设计的最佳实践

漫谈设计模式在 Spring 框架中的良好实践

漫谈设计模式在Spring框架中的良好实践

基于Flux的安卓应用设计模式的研究

Spring Flux:如果我需要使用 Flux 和 Spring 5 进行并行 Web 服务调用,实现模式会是啥样子

画布库如何适应 Flux 模式和 React?