我完成了编写 FAQ 的最初繁重工作。 @gaearon做了一些编辑,我添加了 TOC 和简短的问题链接,到目前为止它是一个很好的资源。 从那以后,我知道@gaearon指出了一些值得进行常见问题解答的讨论和文章,而且我有一堆积压的书签和更新需要整理。 让我们尝试列出我们认为需要添加或更新的任何主题、链接或项目。
我添加了现有问题的更新,但目前我专注于其他任务。 如果有人有兴趣帮助编写“新”条目,我很乐意就信息、内容和编辑与他们合作!
这不是常见问题解答项目,但我会在这里给自己留个便条,而不是提交新问题。 “Beyond combineReducers”页面应该提到“双重嵌套状态”,如在state.posts.posts
,通常是由于初始状态定义了一个键 _and_ slice reducer 被赋予了一个键。 . 绝对是一个常见的错误。
applyMiddleware
对dispatch
使用闭包?combineReducers
递归/限制?为什么mapDispatch
不允许使用getState
或mapState
返回值?
拥有“一个状态树”会导致内存问题吗?
看到那个图像,我只是部分地关注那里发生的事情。 或者更确切地说,我看到了代码,只是不太了解意图或声明。
除了“调度”和“减少”实际上只是更新父组件状态之外,您的意图是呈现“类似连接”的组件吗?
我也不明白关于“分离”减速器的一点,因为在该片段中没有实际存储或使用store.replaceReducer()
。 您只是说“类似减速器”的功能可以应用于商店减速器结构的上下文之外?
新的常见问题解答部分,或可能的设计文档:“为什么 Redux 是这样设计的”。 示例主题:为什么store.subscribe()
不包括动作或状态作为参数,为什么中间件是嵌套函数等。
看到那个图像,我只是部分地关注那里发生的事情。 或者更确切地说,我看到了代码,只是不太了解意图或声明。
除了“调度”和“减少”实际上只是更新父组件状态之外,您的意图是呈现“类似连接”的组件吗?
我也不理解关于“分离”reducer 的部分,因为在该片段中没有实际存储或使用 store.replaceReducer()。 您只是说“类似减速器”的功能可以应用于商店减速器结构的上下文之外?
这个想法是:您不需要带有专用存储对象的 redux 库来实现(prevState, action) => nextState
redux 架构。 React 组件状态可以是您的存储,位于组件本地,您可以通过 React setState 进行状态更新来实现自己的调度。
是的,这就是我以为我看到的。 真正让我失望的是“分离”措辞,因为我知道您实际上可以调用store.replaceReducer()
。
关于action creators 和 reducers 之间的拆分逻辑,我认为值得指出的是 selectors(mapStateToComponent) 是另一个处理这些(验证、数据转换)的好地方。 这在来自服务器(reducer)的真实源和由源(选择器)计算(转换或过滤)的视图相关数据之间创建了很好的分离。
我经常看到的另一个问题是如何制作一个可以在外部重用的 redux 模块(action creators、reducers、components)。 主要是当我们在同一个页面中有多个相同类型的模块时如何避免动作名称冲突,以及如何确定reducer名称以便它可以被createStore使用。
是的,我们肯定需要常见问题解答的“设计决策”部分。
@reactjs/redux 的问题:我正在讨论是否可能将 FAQ 分成每个主题的单独页面。 当前的单页很长。 有什么意见吗?
我确实喜欢有一个指向目录中所有问题的链接列表。 如果我们保持这一点,我就看不出将主题拆分到不同页面上有任何不利之处。
是的,我肯定会保留 FAQ.html 以获得完整的目录,然后可能在每个页面中都有一个单独的目录,仅用于其条目。
组织它们的最佳方式可能是对在谷歌搜索相关问题的人产生最佳结果的任何方式。
从这个任务开始。 计划是先按照当前的分类进行拆分,然后更新现有的问题,最后写出新的材料。
我想了解更多关于商店增强剂的信息。 以及用于代码拆分的可注入减速器。 两者的例子都非常有限且难以遵循。
@梅德罗斯:嗯。 两个有趣的话题,但可能没有那么多“常见问题”。
几周前在 Twitter 上有一个关于商店增强器的很好的讨论: https :
对于可注入的减速器,您可能想看看https://github.com/mxstbr/react-boilerplate和https://github.com/davezuko/react-redux-starter-kit是如何做的。 在我的Redux 插件列表中,还有各种与组件状态和reducer 管理相关的库可能是相关的。
今天进展不错。 将 FAQ 分成每个类别的单独页面,对现有问题进行了大约一半的计划更新。 明天我会试着把剩下的都打掉。
“拆分+更新”部分现在在(见#2009)。
在解决新问题之前,我还有一些其他事情要做,所以我暂时将其搁置。 可能会在几周内回到这个问题。
很高兴帮助您为您编写其中的一些内容。 关于最好的起点有什么想法吗?
嗨,谢谢!
就实际提问的频率而言,添加一个新的“设计决策”类别将是最相关的。 也就是说,这也直接涉及到一些相当技术性的方面。
一个更容易开始的地方可能是在“常规”部分添加一些新问题。 我目前列出的想法是“我应该什么时候使用 Redux?”、“使用 Redux 的优缺点是什么?”和“Redux 与 [Angular/Backbone/MobX] 相比如何?”。
也就是说,如果有一个特别的问题引起了您的注意,那也可以。 我们没有试图达到特定的截止日期,只是我看到的一堆问题,我希望在常见问题解答中实际涵盖。
我很高兴与您合作,讨论这些答案的方向、编辑和指向更多信息的链接,我目前主要专注于撰写博客文章系列,并尝试自己编写常见问题解答在完成之前对我来说是次要的。
好的,听起来不错。 为什么我不从 _When/why to use Redux_ 和 _Redux state vs React state_ 开始。 你想让我写一个草稿并添加一个新的 PR 供你审查,或者你有其他一些你喜欢使用的流程吗?
啊...抱歉,让我澄清一下第一条评论试图表达的内容。
我的目标是为现有问题添加额外的链接和信息,然后编写新的问题+答案。 我已经完成了“现有问题的更新”标题下的所有内容,即“添加新链接”部分。 这是我目前正在寻求帮助的“编写新问题+答案”部分。
潜在的新问题列表在“新主题”标题下(从“我什么时候应该学习 Redux?”开始)。 该部分下列出的任何内容都值得解决。
至于工作流:你想要 fork Redux repo,创建一个分支,然后开始处理你的草稿。 可以先在此处发布指向 WIP 文件的链接,然后一旦您认为已准备好草稿,就提交 PR。
好的,我将从_我必须使用 Immutable.js 吗?_ 开始。 我刚刚写完关于 Immutable 的一系列教程,我每天都在使用它,所以我非常熟悉围绕它使用的问题。
听起来不错! Reddit 上的链接评论是我自己对一些权衡的看法。 我还添加了指向我的 React/Redux 链接列表相关部分的指针,关于不可变数据和 React perf,作为附加资源。
“Immutable.js”问题可能属于一个新类别,但目前不确定该类别应该是什么。 也许暂时在您的分支中创建一个“不可变数据”类别,然后开始在该页面中编写?
@markerikson First PR 现在可以审核了:#2120
@bundance :太好了,谢谢! 我今晚或周五去看看。
这看起来是增加我对 Redux 理解的绝佳方式。 我很感激有一些特定的任务要做。 哪个有优先权,有人还没有这样做,等等。
@mateo-io:当然,感谢您提供帮助!
如果您查看问题顶部的列表,“等待添加”部分下的所有内容都是......呃......等待添加:) 目前没有其他人正在处理这些中的任何一个,所以他们都是公平的游戏。
一种简单的入门方法可能是处理“现有问题的更新”项目。 例如,有一堆链接我想添加到“我什么时候应该使用 Redux?” 题。 这些应该非常简单 - 只需将链接添加到常见问题解答中该问题末尾的现有列表中,并简要说明每个链接的含义。
另一个好的起点可能是诸如“为什么我应该使用动作创建器?”之类的新问题之一。 或“我什么时候应该使用 Redux?”。
如果您想先解决其他问题,那很好。 查看我想要添加或更新的主题列表,让我知道您想要处理的部分。
@markerikson 2370为常见问题解答一般部分
我想帮助添加到“代码结构”部分的新链接!
@gribnoysup :太好了,很高兴听到它! 继续创建 repo 的分支和用于编辑的分支,然后开始更新“代码结构”常见问题解答文件。 最简单的第一步就是添加我列出的几个链接,用于更新“将业务逻辑放在哪里?” 题。 从那里,我们可以讨论为“为什么使用动作创建者?”添加新的问题/答案。 和“封装逻辑”。
@markerikson我为代码结构常见问题部分打开了一个新的拉取请求https://github.com/reactjs/redux/pull/2494
@markerikson我有兴趣研究这个。 如果我选择“为什么使用动作创建器?”可以吗? 物品。 如果这对您更好,很高兴从其他地方开始。
@maxhallinan :是的,那太好了! 继续为新的常见问题解答草稿,提交 PR,我们可以在那里对其进行调整。 谢谢!
@markerikson我也很感兴趣,您有什么想法可以让我开始,这也是社区普遍要求的吗?
@markerikson我为关于设计决策的常见问题部分做了 PR #2528
@sbakkila :太好了,谢谢! 明天晚上或周三我会试着看一下。
@Fyre91 :很抱歉没有更快地回复您。 在最近几条评论中没有提到的列表中的任何内容都是公平的游戏:) 如果您想要一些建议作为开始,您可以处理我为“一棵状态树”和“多次调度”问题。
@markerikson我很抱歉这花了这么长时间。 我已经打开 PR #2535 “我为什么应该使用动作创建器?”
我还打开了 PR #2537 以添加指向操作常见问题部分的链接。 FWIW,此问题描述中列出的其他更新链接似乎已添加。 否则,我会将它们包含在此 PR 中。
我正在考虑继续“我应该什么时候学习 Redux?” 这个问题是专门针对 React 的吗? 否则,似乎应该在应该使用 Redux 的时候学习 Redux,这会与已经回答的“我什么时候应该使用 Redux?”重叠。
@maxhallinan :嗯,这是关于 React 的 _sort_。 是的,与“我什么时候应该使用 Redux?”有 _some_ 重叠,但我认为它足够明显,可以保证自己的 FAQ 条目。
@markerikson好的,我将讨论一个状态树性能常见问题解答。
@Fyre91 :很酷,谢谢!
@markerikson好的,听起来不错。 我正在学习“我什么时候应该学习 Redux?”。
@markerikson我
@markerikson我接下来将在 Performance 下进行分页/缓存项目。 只是为了确认,实际问题是“我可以缓存分页数据而不引起内存问题吗?”
@maxhallinan :大致,是的。 其他思路可能是“我如何实现缓存检查?”、“我如何处理清除缓存数据?”、“我可以安全地在内存中缓存多少?”等。
老实说,我不记得_完全_我在写那个项目时在想什么,但这就是这些链接所涵盖的内容。 我还刚刚添加了一个链接,指向一篇关于跟踪规范化数据子集的精彩帖子。
如果我们觉得它需要它,这很容易变成多个单独的问题条目,而且我不确定我想从中看到什么。 尝试一下这个话题,看看你想出了什么,我们将从那里开始工作。
我刚刚更新了线程顶部的列表,以反映最近所做的工作。 (实际上,你知道……我真的应该从一开始就将其设为复选框待办事项列表,而不是将完成的内容剪切并粘贴到第二部分中。哦,好吧。)
很高兴看到剩余的东西列表越来越小!
@markerikson Updates to Existing Questions: Performance
已经在 master :)
@markerikson “为什么要使用动作创建器?” 也是在大师。
@gribnoysup , @maxhallinan :啊,是的,他们是 :) 更新了列表。
肯定能到。 看起来现有问题的所有更新都已完成,只剩下几个新项目了。
刚刚提出了一个新的“设计决策”问题:“为什么 Redux 将操作和更新分开?”
我认为我们在这方面做得很好。 我们可以跟踪其他问题中的个别常见问题更新。
最有用的评论
关于action creators 和 reducers 之间的拆分逻辑,我认为值得指出的是 selectors(mapStateToComponent) 是另一个处理这些(验证、数据转换)的好地方。 这在来自服务器(reducer)的真实源和由源(选择器)计算(转换或过滤)的视图相关数据之间创建了很好的分离。
我经常看到的另一个问题是如何制作一个可以在外部重用的 redux 模块(action creators、reducers、components)。 主要是当我们在同一个页面中有多个相同类型的模块时如何避免动作名称冲突,以及如何确定reducer名称以便它可以被createStore使用。