使用Redux而不是Flux的缺点是什么？

我刚刚发现Redux 。 这一切看起来不错。 是否有任何缺点，使用Redux而不是Flux的问题？ 谢谢

Redux的作者在这里！

我想说，你会使用它作出以下妥协：

  • 你需要学会避免突变。 通量是关于变异数据的select，但是Redux不喜欢突变，许多与Redux互补的包假设你从不改变状态。 你可以用像devx-immutable-state-invariant这样的仅限于开发包，使用Immutable.js ，或者相信你自己和你的团队编写非可变的代码，但是这是你需要注意的，这需要是你的团队接受的有意识的决定。

  • 你将不得不认真挑选你的软件包。 虽然Flux明确没有尝试解决诸如撤消/重做 ， 持久化或表单等“附近”问题，但是Redux具有诸如中间件和存储增强器等扩展点，并且催生了一个年轻但丰富的生态系统 。 这意味着大多数软件包是新的想法，并没有得到使用的临界量。 几个月后，你可能会依赖某些明显不好的想法，但目前还很难分辨。

  • 你将不会有一个很好的stream量集成。 Flux目前可以让你做非常令人印象深刻的静态types检查 ，Redux 目前还不支持 。 我们会到达那里，但这需要一些时间。

我认为第一个是初学者最大的障碍，第二个可能是过激的尝鲜者的问题，第三个是我个人的宠儿。 除此之外，我不认为使用Redux会带来Flux避免的任何特殊的缺点，有些人甚至说Flux相比Flux有一些好处。

另请参阅我的回答使用Redux的好处 。

Redux和Flux都需要大量的样板代码来覆盖许多常见模式，特别是那些涉及asynchronous数据提取的模式。 Redux文档已经为减less样板文件提供了一些示例： http : //redux.js.org/docs/recipes/ReducingBoilerplate.html 。 从Alt或Fluxxor等Flux库中可以获得所需的所有内容，但是Redux更喜欢自由而不是function。 对于一些开发者来说，这可能是一个不利因素，因为Redux会对你的状态做出某些假设，而这可能会被无意中忽视。

你真正回答你的问题的唯一方法是尝试Redux，如果你可以，也许在一个个人项目。 Redux的出现是因为需要更好的开发人员经验，而且它偏向于函数式编程。 如果你不熟悉reducers和函数组合等function概念，那么你可能会减慢速度，但只是略微。 在数据stream中包含这些想法的好处是testing和预测更容易。

免责声明：我从Flummox（stream行的Flux实现）迁移到Redux，其优势远远超过了任何缺点。 我更喜欢我的代码中less得多的魔法。 更less的魔法是花费更多的样板，但这是一个非常小的代价。

通量和回报 。 。 。

Redux不是纯粹的Flux实现，而是受Flux的启发。 最大的区别在于它使用一个包含一个包含应用程序所有状态的状态对象的存储。 而不是像Flux那样创build商店，你会写Reducer函数来改变单一的对象状态。 这个对象代表你的应用程序中的所有状态。 在Redux中，您将获得当前的操作和状态，并返回一个新的状态。 这意味着行动是连续的，国家是不可改变的。 这使我想到Redux中最明显的骗局（在我看来）。

Redux支持一个不变的概念。

为什么不可变性？

有几个原因：
1. 一致性 – 商店的状态总是被减速器改变，所以很容易跟踪谁改变了什么。
2. 性能 – 因为它是不可变的，Redux只需要检查以前的状态！==当前的状态，如果是这样的渲染。 不需要每一次循环状态来确定渲染。
3. debugging – 新的真棒概念，如时间旅行debugging和热重新加载 。

更新：如果这不足以说服，请观看关于不可变用户界面的 Lee Byron精彩的演讲。

Redux需要开发者通过代码库来维护这个想法。 您需要确保select库并以不可变的方式编写代码。

如果您想了解更多关于Flux概念的不同实现（以及最适合您的需求），请查看这个有用的比较。

在这之后，我必须承认Redux是JS未来发展的方向（至于写这些行）。

在其他Flux替代scheme中使用Redux的最大好处之一是能够将您的思维方向重新定位为更加实用的方法。 一旦你了解电线如何连接，你就会意识到其惊人的优雅和简单的devise，永远不会回头。

我更喜欢使用Redux，因为它使用了一个与Flux相比使得状态pipe理更容易的商店， Redux DevTools也是非常有用的工具，可以让你看到你用你的状态来处理一些有用的数据，而且它与React开发工具真正联系在一起。

另外， Redux和Angular等其他stream行的框架一起使用也变得更加灵活。 无论如何，让我们看看Redux如何将自己介绍为一个框架。

Redux有三个原则可以很好地引入Redux，它们也是Redux和Flux的主要区别。

单一的事实来源

整个应用程序的状态存储在单个存储中的对象树中。

这使得创build通用应用程序变得很容易，因为您的服务器的状态可以被序列化，并且无需额外的编码工作即可融入客户端。 单个状态树也使debugging或检查应用程序更容易; 它也使您能够坚持开发您的应用程序的状态，以更快的开发周期。 一些传统上难以实现的function – 例如撤消/重做 – 可能会突然变得微不足道，如果所有的状态都存储在一棵树中的话。 

 console.log(store.getState()) /* Prints { visibilityFilter: 'SHOW_ALL', todos: [ { text: 'Consider using Redux', completed: true, }, { text: 'Keep all state in a single tree', completed: false } ] } */

状态是只读的

改变状态的唯一方法是发出一个动作，一个描述发生的事情的对象。

这确保了视图和networkingcallback都不会直接写入状态。 相反，他们expression了转变国家的意图。 因为所有的变化都是集中的，严格的一个一个地发生，所以没有细微的竞争条件需要注意。 由于操作只是普通的对象，因此可以对其进行logging，序列化，存储以及稍后重放以用于debugging或testing目的。 

 store.dispatch({ type: 'COMPLETE_TODO', index: 1 }) store.dispatch({ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_COMPLETED' })

用纯函数进行更改

要指定状态树如何通过操作进行转换，可以编写纯粹的reducer。

Reducers只是一个纯粹的函数，它会采用之前的状态和一个动作，并返回下一个状态。 记住要返回新的状态对象，而不是改变以前的状态。 您可以从一个reducer开始，随着您的应用程序的增长，将其分解成更小的reducer来pipe理状态树的特定部分。 因为reducer只是函数，所以你可以控制它们的调用顺序，传递额外的数据，甚至可以为诸如分页之类的常见任务创build可重用的reducers。 

 function visibilityFilter(state = 'SHOW_ALL', action) { switch (action.type) { case 'SET_VISIBILITY_FILTER': return action.filter default: return state } } function todos(state = [], action) { switch (action.type) { case 'ADD_TODO': return [ ...state, { text: action.text, completed: false } ] case 'COMPLETE_TODO': return state.map((todo, index) => { if (index === action.index) { return Object.assign({}, todo, { completed: true }) } return todo }) default: return state } } import { combineReducers, createStore } from 'redux' let reducer = combineReducers({ visibilityFilter, todos }) let store = createStore(reducer)

欲了解更多信息请访问这里

Redux需要有关不可变性的纪律。 我可以推荐的东西是ng-freeze，让你知道任何意外的状态变化。

Interesting Posts