【发布时间】: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 只会保存有关用户的信息,{data}Store > 将仅保存有关其数据类型的信息。每个组件都可以从所有商店获取所需的任何东西。或者应该更像 - 每个 container 都有自己的 store,这会导致数据重复,但项目更干净。
2) 对多个组件
使用单个store例如 - FormStore,它负责保存有关我们应用程序中每个表单的信息。我们表单的所有字段都保存在那里,只有当前安装的组件(例如UserRegister)的那些被初始化和使用。这可能会导致很多未使用的字段在 state 中具有 null 值,但同样我们可以防止这种情况发生,如果我们只选择我们正在使用的字段,如上所述。
3) 什么应该负责加载初始数据?
我设计我的应用程序的方式是,当组件挂载时,它会触发 action 方法,该方法调用服务器获取数据,然后触发 Success 的 Fail 动作,这会更新 商店。但我在某处读到 stores 可以在内部获取初始数据,然后 actions 将仅用于更改该 data。如果商店要为此负责,应该在何时以及如何工作?
4) 动作的概念:
操作是应该驱动一切,还是仅在我们更新数据时才需要。例如,我尝试在操作内重定向,但我得到 同时操作错误,因为我重定向到的组件会在 componentDidMount 内触发操作以获取更多数据。如果 store 在内部处理初始数据,这可能不是问题。
5) 使用 actions 和 stores,减少传递大量道具:
例如,我的用户逻辑(登录、注销)由App 容器 组件处理。在App 下我有Navbar,然后是NavbarUserMenu。如果用户已登录,此用户菜单必须显示“Profile”和“Logout”,以及“Login”、“Register”。因此,我没有一直传递两个函数和一个布尔值——我在NavbarUserMenu 中使用UserActions 和UserStore。我知道这种用户身份验证方法不是很好,但这只是最简单的例子。
第 2 部分:我在最近的应用中遇到的问题
1) 用户授权
基于URL 的限制很简单。我在 container 之上使用了另一个 HOC,如果没有登录用户,它会监听 UserStore 并重定向到登录页面。但是我如何在我的组件链中隐藏一个按钮?我使用了相同的方法(但不是重定向,我只是没有渲染按钮)。但这有点违反 Flux 的规则,即所有 action 和 stores 都应该由 容器组件 操作> 仅限。有没有更好的方法。
2) 自包含 statefull 组件
Flux 文档说,最好的情况是所有 视图组件 都是 无状态。但是如果我有一个可扩展的视图组件呢?例如,我有一个盒子,带有书籍摘要和阅读更多按钮。按下按钮时,框会展开并显示附加信息。我的解决方案是在组件内部保持一个独立的状态,该组件包含特定于组件的信息。从逻辑上讲,我认为不保存实际数据的商店没有任何意义。有什么想法吗?
3) 位于组件链中较低的表单
这可能与 2) 类似,但我认为形式有点不同。例如,我有电影列表,在每部电影上,您都可以单击“评论”按钮,该按钮将显示 cmets 和表单,以添加新评论。如何处理该表格?独立的逻辑和状态?我所做的是将 comment 字段添加到我的 FormStore,并重用它和 FormActions(相同的 actions 和商店我用于我的应用中的每一个)。
【问题讨论】:
-
感谢您为您的问题付出了很多努力,但您同时提出了太多问题。每个问题都应该与特定事物有关。
-
@TomFenech 所以我应该把它分成 5-10 个不同的主题?这很奇怪。在我看来,每个人都可以过来说:“第2节:问题3:
hisThoughts”。我真的不知道还能把这个放在哪里。在通量库上的 Git 问题 中看起来很傻。 -
您的许多“具体问题”实际上并不是问题。这些看起来像是没有具体答案的讨论点,而不是具有特定解决方案的编程问题。我不确定它适合哪里,但这并不意味着它适合这里!
-
@TomFenech 并不是要不尊重,事实上,您正在回答,这意味着您比我更活跃并且更了解这个论坛,但我之前看到过非常受欢迎的抽象主题。通常是我的非常具体的问题,人们不喜欢,因为从他们的角度来看,我只是没有做足够的研究,而我只是没有得到我读到的一半的东西,因为我很新鲜。你会建议我把它拿下来吗?
-
我不会急于做任何事情,也许别人认为你的问题很好,我只是告诉你我的想法。
标签: reactjs design-patterns flux