我正在编写我的第一个 Flutter 应用程序，并正在努力应对各种状态管理解决方案。我决定从 Provider 开始，但我正在考虑切换到 BLoC。到目前为止，我发现的大多数示例都仅限于相对简单的事情，例如显示项目列表或响应某些按钮按下。就我而言，几乎所有应用程序都专注于设置相当大的数据块。（它基本上是一大堆表单，所有表单都在大型数据结构的不同位上工作。）
目前，所有状态管理都被放在一个提供程序类中，因为其中大部分都非常密切相关。例如，它的最大部分是一个项目列表，然后是该列表的一堆子集。应用程序中的大部分数据操作都在这些子集上。
我一开始并没有真正打算这样做，但我发现自己将实际使用提供程序的代码放在非常接近顶层的位置，然后沿着树传递数据。它违背了 Provider 的初衷，但它减少了重复的代码。例如，我的应用程序中的一个屏幕有一堆卡片，它们都包含非常相似的列表。它们之间的主要区别在于它们的内容来自不同的列表。因此，为了减少重复的代码，我尽可能地概括了卡片和列表，并将必要的数据沿树向下传递。我还传递回调函数来处理诸如编辑项目或将其从列表中删除之类的事情。
这听起来是一个不错的方法吗？事实上，我在树上传递状态和回调对我来说就像一种代码味道，但正如我所提到的，它减少了重复的代码。如果我有一个提供者暴露了很多东西，那又如何呢？我觉得我应该将数据模型与提供者分开，然后拥有多个较小的提供者。如果我要走这条路，BLoC 会比 Provider 更合适吗？如果我能够分解单一提供商，是否可能会提高性能？拥有多个提供商或集团似乎会使保存更改变得复杂，但也许并非如此。你有没有发现这是一个问题？
编辑：我刚刚发现这个问题，它讨论了不同数据的重用提供程序：Flutter Provider。如何拥有同一提供者类型的多个实例？
我以前并没有真正这么想过，但这是我正在努力解决的一个重要问题。我有独立修改的不同列表。它是在多个地方使用的相同小部件（有时在同一屏幕上），并且如果我将所拥有的内容分解成更小的部分，则提供程序中的功能也将是相同的。由于 Provider 是基于类型而不是实例，因此在这种情况下它可能不起作用。