现在在生产环境中使用Redux合适吗？

#1

公司最近要将前端的项目全部使用React重构，所以最近一直在看React相关的东西。

算是个不大不小的项目，预计是到年底做完，如果现在就直接选用Redux的话会不会早了点？

如果不行的话，还想问一下基于React的前端架构有哪些其他比较成熟的选择呢？求各位大大答疑解惑。

#2

也关心这个问题，打算新项目用。flux这个概念实现太多，也真是很让人困扰。

#3

为什么不自己实现个呢

#4

其实纠结这个问题，也是因为没基础。比如我也就是AngularJS做过几个项目，React刚刚入门，这个阶段别说造轮子，就连造好的轮子是圆的是方的都看不出来。

1 Like
#5

建议先了解Flux想要解决的问题和解决方案的思路，然后对比一下自己之前程序的解决方法和Flux对比一下，可能会更好的判断是不是该用Flux或者是不是该用现成的Flux实现。

如果不理解Flux每个部分的职责和局限的话，光是引入别人的Flux库可能也不会有很多优点。就像MVC框架一样，光是引入MVC然后把类分成M、V和C并不能保证写出来清晰的MVC程序。

如果自己实现也不必说是重复造轮子，因为困难的部分都在React，看一下官方的Flux就会发现Flux部分的代码超短的，自己写搞不好还有利于理解架构。

#6

还没深入看过, 建议到官方 Issues 上边跟开发人员一起混一下, 深入了解一下.
毕竟现在还是没有正式发布 1.0 对吧

#7

感谢大家的回复，已经watch了Redux项目，不过目前还是观望下

果然还是先把React本身弄好再说……

#8

redux 1.0.0-rc已经可以通过npm安装了. 对应的是breaking-changes-1.0这个branch, 基本上应该和要发布的1.0.0版本的API一致了.

我看上redux的原因特别搞笑，因为本来就没经验，只是对flux有个大概结构上的了解，所以完全说不上判断框架的好坏。不过看了redux提供的两个sample，觉得项目结构真是又简单又实用，按照自己的要求，改改webpack.config.js也不是麻烦事情，比起react-starter-kit这些成熟的项目维护起来要省心很多。所以立刻心理就觉得这个东西靠谱。另外一个因素也很搞笑，最近非常迷信ES6，看来看去，好像还是redux这样新框架，更符合ES6的规范。

不过也还是有小小的阴影，react-redux的issue3看着就莫名奇妙的，希望真的只是dom结构回收比较慢吧。

#9

Redux 从 Dan 写了那篇 blog 开始，我就一直跟了很久，越来越没有想用的欲望。

  1. 函数式编程：Dan 自己也在 twitter 上说，Redux 对于 FP-guys，和 Non-FP-guys，都难于理解。现在 FP 挺火，github 上本月最火的 repo 就是 FP 的教程。但是，毕竟是一种相对未成主流的编程范式。

  2. ES7的语法：这是令我望而却步的原因。我虽然是从 Java 过来的，更久之前也写过 C#，对 ES6 引入的 Class 并不畏惧。但依然坚持用 ES5 的 function 来写。原因就是1，FP。我目前是准备学习 FP 的。竟然还引入了 ES7 的 decorator 语法。这个 Dan 也在 twitter 上说，他本人是不喜欢 Class 的，是用 Class 是因为提供了清晰的代码结构。React.createClass 是 JavaScript 的（伪）类的实现，但翻看源码发现其实做了几件事（autobind，props, state，inject mixins)，本质还是返回一个 function。参看 Elliott 的这篇 blog。当然他现在写了一个 stampit 的库，这个对于社区更加陌生了。

  3. Redux 引入很多的 concepts。这一点和原生 flux 相比有好有坏。原生 Flux 是一个 pub/sub。和一般的 pub/sub 相比，主要区别在于：

  1. 回调并不会订阅特定的事件。每一个 payload 都会分派给所有注册的回调。
  2. 回调会被整个或者部分延迟，以等待其他回调执行完毕。
    而，Redux 目前引入了一个 middleware 的概念。这个是 fluxmmox 的作者 acdlite 加入后，引入的概念。我当时觉得 Redux 自此已经偏离他那篇初始博客的本意了。code base 越来越复杂。这一点 Facebook 就做的很好，不引入复杂的概念，使用 ubiquitous 的概念。

同意 @pinyin 的，可以自己实现一个。不过，flux 本身是一个 data flow 的概念，官方Flux 本身就是一个 pub/sub， 不能称为实现，我现在倾向于称为是做减少 boilerplate 的工作。

5 Likes
#10

是的，实在是太复杂了。

#11

现在用的比较好的还是reflux吧？

#12

我觉得完全没有什么问题，Redux绝对是React最好的Flux框架

#13

最新版是没有什么问题的，redux比较适合大的项目，因为要整体去架构一个整体布局需要点时间的，比如action里面你要做哪些基本的操作，这个是要进行规划才能进行的任务，如果是一个简单的玩玩的话，就算了。我之前也用过reflux，是简单，易理解，但问题是，如果使用es6的语法写react的话就会有问题，不能使用mixin啦，如果用的话，就是es6里面加入了不是es6的语法，就有点混了，不是很纯净，redux跟react结合比较还是比较适合的，推荐，哈哈

#14

在用，没什么问题，现在遇到最大的问题还是react在移动端速度不容乐观

#15

很合适，我们公司就在生产环境中使用。自己有个学习型项目，前端是用的React + Redux，在此访问：http://www.hieat.me/sign （后端用的Play 2，不感兴趣的同学请忽略）

#16

上周刚把项目从官方的 flux + immutable 转成 redux + immutable 用 jscodeshift 做了大量的代码批量修改，挺顺利。

redux 和 flux 代码量都不是太大，合适不合适使用，主要而在于自己或团队对 flux / redux 它们提供的解决方案，思路是否理解到位。

#17

本来想访问一下的，怎么网站挂了。。。

#18

react在移动端速度不容乐观

是因为文件大的原因吗

与cordova结合的话，情况如何

#19

可以试试，这是我写的react+redux系列教程
https://github.com/lewis617/myReact

#20

reflux、redux都做过多语言切换的案例，reflux入门容易，redux概念多，需要时间理解，reflux没有深入，但是redux的确很强大