Redux: 提案：将“stores”重命名为“reducers”

-1 这个 repo 的学习曲线已经很陡峭。 让我们不要通过为新的通量用户引入新术语来使它变得更陡峭。

在内部，它们可以称为减速器，将它们公开保留为存储，以便更容易理解。

老实说，我认为现在的方式更令人困惑。 完全是轶事，但我已经有几个人在 IRL 思考“商店”如何是无状态的。

传统 Flux 中“存储”的主要特征是它们 1) 保持状态，以及 2) 发出更改事件。 在 Redux 中这两者都不是真的。

我同意我们需要澄清术语，并在某些情况下找到更好的命名。
我认为作为第一步应该有一些 JSDoc，然后术语部分也会有所帮助。
一般来说，我们必须保持一定程度的一致性。

我想知道是否有一个术语听起来不像 FP-ish，但也不是“商店”。
域？

OTOH 它已经被称为 Redux，所以至少“reducer”听起来是相关的。

“步进更新”或“步进器”如何​​，它将您的状态向前移动一步。 我已经看到这在 Elm 文献中被使用，有一个名为step 、 update或next的函数

域包含 node.js 包袱。

它们不是存储它们的功能，但您仍然将状态逻辑放在那里，就像通量存储一样。 他们是状态管理器，就像通量商店应该是。

如果您热衷于更改它的名称，Reducers 很好。

特别是因为“减速器”是对它们实际情况的精确描述:)

更新者？ 听起来描述性+比减速器更不势利。

我也喜欢reducer

我想我不明白为什么“减速器”是势利的。 使用实际术语不是比发明一个描述性更差的新术语更好吗？

我想两者都可能是有效的，这取决于您从哪个角度看待它：动作的 _reducer_（进入状态），或状态的 _updater_。

“更新程序”意味着它是可变的。 “Reducer”清楚地表明您正在返回一个新状态，而不是修改旧状态。

这是我认为的一个优点，可能有助于解决关于 redux 无法正确处理突变的问题

我很欣赏需要让 Redux 对不熟悉 FP 的人保持友好，但我们可以通过更好的文档来解决这个问题。 我喜欢当前的文档，但乍一看它们有点让人不知所措。 一个好的文档站点将熟悉的内容（动作创建者、reducer 逻辑）置于高级内容（中间件、热重载）之上，这将非常有帮助。

然而，从这里以下内容的快速增长来看，我们必须做正确的事情:)

如果这与更好的文档一起发生，我愿意将“Stores”更改为“Reducers”。

基本要素是保持“它就像 Flux 但更好，别担心”的氛围。 我不希望人们认为它类似于 Reflux 之类的东西，这听起来像 Flux，但破坏了它的一些不错的特性。 我也不希望他们认为他们需要学习 FP。 只要我们能保持这种状态，我就可以接受这种变化。

我不太确定的建议：如果我们将 Redux 类重命名为 Store（想一想：它的两个目的是保持状态和发出更改事件），那么顶级 API 变为：

const store = createStore(reducers);

<Provider store={store} />

我认为，这很好地传达了这个想法。 Reducers 是存储逻辑所在的地方，但它们本身不是存储。

我喜欢这个，虽然store.dispatch感觉不对。

是的，这是我不太喜欢的一件事，但其他方法是有道理的： store.getState() , store.setState() , store.subscribe()

现在回想起来，我们并没有真正“派遣”任何东西。
呃，命名是一个兔子洞。

好的，到目前为止我们所拥有的是：

• 行动（创造者）
• (店)减速机
• 中间件功能
• 回调（侦听器）函数
• 触发函数调用链的东西（称为调度程序）
• 保持可变状态的东西（使用 setter 和 getter）

也许我们可以退后一步重新考虑命名？

也许store.dispatch还不错。 我们可以简单地解释一下，我们只有一个 Store，而不是许多 Store，您可以用 Reducers 组合它。 No Stores = 不需要单独的 Dispatcher，因此dispatch可直接在 Store 上使用。

@gaearon我同意。

@emmenko很好的总结。 任何术语细分都应区分_动作创建者_和_动作_。 它还应该区分 _dispatcher_ 或 _dispatch strategy_，其中包含中间件 + 减速器，以及触发 _dispatch cycle_ 的 _dispatch_ 方法。

我们开工吧：

• 将 Store 重命名为 Reducers
• 根据https://github.com/gaearon/redux/issues/137#issuecomment -113252359 将“Redux 实例”重命名为 Store
• 说明如果你眯着眼看传统的 Flux Store，你会看到 Reducers 被困在里面

有人想领导新的文档工作吗？ 它需要一些结构化：词汇表、自述文件、简单的“开始运行”教程，也许还有更深入的“设计决策”指南。

@gaearon我会自愿领导这个 :) 我已经有一个大纲了。

谢谢：+1：

我会自愿领导这个

谢谢！ :+1: :+1: :+1:

就个人而言，作为最终结果，我真的很想拥有一个自动生成的网站：

• 入门
• 教程
• 活生生的例子

...作为一个不错的功能：

• 生成的文档 a-la docco （例如：像jasmine ）以便清楚地解释源代码

但是从 markdown 和 jsdoc 开始当然是第一步；)

是的，我认为第一步是以 Markdown 形式编写的文档，然后我们可以将它们移植到一个非常好的文档站点。 :+1: 也适用于 JSDoc。 今晚我将在https://github.com/gaearon/redux/pull/87 进行最后一次尝试，但我不确定此时 Flow 注释是否值得，除非我们摆脱函数重载的代码库。 （或者除非有人教我如何在没有 Flow 抱怨的情况下正确输入它们。）

我想 Flow 不是优先级的自动取款机。

+1 表示被称为减速器的商店。

我一直不喜欢将这些更具声明性的、无状态的事物称为存储。

我喜欢新名字的想法。 我还建议将Connector重命名Subscription 。 Connector非常通用，虽然我知道它将 redux 的状态和调度程序连接到它的孩子，但我认为订阅是对正在发生的事情的更好描述。 您在订阅时获得调度员有点牵强，但我认为没关系。

-1 表示 store 被称为 reducers，作为一个名字，它对新用户（至少那些没有函数式编程背景的用户）来说不是很直观。 如果我们想更明确地了解它，也许 Updater 或 Transformer 会更好，或者 Store Updater。

“变形金刚”已经被推荐了很多次了。 它不像 Updaters 那样暗示可变性，比 Reducers 更平易近人，并且不带有 Stores 的“存储”内涵。

你喜欢变形金刚吗？

减速器 +1

正如@faassen在 Twitter 上所指出的，“reducers”的一个很好的论据是回调项目名称。 我们有机会说“这就像 Flux，但只有一个 Store。 就像您可以将您的应用程序组合成 React 组件一样，在 Redux 中，您可以使用 Reducers 组合该 Store。 它们被称为 Reducers，因为它们的签名匹配传递给[].reduce()函数： (state, action) => state 。 布拉布拉布拉”

角度像野火一样蔓延并使用类似的词

• 指示
• 隔离
• 嵌入

忽略编程，转换和减少是不同的事情。 我会选择最准确的名字。

如果它们不存储数据，请不要称它们为商店。

你是从一种形式转变为另一种形式，还是从许多值减少到一个？

变压器 => 地图
减速器 => 减少

对我来说听起来像是减少了。

我也是reducers ！ ：+1：

从榆树那里汲取灵感。 https://github.com/evancz/elm-architecture-tutorial#the -basic-pattern

最好的词是update 。 Store 是废话，一直都是“Model”。 无需重新发明轮子或混淆人们。

我之所以称他们为更新者，是因为人们可能认为他们应该是可变的。 如果命名可以帮助澄清非突变性，那将是一个巨大的好处。

你是从一种形式转变为另一种形式，还是从许多值减少到一个？

我在积累。 “一个动作如何将一个状态变成下一个状态。” 从概念上讲，它们从初始（未定义）状态减少了许多动作，而记忆只是一种优化。

状态转换器

尽量避免重新发明/重新发现。 人们一直称它为reduce 、 scan 、 fold和update 。

reducer从 javascript 的角度来看似乎是准确的......
不要看到从另一种语言的概念命名它的价值，即使它更准确。

对它应该是什么没有坚定的立场，但 IMO 它应该是最准确地代表计算类型的东西。 如果它对大多数程序员来说是一个陌生的词，那么这可以通过文档来抵消。

@vramana它不是map ，而是reduce ，因为它需要先前累积的state和一个新的action并返回一个新的state 。

如果您有应用程序所有操作的数组，您可以使用此函数将其减少到最终应用程序状态：

function reducer(state, action) {
  // switch (action.type) ...
  // return state;
}
const finalState = allAppActions.reduce(reducer, initialState);

现在，您真正拥有的是stream的actions时间，这在概念上与数组相同，但是在时间上（您可以将其减少为stream state秒）。

我喜欢将其视为（事件日志到数据结构的投影）。
DB 人过去将此称为“物化视图”。

我喜欢减少或折叠，不同社区都很好理解

我更喜欢 Transformers 而不是 Reducers：从这个词的正常英语用法可以清楚地看出它的含义。

减速机。
首先，它是 javascript 库，javascript 有[].reduce(reducer, initialState) 。
其次，Redu(cer)x 已经在库名中。
第三， https://blog.javascripting.com/2015/06/19/flux-no-more-stores-meet-reducer/ ，其他人和图书馆会使用“reducers”这个词。

Reducer 是准确的，在 vanilla JS 中有先例。 不确定如何改进。

减速器它应该然后。

（关注#140 的进展）

偶尔我会发现旧的讨论称它们为“商店”，并惊叹事后它是多么可笑的混乱。

“状态容器”？

是的，这是一个很好的改变:)