Open hushicai opened 6 years ago
原文链接:You Might Not Need Redux 原文作者:Dan Abramov
人们常常在真正需要Redux之前,就选择使用它。
“如果不使用Redux,我们的应用无法扩展怎么办?”
应用接入Redux之后,开发者就开始头疼了。
“为什么开发一个简单的功能需要创建 3 个文件?”
为什么!
人们痛苦地抱怨Redux、React、FP、不可变数据和一些别的东西,但我理解他们。
那些不需要"模版"代码来更新应用状态的方法自然比使用 Redux 更为简单。
这说得没错,设计上也是如此。
Redux提供了一种权衡,它要求:
无论是不是React应用,这些限制都不是创建一个应用所必须的。
事实上,这些都是非常强的约束,在把它们加入应用之前,你应当慎重考虑。
有没有一些好的理由来使用Redux?
当然是有的!
Redux同时也能够使应用拥有以下的特性:
如果,你正在开发一个可扩展的终端、JavaScript 调试器或是某些类型的应用,那么 Redux 也许值得一试。
至少,它是值得考虑的。(顺便说一句,这些并不是什么新技术)
然而,如果你只是学习React,那么,Redux并不是你的首选。
与之相反,你该看看"Thinking In React"。
当你有真正地需要或想玩一些新东西的时候,才去尝试Redux。
然而,就像你使用其他强限制的工具一样,谨慎地选择是否使用它。
如果,你觉得用Redux的方式编码有压力,那可能意味着你或你的伙伴对此太较真了。
Redux只是你工具箱中的一件工具,一种尝试。
最后,记住你可以将Redux的理念运用到你的应用中,但不使用Redux。
试想一下,一个拥有本地状态的 React 组件:
import React, { Component } from 'react'; class Counter extends Component { state = { value: 0 }; increment = () => { this.setState(prevState => ({ value: prevState.value + 1 })); }; decrement = () => { this.setState(prevState => ({ value: prevState.value - 1 })); }; render() { return ( <div> {this.state.value} <button onClick={this.increment}>+</button> <button onClick={this.decrement}>-</button> </div> ) } }
这是非常合理的。
认真地说,它值得重复使用。
本地状态是好的。
Redux提供的权衡是通过增加中间环节来将“发生了什么”和“该如何变化”之间进行解耦。
这样做是不是总是正确的呢?不,这是一种权衡。
比如,我们可以从组件中将 reducer 抽出:
import React, { Component } from 'react'; const counter = (state = { value: 0 }, action) => { switch (action.type) { case 'INCREMENT': return { value: state.value + 1 }; case 'DECREMENT': return { value: state.value - 1 }; default: return state; } } class Counter extends Component { state = counter(undefined, {}); dispatch(action) { this.setState(prevState => counter(prevState, action)); } increment = () => { this.dispatch({ type: 'INCREMENT' }); }; decrement = () => { this.dispatch({ type: 'DECREMENT' }); }; render() { return ( <div> {this.state.value} <button onClick={this.increment}>+</button> <button onClick={this.decrement}>-</button> </div> ) } }
发现没有,我们不必运行 npm install 就能使用Redux,酷!
状态组件能不能也这样做?可能不行。
也就是说,除非你有打算从额外的中间环节中受益。
在当前这个时代,想法才是关键。
Redux库本身只是提供一系列帮助方法,将reduces“挂载”到全局唯一的 store 对象上。
你可以尽可能少,或尽可能多得使用Redux,随你的便。
但是,如果你付出了一些东西,确保你同时也能获得一些回报。
[译] 从零开始,在 Redux 中构建时间旅行式调试
Redux 应用程序的状态是在一个线性的可预测的时间线上生成的。
人们常常在真正需要Redux之前,就选择使用它。
“如果不使用Redux,我们的应用无法扩展怎么办?”
应用接入Redux之后,开发者就开始头疼了。
“为什么开发一个简单的功能需要创建 3 个文件?”
为什么!
人们痛苦地抱怨Redux、React、FP、不可变数据和一些别的东西,但我理解他们。
那些不需要"模版"代码来更新应用状态的方法自然比使用 Redux 更为简单。
这说得没错,设计上也是如此。
Redux提供了一种权衡,它要求:
无论是不是React应用,这些限制都不是创建一个应用所必须的。
事实上,这些都是非常强的约束,在把它们加入应用之前,你应当慎重考虑。
有没有一些好的理由来使用Redux?
当然是有的!
Redux同时也能够使应用拥有以下的特性:
如果,你正在开发一个可扩展的终端、JavaScript 调试器或是某些类型的应用,那么 Redux 也许值得一试。
至少,它是值得考虑的。(顺便说一句,这些并不是什么新技术)
然而,如果你只是学习React,那么,Redux并不是你的首选。
与之相反,你该看看"Thinking In React"。
当你有真正地需要或想玩一些新东西的时候,才去尝试Redux。
然而,就像你使用其他强限制的工具一样,谨慎地选择是否使用它。
如果,你觉得用Redux的方式编码有压力,那可能意味着你或你的伙伴对此太较真了。
Redux只是你工具箱中的一件工具,一种尝试。
最后,记住你可以将Redux的理念运用到你的应用中,但不使用Redux。
试想一下,一个拥有本地状态的 React 组件:
这是非常合理的。
认真地说,它值得重复使用。
Redux提供的权衡是通过增加中间环节来将“发生了什么”和“该如何变化”之间进行解耦。
这样做是不是总是正确的呢?不,这是一种权衡。
比如,我们可以从组件中将 reducer 抽出:
发现没有,我们不必运行 npm install 就能使用Redux,酷!
状态组件能不能也这样做?可能不行。
也就是说,除非你有打算从额外的中间环节中受益。
在当前这个时代,想法才是关键。
Redux库本身只是提供一系列帮助方法,将reduces“挂载”到全局唯一的 store 对象上。
你可以尽可能少,或尽可能多得使用Redux,随你的便。
但是,如果你付出了一些东西,确保你同时也能获得一些回报。