我在看Pluralsight关于React的课程,老师说道具不应该被改变。我现在正在读一篇关于道具vs.国家的文章(uberVU/react-guide),它说
道具和状态更改都会触发呈现更新。
文章后面说:
Props(属性的缩写)是组件的配置,如果可以的话,是它的选项。它们是从上面接收的,是不可变的。
所以道具可以改变,但它们应该是不可变的?
什么时候应该使用道具,什么时候应该使用状态?
如果你有一个React组件需要的数据,它应该通过道具或设置在React组件通过getInitialState?
给出最简单的解释,补充上述评论:
根据React的官方文档,他们将“状态”视为
To “remember” things, components use state.
props可以理解为从父组件传递给子组件的变量。
如果你想在应用中记住一些东西,你会使用状态如果你想传递数据,你会使用道具。
让我给你另一个类比,假设你想把你脑子里的前25个自然数的序列相加。
1+2+3+4.....
从1开始,然后加2,现在是3,然后加到现在的总数(6),然后加4到现在的总数(6),所以新的总数是10。
当前的总和是程序的状态,假设您需要找到总和的平均值。你要把这个和代入一个方程,然后把这个和作为道具传下去。
希望这能说得通。
state -这是一个特殊的可变属性,保存组件数据。它在Componet挂载时具有默认值。
props -这是一个特殊的属性,本质上是不可变的,用于从父到子的值传递。props只是组件之间的通信通道,总是从顶部(父组件)移动到底部(子组件)。
下面是结合状态和道具的完整示例
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<title>state&props example</title>
<script src="https://unpkg.com/react@0.14.8/dist/react.min.js"></script>
<script src="https://unpkg.com/react-dom@0.14.8/dist/react-dom.min.js"></script>
<script src="https://unpkg.com/babel-standalone@6.15.0/babel.min.js"></script>
</head>
<body>
<div id="root"></div>
<script type="text/babel">
var TodoList = React.createClass({
render(){
return <div className='tacos-list'>
{
this.props.list.map( ( todo, index ) => {
return <p key={ `taco-${ index }` }>{ todo }</p>;
})}
</div>;
}
});
var Todo = React.createClass({
getInitialState(){
return {
list : [ 'Banana', 'Apple', 'Beans' ]
}
},
handleReverse(){
this.setState({list : this.state.list.reverse()});
},
render(){
return <div className='parent-component'>
<h3 onClick={this.handleReverse}>List of todo:</h3>
<TodoList list={ this.state.list } />
</div>;
}
});
ReactDOM.render(
<Todo/>,
document.getElementById('root')
);
</script>
</body>
</html>
亲子交流,只需传递道具即可。
使用state在控制器视图中存储当前页面所需的数据。
使用道具将数据和事件处理程序传递给你的子组件。
这些列表应该有助于指导您在组件中处理数据。
道具
是不可变的
它可以让React进行快速参考检查
用于从视图控制器向下传递数据
顶级组件
有更好的表现
使用它将数据传递给子组件
状态
是否应该在视图控制器中进行管理
顶级组件
是可变的
表现更差
不应该从子组件访问
用道具把它传下去
For communication between two components that don't have a
parent-child relationship, you can set up your own global event
system. Subscribe to events in componentDidMount(), unsubscribe in
componentWillUnmount(), and call setState() when you receive an event.
Flux pattern is one of the possible ways to arrange this.
- https://facebook.github.io/react/tips/communicate-between-components.html
What Components Should Have State?
Most of your components should simply take some data from props and
render it. However, sometimes you need to respond to user input, a
server request or the passage of time. For this you use state.
Try to keep as many of your components as possible stateless. By doing
this you'll isolate the state to its most logical place and minimize
redundancy, making it easier to reason about your application.
A common pattern is to create several stateless components that just
render data, and have a stateful component above them in the hierarchy
that passes its state to its children via props. The stateful
component encapsulates all of the interaction logic, while the
stateless components take care of rendering data in a declarative way.
- https://facebook.github.io/react/docs/interactivity-and-dynamic-uis.html#what-components-should-have-state
What Should Go in State?
State should contain data that a component's event handlers may change
to trigger a UI update. In real apps this data tends to be very small
and JSON-serializable. When building a stateful component, think about
the minimal possible representation of its state, and only store those
properties in this.state. Inside of render() simply compute any other
information you need based on this state. You'll find that thinking
about and writing applications in this way tends to lead to the most
correct application, since adding redundant or computed values to
state means that you need to explicitly keep them in sync rather than
rely on React computing them for you.
- https://facebook.github.io/react/docs/interactivity-and-dynamic-uis.html#what-should-go-in-state