“Props”是传递给组件(1)的外部输入，“state”是由组件(2)管理的内部私有数据。

用户在应用程序的某个地方输入了一些数据。

在其中输入数据的组件应该在其状态中拥有该数据，因为它需要在数据输入期间操作和更改它 在应用程序的其他任何地方，数据都应该作为道具传递给所有其他组件

所以，是的，道具是在变化的，但它们是从“源头”改变的，然后简单地从那里向下流动。所以道具在接收它们的组件的上下文中是不可变的。

例如，在一个参考数据屏幕上，用户编辑一个供应商列表将在状态下管理它，然后会有一个操作，导致更新的数据保存在ReferenceDataState中，它可能比AppState低一级，然后这个供应商列表将作为道具传递给所有需要使用它的组件。

基本上，区别在于状态类似于OOP中的属性:它是类(组件)的局部属性，用于更好地描述它。道具就像参数一样——它们从组件的调用者(父组件)传递给组件:就像你调用一个带有特定参数的函数一样。

这是我目前对于状态与道具之间的解释的观点

State就像组件中的局部变量。你可以操纵 使用set state获取state的值。然后可以传递state的值 例如，您的子组件。 Props是位于redux存储中的值 来源于来源于减速器的状态。您的组件 应该连接到redux从道具中获取值。你也可以通过 你的props值给你的子组件

道具——你不能改变它的值。 States—您可以在代码中更改它的值，但当呈现发生时它将是活动的。

亲子交流，只需传递道具即可。

使用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