BOF会议在孟买ReactFoo上关于状态管理的讨论摘要。
最近，Twitter见证了有关Redux的争论激增—关于它的吸引力或表现如何。 知道开发人员自己对此要说些什么会很有趣。
- 法伦（Fraei）的Pronto-更好地致电Saul S4E04
- 热，疯狂的混乱
- [Dica filme Netflix] Kiki-Os Segredos do Desejo
- Netflix新闻：“纸牌屋”将于5月30日回归第5季！ 见预告片！
- 生存指南：从MoviePass继续
好像上帝听到了我们。 阅读以下内容以了解原因。
ReactFoo的最新版本在孟买，来自不同公司的开发人员参加了此次活动，以分享他们的想法。 USP之一是“羽毛之鸟”会议（BoF）。
羽毛鸟： 这个成语是谚语“羽毛鸟聚在一起”的缩写。这意味着同种或兴趣相同的人（鸟）喜欢共同消磨时间。
那是一个阳光灿烂的下午，这次我们选择了React中的State Management进行讨论。 State Management带有广泛的生态系统，可以满足您的所有需求。 但是，事实是： 您可能根本不需要，或者至少现在还不需要 。 因此，演讲的主要议程是更好地理解它们。
我们邀请了Tesco的Souvik Basu和Amdocs的Ankita Goyal主持了此次讨论。
他们以我们在任何Web应用程序中处理的状态类型开始了讨论。 安基塔（Akitta）阐明了这些类型，并谈到了5个州。 她通过描述数据状态，控制状态，通信状态，会话状态和位置状态这五个状态进一步讨论了它们。
1.数据状态
数据状态涵盖您的应用程序临时存储的有关广阔世界的信息。 也就是说，它涵盖了您的业务数据。 当然，数据不仅会神奇地出现在应用程序中。 我们需要请求它，然后等到请求成功或失败。 在这里，我们的通讯状态进入。
2.通讯状态
通信状态是对其他服务的任何尚未完成的请求的状态。 当我们等待HTTP请求的回调时，它可以帮助装载程序和微调程序。
3.控制状态
控制状态是特定于给定容器组件的状态，并且不存储在屏幕的URL或HTML5历史API中。
4.会话状态
会话状态包含有关当前已登录或希望在整个应用程序中使用它的用户或应用程序的信息。 会话状态仅在安装组件时读取。
5.位置状态
位置状态是存储在URL栏或HTML5历史记录API中的信息。
我们使用最常见的示例对其进行了更好的解释。 我们使用Netflix来使图片清晰。 在浏览Netflix时，如何知道您最近观看的剧集或确切的时间历史以继续播放已退出的电影或剧集。 好吧，这是会话管理的魅力。 我们还有其他网站用户与Netflix用户：
然后，讨论转向了保持这些状态的不同方法。 我们有Redux ， MobX ，Vanilla React的SetState ，带有Apollo Client的GraphQL 。 几乎90％的受众群体已将Redux用于应用程序管理。
首先从Redux开始，我们需要查询以及开发人员共享的经验。 我们讨论了Redux在市场上创造的炒作，只是因为它很好地在数据，表示和控制器之间建立了隔离。
Redux的工作方式以及商店如何更新操作也是讨论的一部分。 我们还有一个有趣的查询：如果项目中有可重用的组件，那么应该在哪里更新组件的值？ 在商店级别还是在容器级别？
很好的答案是-可以在查看业务需求后通过查看范围来确定。
在商店级别定义值可能会导致代码容易出错，并且可能还会增加商店长度。 如果没有为减速器使用选择器，则可能导致更新完整的状态树并降低效率。 而如果在容器级别对其进行管理，则更易于管理本地状态和调试。
我们讨论了Redux应用程序中的多个商店，如何处理它们，以及这是否会使应用程序复杂化或简化商店管理。 根据开发人员的经验，我们在列表中有正面和负面的场景。
因此，丹·阿布拉莫夫本人曾表示， 除非您对香草React遇到问题，否则不要使用Redux，这是在开始使用React之前要了解的重点 。 Redux也有缺点，因为自由事物总是带有警告。
Souvik已经讨论了有关Context API的问题，并且状态管理与它们明确且易于开发人员根据应用程序需求进行选择。
在演讲嘉宾讨论了Apollo和GraphQL之后，我们要求开发人员使用这些堆栈分享他们的成功故事。 好吧，Apollo的使用率比Redux或MobX小得多。 Souvik与Apollo和GraphQL一起分享了他的经验。 听众几乎没有关于缓存期以及它们与React在广泛应用程序中的兼容性的疑问。
开发人员之间的对话非常精彩，与会的每个人都非常喜欢这次会议。
请继续关注ReactFoo Delhi。
