ReactJS-正确更新兄弟姐妹组件中数据的方法
我将在“高级”中提到这不是关于如何在2个兄弟姐妹组件之间进行数据更新的技术问题，而是正确的方法。
我有以下组件树结构：
App
|
-- Home
|
-- SearchBar
| |
| -- Filters
|
-- ItemsList
itemslist具有逻辑，可以加载来自API调用的项目列表并显示页面上的项目列表。它还管理文章的状态。如果删除了文章，则将其从列表中删除并更新其状态。
searchBar是一个包含文本搜索的组件，该搜索显示在列表上方，用户可以在其中输入文本进行搜索，并且还具有打开filters组件的按钮可以过滤不同的参数。一旦用户搜索或过滤itemsList组件中的列表，应相应地更新。
我可以考虑有几种方法来实现这一目标：
- 使用React上下文 - 提供商将在
Home组件上（或其他用于持有searchbar-searchbar和itemslist将包含一个消费者，该消费者将使用提供商中的方法更新状态 - 那些在我看法中更新了这一点。这些组件之间的某些依赖性和它们并没有真正站立（itemslist组件也应在其他页面中使用 - 当然，这仍然是可能的，但是并没有感到“干净” 。 - ） 具有函数为事件的属性 - 类似“ onfilterchanged”之类的东西，并将在
itemlist上调用该方法（我需要对该组件保留ref）。但是，这样的工作感觉就像每个组件都可以站立并重复使用它自己的优点 - 但要失去“反应性”和更多需要完成的电线。
还有其他方法可以实现我不考虑的东西吗？ 构建这种解决方案的正确方法是什么？
I'll mention in advanced that this is not a technical question on how to do the data update between 2 sibling components, rather what is the correct way to do so.
I have the following component tree structure:
App
|
-- Home
|
-- SearchBar
| |
| -- Filters
|
-- ItemsList
ItemsList has logic in it to load the list of items from an API call and show the list of items on the page. It also manages the state of the articles. If an article is deleted it removes it from the list and updates it's state.
SearchBar is a component that contains a textual search that is displayed above the list where a user can enter text to search and also has a button that opens the Filters component where the user can filter different parameters. Once the user search's or filters the list in the ItemsList component should be updated accordingly.
There are a few ways I can think to achieve this:
- Using react context - The provider will be on the
Homecomponent (or another component for holdingSearchBarandItemsList- and bothSearchBarandItemsListwill contain a consumer that will updated the state with a method in the provider - those updating the components. This in my opinion create some dependency between those components and they are not really standing on their own (theItemsListcomponent should be used in other pages as well - of course this is still possible, but yet does not feel so "clean"). - The
ItemsListcomponent will contain public methods such as "delete item", and "clear list" and those methods will be called from the home component. TheSearchBarwill get a property with a function as an event - something like "onFilterChanged" and will call the method onItemsList(I will need to hold a ref to that component). But working like that feels like each component can stand and be re-used on it's own merit - but loosing the "reactiveness" and more wire up that needs to be done.
Are there any other ways to achieve what I'm looking for that I'm not thinking of?
What is the correct way to architect this kind of solutions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当两个兄弟姐妹需要访问同一状态时，将状态保持在共同的父部分中是一种常见且推荐的处理方式（官方
该方法可能有缺点：取决于应用程序的大小， prop钻孔可能会使代码令人困惑且难以维护，尤其是如果使用所述数据的一个组件在多个位置使用，或两者兼有。
在这种情况下，在上下文或redux中保持状态是一种更合适的方法。您列出的第一个选项是完全合法的，我建议您建议使用。也许完全提取上下文（不要将其保存在
主页组件中，而不是在自己的文件中创建上下文）会帮助事物感觉更加“清洁”。确定何时使用哪种方法是随着时间和经验带来的。选择一种方法时，请记住您的未来计划很有帮助。如果您知道该应用程序很小而简单，则将状态保持在父组件中是一个很好的举动。如果您对应用程序有宏伟的计划，那么从一开始就使用上下文或redux将是最简单的。
值得庆幸的是，最坏的情况是，您决定从一种方法转变为另一种方法，这总是可以做到的（有时可能会造成混乱和乏味）。
When two siblings need access to the same state, keeping the state in a mutual parent component is a common and recommended way of handling it (the official React documentation encourages that approach for most cases). That way, both the state and any methods to update the state can be passed to both children as needed, and any updates made by one child will be reflected in the other child.
There can be drawbacks to that approach: Depending on the size of the application, prop drilling can make code confusing and difficult to maintain—especially if one component that is using said data is being used in multiple places, deeply nested, or both.
For such occasions, holding the state in context or redux is a more appropriate approach. The first option that you listed is completely legitimate and what I would recommend. Maybe extracting your context entirely (not keeping it in your
Homecomponent and instead creating the context in its own file) would help things feel more "clean."Determining when to use which approach is something that comes with time and experience. When choosing an approach, it is helpful to keep your future plans in mind. If you know the application will be small and simple, keeping the state in a parent component is a great move. If you have big plans for your application, using context or Redux from the start will be easiest.
Thankfully, the worst case scenario is that you decide to change from one approach to the other, which can always be done (confusing and tedious as it may be at times).