下载Telerik UI for ASP.NET AJAX最新版本Download
在React应用程序中学习一些有关使用State的快速和重要提示，以帮助您确定哪种选项，适合您的环境。
不要害怕以setState（）开头
首先，如果您是React的新用户，或者开始使用新的React应用程序，请从React的内置状态功能开始。除非你完全确定新的应用程序将成为一个复杂的庞然大物，否则就要抵制从州管理解决方案开始的冲动。我提出这个建议有两个原因。首先，如果你是React的新手，你应该在引入外部依赖之前专注于学习React的细节。Redux和MobX很棒，但是在学习React的同时学习状态解决方案不仅会使你的学习曲线变得陡峭，而且会使你对两者的理解变得混乱。熟悉React，然后，当时机成熟时，再添加一块拼图。
需要时，可以使用Redux或MobX ......
您正在构建的应用程序可能会保持很长时间，并且您可能会发现setState（）是处理组件内部和组件之间的UI更改的良好解决方案。那么什么时候考虑将Redux或MobX添加到您的应用中？
没有硬性规定。复杂性倾向于蔓延到我们的应用程序中并突然停止。当您发现自己一次又一次地在组件之间传递状态或者在级别之后冒出子组件状态级别以便父级或更高级组件可以使用该状态时，您将知道它是时候找到解决方案了。
Redux和MobX都围绕实现一个或多个商店来管理状态的原则进行组织。然后，组件将状态更改分派给这些存储，并在需要访问状态时订阅状态更改。这些模式为您的应用程序带来了间接性和复杂性，但是当您的应用程序本身的状态变得复杂时，最好选择其中一种。
继续使用setState（）是好的
最后，如果您决定实施状态管理解决方案，请在某些情况下随时继续使用setState（）。 考虑一下：在子组件中按下一个按钮来更新该组件的UI但是在层次结构的其他地方没有影响真的需要进入状态存储吗？ 可能不是。
我第一次实现Redux时犯的错误之一是将所有内容放入Redux存储库，为每个UI更改创建操作和缩减器。这有其自身形式的爬行复杂性，如果不加以控制，可能会让您想知道您是否曾经需要一个状态管理解决方案。 很多时候，即使使用Redux或MobX等解决方案，也可以继续使用本地组件状态。我个人的经验法则是使用完全独立的本地状态UI交互，或者使用可移植的组件，因此不依赖于全局存储。
示例：在最近的项目中，我们创建了一个Map组件，该组件在应用程序的多个位置使用，以显示事件详细信息，当前位置等。组件依赖于状态（通过Props）显示它所显示的数据，但我们使用本地状态来管理内部状态，例如选择了哪个映射引脚，以及是否应显示信息窗口。构造函数看起来像这样：
class Map extends Component {
constructor (props) {
super(props)
this.state = {
showingInfoWindow: false,
activeMarker: null,
selectedPlace: {},
map: null
}
}
onMarkerClick (props, marker, e) {
this.setState({
selectedPlace: props,
activeMarker: marker,
showingInfoWindow: true
})
}
onInfoWindowClose () {
this.setState({
showingInfoWindow: false,
activeMarker: null
})
}
onMapClicked (props) {
if (this.state.showingInfoWindow) {
this.setState({
showingInfoWindow: false,
activeMarker: null
})
}
}
onMapReady (mapProps, map) {
const { agency, languageCode } = this.props
this.setState({
map: map
})
if (agency) {
const assignees = agency.details.assignees
if (assignees.regions) {
assignees.contract.map(region => {
// Do things
})
}
}
}}
结论
底线：可以使用本地状态，特别是如果它可以帮助您保持全球状态清洁和有条理。 在开始一个新的React应用程序时，无论你是React新手还是经验丰富的专业人士，都可以尝试从跳转中添加状态管理解决方案。不过，在此之前，请记住YAGNI并考虑等到时机成熟。