我刚开始使用ReactJS，我有一个问题。
我的应用程序本质上是一个带有过滤器和更改布局的按钮的列表。 目前我正在使用三个组件:<list />， < Filters />和<TopBar />，现在显然，当我在< Filters />中更改设置时，我想在<list />中触发一些方法来更新我的视图。
我如何使这3个组件相互交互，或者我是否需要某种全局数据模型，我只需要对其进行更改?
当前回答
我看到这个问题已经有了答案，但如果你想了解更多细节，组件之间的通信总共有3种情况:
案例1:父到子通信 案例2:子到父通信 案例3:不相关的组件(任何组件到任何组件)通信
其他回答
我曾经是你现在的位置，作为一个初学者，你有时会觉得不适应如何反应的方式来做这件事。我将尝试用我现在思考的方式来解决这个问题。
国家是交流的基石
通常它归结于你改变这个组件的状态的方式在你的例子中你指出三个组件。
<List />:它可能会根据筛选器显示项目列表 <Filters />:筛选将更改数据的选项。 <TopBar />:选项列表。
为了协调所有这些交互你需要一个更高的组件我们叫它App，它会把动作和数据传递给每个组件例如，它看起来是这样的
<div>
<List items={this.state.filteredItems}/>
<Filter filter={this.state.filter} setFilter={setFilter}/>
</div>
因此，当setFilter被调用时，它将影响filteredItem并重新渲染两个组件;。如果这不是完全清楚，我给你一个例子，你可以在一个文件中检查复选框:
import React, {Component} from 'react';
import {render} from 'react-dom';
const Person = ({person, setForDelete}) => (
<div>
<input type="checkbox" name="person" checked={person.checked} onChange={setForDelete.bind(this, person)} />
{person.name}
</div>
);
class PeopleList extends Component {
render() {
return(
<div>
{this.props.people.map((person, i) => {
return <Person key={i} person={person} setForDelete={this.props.setForDelete} />;
})}
<div onClick={this.props.deleteRecords}>Delete Selected Records</div>
</div>
);
}
} // end class
class App extends React.Component {
constructor(props) {
super(props)
this.state = {people:[{id:1, name:'Cesar', checked:false},{id:2, name:'Jose', checked:false},{id:3, name:'Marbel', checked:false}]}
}
deleteRecords() {
const people = this.state.people.filter(p => !p.checked);
this.setState({people});
}
setForDelete(person) {
const checked = !person.checked;
const people = this.state.people.map((p)=>{
if(p.id === person.id)
return {name:person.name, checked};
return p;
});
this.setState({people});
}
render () {
return <PeopleList people={this.state.people} deleteRecords={this.deleteRecords.bind(this)} setForDelete={this.setForDelete.bind(this)}/>;
}
}
render(<App/>, document.getElementById('app'));
奇怪的是，没有人提到mobx。这个想法类似于redux。如果我有一段数据，多个组件订阅了它，那么我可以使用该数据来驱动多个组件。
有多种方法可以使组件进行通信。有些可能适合您的用例。下面是一些我认为有用的知识。
反应
亲子直接交流
const Child = ({fromChildToParentCallback}) => (
<div onClick={() => fromChildToParentCallback(42)}>
Click me
</div>
);
class Parent extends React.Component {
receiveChildValue = (value) => {
console.log("Parent received value from child: " + value); // value is 42
};
render() {
return (
<Child fromChildToParentCallback={this.receiveChildValue}/>
)
}
}
在这里，子组件将调用父组件提供的带有值的回调，父组件将能够获得父组件中子组件提供的值。
如果你为你的应用程序构建一个功能/页面，最好有一个单一的父组件来管理回调/状态(也称为容器或智能组件)，所有的子组件都是无状态的，只向父组件报告事情。通过这种方式，您可以轻松地将父进程的状态“共享”给任何需要它的子进程。
上下文
React Context允许将状态保存在组件层次结构的根，并且能够很容易地将这种状态注入嵌套非常深的组件中，而不必麻烦地将道具传递给每个中间组件。
到目前为止，上下文还只是一个实验性的特性，但在React 16.3中有了一个新的API。
const AppContext = React.createContext(null)
class App extends React.Component {
render() {
return (
<AppContext.Provider value={{language: "en",userId: 42}}>
<div>
...
<SomeDeeplyNestedComponent/>
...
</div>
</AppContext.Provider>
)
}
};
const SomeDeeplyNestedComponent = () => (
<AppContext.Consumer>
{({language}) => <div>App language is currently {language}</div>}
</AppContext.Consumer>
);
使用者正在使用呈现道具/子函数模式
查看这篇博客文章了解更多细节。
在React 16.3之前，我建议使用React -broadcast，它提供了非常相似的API，并使用以前的上下文API。
门户网站
当你想让两个组件靠得很近，让它们用简单的函数通信时，使用门户，就像正常的父/子组件一样，但你不希望这两个组件在DOM中有父/子关系，因为它暗示了视觉/ CSS约束(如z-index，不透明度……)
在这种情况下，您可以使用“门户”。有不同的react库使用门户，通常用于模态，弹出窗口，工具提示…
考虑以下几点:
<div className="a">
a content
<Portal target="body">
<div className="b">
b content
</div>
</Portal>
</div>
在reactAppContainer中渲染时可以产生以下DOM:
<body>
<div id="reactAppContainer">
<div className="a">
a content
</div>
</div>
<div className="b">
b content
</div>
</body>
详情请点击这里
槽
在某处定义一个槽，然后从呈现树的另一个位置填充该槽。
import { Slot, Fill } from 'react-slot-fill';
const Toolbar = (props) =>
<div>
<Slot name="ToolbarContent" />
</div>
export default Toolbar;
export const FillToolbar = ({children}) =>
<Fill name="ToolbarContent">
{children}
</Fill>
这有点类似于门户，除了填充的内容将呈现在您定义的槽中，而门户通常呈现一个新的dom节点(通常是document.body的子节点)
检查react-slot-fill库
事件总线
正如React文档中所述:
对于没有父子关系的两个组件之间的通信，您可以设置自己的全局事件系统。在componentDidMount()中订阅事件，在componentWillUnmount()中取消订阅，并在收到事件时调用setState()。
可以使用许多方法来设置事件总线。您可以只创建一个侦听器数组，在事件发布时，所有侦听器都将收到该事件。或者你可以使用EventEmitter或PostalJs之类的东西
Flux
Flux基本上是一个事件总线，只是事件接收器是存储。这类似于基本的事件总线系统，只是状态是在React之外管理的
最初的Flux实现看起来像是试图以一种俗套的方式来做事件源。
对我来说，Redux是最接近事件源的Flux实现，这得益于事件源的许多优势，比如时间旅行的能力。它没有严格地链接到React，也可以与其他函数视图库一起使用。
Egghead的Redux视频教程非常好，解释了它的内部工作原理(真的很简单)。
游标
游标来自ClojureScript/Om，在React项目中广泛使用。它们允许在React之外管理状态，并允许多个组件对状态的同一部分进行读/写访问，而不需要了解任何关于组件树的信息。
有很多实现，包括ImmutableJS, react -游标和Omniscient
编辑2016:似乎人们同意游标在较小的应用程序中工作得很好，但在复杂的应用程序中却不能很好地伸缩。Om Next不再有游标(虽然最初是Om引入了这个概念)
榆树架构
Elm体系结构是一种由Elm语言使用的体系结构。即使Elm不是ReactJS，也可以在React中完成Elm架构。
Redux的作者Dan Abramov使用React实现了Elm架构。
Redux和Elm都很棒，都倾向于在前端支持事件源概念，都允许时间旅行调试、撤销/重做、重放……
Redux和Elm之间的主要区别是Elm倾向于对状态管理更加严格。在Elm中，你不能有本地组件状态或挂载/卸载钩子，所有DOM更改必须由全局状态更改触发。Elm体系结构提出了一种可伸缩的方法，允许在单个不可变对象中处理所有状态，而Redux提出了一种方法，邀请您在单个不可变对象中处理大多数状态。
虽然Elm的概念模型非常优雅，其架构允许在大型应用程序上很好地扩展，但在实践中，实现简单的任务可能会很困难，或者涉及更多的样板文件，比如在安装输入后将焦点放在输入上，或者与现有的库集成，使用强制接口(如JQuery插件)。相关的问题。
此外，Elm体系结构涉及更多的代码样板。写起来并没有那么冗长或复杂，但我认为Elm架构更适合静态类型语言。
FRP
像RxJS, BaconJS或Kefir这样的库可以用来生成FRP流来处理组件之间的通信。
你可以以Rx-React为例
我认为使用这些库与使用ELM语言提供的信号非常相似。
CycleJS框架不使用ReactJS，而是使用vdom。它与Elm架构有很多相似之处(但在现实生活中更容易使用，因为它允许vdom钩子)，它广泛使用RxJs而不是函数，如果你想在React中使用FRP，它可以是一个很好的灵感来源。Egghead视频很好地理解了它是如何工作的。
CSP
CSP(通信顺序进程)目前很流行(主要是因为Go/goroutines和core.async/ClojureScript)，但你也可以在JS-CSP的javascript中使用它们。
James Long做了一个视频，解释了它如何与React一起使用。
Sagas
saga是来自DDD / EventSourcing / CQRS世界的后端概念，也称为“过程管理器”。 它是由redux-saga项目推广的，主要是作为redux-thunk处理副作用(即API调用等)的替代品。目前大多数人认为它只服务于副作用，但实际上它更多的是关于解耦组件。
It is more of a compliment to a Flux architecture (or Redux) than a totally new communication system, because the saga emit Flux actions at the end. The idea is that if you have widget1 and widget2, and you want them to be decoupled, you can't fire action targeting widget2 from widget1. So you make widget1 only fire actions that target itself, and the saga is a "background process" that listens for widget1 actions, and may dispatch actions that target widget2. The saga is the coupling point between the 2 widgets but the widgets remain decoupled.
如果你感兴趣，看看我的答案
结论
如果您想查看使用这些不同样式的相同小应用程序的示例，请检查此存储库的分支。
我不知道从长远来看什么是最好的选择，但我真的很喜欢Flux看起来像事件源的样子。
如果您不了解事件源的概念，可以看看这个非常具有教学意义的博客:用apache Samza彻底改变数据库，这是一个必读的文章，可以理解Flux为什么很好(但这也适用于FRP)
我认为社区同意最有前途的Flux实现是Redux，由于热重新加载，它将逐步提供非常高效的开发体验。令人印象深刻的现场编码阿拉Bret维克多的发明原则视频是可能的!
我看到这个问题已经有了答案，但如果你想了解更多细节，组件之间的通信总共有3种情况:
案例1:父到子通信 案例2:子到父通信 案例3:不相关的组件(任何组件到任何组件)通信
如果您想探索组件之间通信的选项，并且感觉通信变得越来越困难，那么您可能会考虑采用一种好的设计模式:Flux。
它只是一组规则，定义了如何存储和更改应用程序范围内的状态，以及如何使用该状态来呈现组件。
Flux有很多实现，Facebook的官方实现就是其中之一。虽然它被认为包含了最多的样板代码，但它更容易理解，因为大部分内容都是显式的。
其他的一些替代品是flumox, flumox和redux。
