Redux: Redux的时间来了吗？

https://github.com/rackt/redux/issues/464

许多人对Redux感到非常满意。 您应该四处询问-我真的没有资格回答这个问题。 我想说的是，如果您的应用程序非常注重数据（如Facebook）（许多具有复杂关系的嵌套实体），那么最好投资GraphQL后端并学习Relay。 我只听说过好消息。

当然，Redux更明确，并且不能为您解决声明式数据获取。 有尝试集成Redux和GraphQL的尝试，但是我无法根据Relay进行评估-我对此知之甚少。

Redux的级别比Relay低得多，并且比普通的JS对象和函数“过去”更“过去”。 中继是一个框架，没有进行健全性检查的Redux是十个10线性函数，因此它们具有不同的作用域也就不足为奇了。 选择最适合您的方法，并告诉我们。

GraphQL的声明式获取令人称奇，一流。 但是Relay仍然主要具有HoC API，它本身不是声明性的。 如果Relay提供了一个更灵活的，与组件树分离的API，那么可以编写适当的Redux绑定吗？

我认为它们是解决2个不同问题的2种类型的系统。
这张票就像木匠问锤子的时间是否过去了。
我认为基于graphql的系统对于许多应用程序来说都是过度设计的解决方案，相反，如果使用redux构建具有复杂数据结构的应用程序，则极有可能是在工程设计之下。

我认为基于graphql的系统对于许多应用程序来说都是过度设计的解决方案，相反，如果使用redux构建具有复杂数据结构的应用程序，则极有可能是在工程设计之下。

好的表达方式； 我也是这样。

@gaearon与redux保持良好的合作关系！ 最好的工具之一！ 我在公司的5个大型应用程序和2个小型应用程序中使用它，并且很喜欢它！

@gaearon与redux保持良好的合作关系！ 最好的工具之一！ 我在公司的5个大型应用程序和2个小型应用程序中使用它，并且很喜欢它！

：100：

我认为他们不一样：

• 中继-用于解决从服务器获取数据的管理
• redux-解决应用程序的状态管理

许多复杂的应用程序包含与您需要管理的服务器无关的状态。 我会争辩说，如果您将使用中继，那么最终您还将看到自己也需要redux。 相反，中继似乎是一个很好的提升，但仅适用于与服务器相关的东西

问题是继电器与通量激励的设计模式有何关系？ 中继在哪里结束，何时需要Redux？ 是Relay Flux 2.0吗？

Todo Relay示例：它会使redux过时吗？

也许有一种方法可以告诉您的reducer如何在GraphQL上进行映射，以及何时进行映射？ 不要说并不复杂，而是要使之有意义的最简单方法是什么。

需要更多地了解什么是中继。 肯定不是几百行代码！

@oriSomething你不太正确。 中继也解决了很多状态管理。

@gyzerok我的意思是客户端应用程序状态

@oriSomething是的，我在谈论客户端应用程序状态

@gyzerok我必须错过它。 你能给我一个链接吗？

@oriSomething没有特殊的链接，因为Relay隐式管理它。 也许您可以尝试观看FB关于中继的讨论。 他们谈论中继如何解决缓存问题。 客户端应用程序缓存=状态。 我记不清说话了，对不起。

@ori所以这里是开发人员应该执行一些显式状态管理的唯一位置。

@gyzerok好的，那么在那种情况下，是否存在与中继服务器无关的状态管理？ 据我了解，不是吗？

@oriSomething如果我对您的理解是正确的，那么Relay会执行有关客户端上的数据规范化以及将查询中的数据合并到单个存储中的所有操作。

@oriSomething是的，它确实=> https://facebook.github.io/relay/img/Guides-Containers-HOC-Relay.png
检查： https :

仅当客户端上的数据不足时，中继才会向服务器发送请求以获取更多数据。

Redux的级别比Relay低得多，并且比普通的JS对象和函数“过去”更“过去”。 中继是一个框架，没有进行健全性检查的Redux是十个10线性函数，因此它们具有不同的作用域也就不足为奇了。

因此，我只是出于好玩而制作了slim-redux.js，这是Redux的一个版本，没有注释，开发人员警告和健全性检查。 它通过了所有必要的Redux测试（完整性检查测试除外），并且它是99行：wink：。 这足以说明我的观点，即Relay和Redux是范围非常不同的工具。

@IwanKaramazow我认为我还不够清楚，我想说的是，不是所有数据都与服务器有关，没有与服务器管理无关的数据，而且我真的不认为中继即使可以管理此数据，也可以使用“工具”

@oriSomething您能举个例子吗？

完全同意@mattapperson 。 一切都归结为复杂的定义，或更确切地说，是每个人都可以识别“复杂事物”的地方

@IwanKaramazow我认为@oriSomething例如谈论客户端表单状态

由于GraphQL，我从Redux => Relay移出。 大多数情况下，我的应用程序中的所有资源都是分层的。 它们自然是嵌套实体。 在Redux中保留这些模型的缓存非常了不起。 我对数据有一个健全的看法，并且可以使用令人敬畏的redux-devtools快速进行迭代。

但是在没有GraphQL的情况下，我不得不进行几次往返，以将远程资源映射到redux树。

1. / resource1-list
2. / resource2-list？resource1 =
3. / resource3-list？resource2 =

显然，这是REST而不是Redux的问题。 如果我早些时候看过一些Redux-GraphQL绑定，也许我会使用它们。 在我的应用程序中，采用Relay的变化很小。 我使用的是Relay.createContainer而不是@connect Relay.createContainer 。 两种产品对具有不同API的架构具有相同的见解。 我为此写了一篇快速文章。

我目前正在同时使用redux和relay / graphql，尽管Relay对于数据获取来说非常了不起，但我可以看到自己一直在使用redux。 我目前使用redux的原因有两个，以后我会发现自己发现了更多原因

1）需要在不存在于数据库中的组件之间共享的其他状态
2）表格准备。 实际上，在我的应用程序的一部分中，我有一个带有提交按钮的工具栏组件和一个包含我所有输入字段的面板组件。 当我键入表单时，我会将输入反跳入存储在redux中的“表单缩减器”中，以便我的工具栏可以在提交之前访问数据。

另外，redux devtools也很棒。

真是的我今天一直在阅读Relay，我必须承认代码不容易阅读也不容易理解。 我查看了Redux的几个示例，仅阅读代码就能够掌握核心概念。

该教程或Todo示例似乎并不优雅。 我认为React和FLUX以简单为荣。 到目前为止，我还没有从Relay那里得到那种感觉。

考虑到Relay与React的紧密联系以及大多数应用程序在复杂性方面的过高杀伤力，最近我更加热衷于Falcor。 实际上，由于其基于Promise的界面，它非常适合您在Redux中执行大多数异步行为的方式。 而且由于它与React分离，所以我可以在我的应用程序中更轻松地使用它。 另外，服务器端渲染还没有完全完成，这对我来说不是一个入门者。

我也很喜欢react-resolver ，类似于“ Relay Lite”。 对于非常简单的项目或依赖第三方REST API的项目，最终可能是最好的选择。

@timdorr您是否尝试过将所有状态存储在Falcor中？ 例如，让减速器使用Falcor对象。

还没。 我仍在使用它进行实验，在我的项目中还有很多鱼要炒，所以我还没有给予足够的重视。

我曾与Falcor一起玩过，我强烈推荐它。 实际上，我现在正在将Redux应用程序与Falcor后端集成在一起。 它不会为您提供Relay的查询聚合，但是它在其客户端库中具有非常复杂的缓存层，可防止超载。 我认为这可能已经足够了，但是时间会证明一切。

@gaearon与使用Elm编写同一应用程序相比，编写具有声明性数据获取的React Web应用程序有何不同？

在我看来，主要的区别在于，使用Relay＆GraphQL来获取数据更具声明性（Elm要求您指定一个URL，并且您可以对返回的数据进行排序），而Elm中的其他所有内容都更具声明性。

实际上，Elm生态系统似乎可以从Relay / GraphQL端口中受益。

关于查询聚合，有Model.batch方法。 它需要一个时间间隔（以毫秒为单位）或一个调度程序，但是我找不到关于调度程序的大量文档。

如果您不介意我问，您如何集成Redux和Falcor？ 我所有的尝试使我感到沮丧。

我也想看看Redux Falcor的例子。 我已经阅读了所有的Falor文档，并同意它比relay / graphql简单得多。 尽管功能较差。

对于任何想了解Redux与Relay的关系以及一起使用它们是否有意义的人，请参阅： https :

要点是，Relay最终将处理来自多个源的数据（后端，本地临时数据等），因此它将替换您可能使用的其他Flux实现。

https://github.com/facebook/relay/issues/168#issuecomment -135169255：

请注意，Relay是Flux模式的实现（Flux可以代替自己吗？;-）。

我们在OpenGov大量使用Redux和Relay。 的确，自从转移到Relay之后，我们的reducers/文件夹变得越来越小。 但是，我们发现Redux对于应用程序级本地状态管理仍然非常有用。 也许有一天Relay也会在那个地区取代它。 但是正如@josephsavona所说的那样，“ Redux体系结构”实际上只是...函数:)即使有一天从Redux库继续前进，您也可能会继续使用不变的状态更新，反应性数据流，reducer功能等。 这是Redux IMO的有价值的部分，不一定是此存储库中存在的<100行库。 （哦，当然还有社区。）

我想说的是，如果您的应用程序非常注重数据（如Facebook）（许多具有复杂关系的嵌套实体），那么最好投资GraphQL后端并学习Relay。

同意，但是我认为GraphQL + Relay即使对于大小适中的应用程序也是一个不错的投资，尤其是对于从头开始的新项目。

你们如何看待https://github.com/gyzerok/adrenaline？

不完全合适，因为它不使用Relay，但是您如何看待流星社区中这种自以为是的全栈方法呢？ https://github.com/mattkrick/meatier

只有像GraphQL / Relay或Datomic / Om.Next这样的深层架构才能解决对象/关系阻抗问题...这是我的想法-感谢反馈。

GraphQL / Relay：Redux的终结？

似乎有很多人对此主题感兴趣（中继/ Redux，GraphQL和降低复杂性），我正在为一个简单而功能强大的GraphQL客户端进行设计，该客户端将与Redux的应用程序状态方法很好地配合使用。

好奇人们如何看待这套设计原则： https :

只需在此处添加我的2cents：我认为Redux不会结束。 它简单漂亮，在许多情况下足够了。 JS生态系统是如此之快且难以跟上，Redux和React在某种程度上是我们可以依靠的里程碑。 我们只是不能每月（或至少不能）发展我们的工作流程，而且我认为Redux现在确实是一个不错的选择。 在许多项目中只是不需要中继（通常是数据获取）……

@gaearon ，距离您发布此帖子已经有几个月了，您刚刚在React会议上发表了有关Redux的演讲。 与Relay /相比，或者说这三者的结合，您现在说的是与Redux的GraphQL集成？

@likeabbas如果您正在寻找GraphQL-Redux集成，请尝试Apollo Client： http ://docs.apollostack.com/apollo-client/index.html

我们尚不具备与Relay的100％功能同等功能，但我们正在接近。

@gaearon呼应从@likeabbas的问题：“你会在哪里说，我们现在是在GraphQL一体化方面具有终极版相比，继电器/，或者也许是所有三个结合”

几个简短的想法。 Redux是一个通用框架，它提供了足够的结构和足够的灵活性之间的平衡。 这样，它为开发人员提供了一个平台，可为他们的用例构建自定义的状态管理，同时能够重用图形调试器或中间件之类的东西。 该用例似乎不太可能消失，因此与其说“ Redux的时光已经过去了”，不如说是一个更有趣的问题：如果您要构建GraphQL客户端，那么在Redux上构建是否有意义？

我要回答的问题是，尚无一个正确的答案。 在Redux上构建可能会受益于集成（共享工具，共享数据），而构建自定义方法则需要更多工作，但允许使用更多特定于域的工具，并可能实现更好的性能。 与软件开发中的许多事情一样，它取决于用例！

@josephsavona ：这是Redux的_great_摘要！ 我们可能不得不在某个地方窃取这些文档：)

是的，该线程的标题不是最佳的，似乎这个问题已经用尽了。 也许是时候将讨论移到其他地方了。

>.> lock the issue

我将把它关闭。 不知道是否有任何解决办法。 Redux为某些人工作，这对我来说已经足够了。

糟糕，错误的按钮。 对不起😄