Flutter Provider 与 GetX 的状态管理

Question

我即将开始新的 Flutter 项目，但无法在Provider和GetX之间做出决定。还有其他选择，但我的队友相信我在完成 Flutter 课程时使用GetX，他使用Provider包进行状态管理。

所以我对这两个库的方法都有粗略的想法，但我真正关心的是何时使用哪个库。另外我没有找到真正有建设性的讨论，尽管有一些关于 GetX 臃肿和作者粗鲁的批评:(

因此，需要技术和诚实的观点。

谢谢

Answer 1

在编写了一些 Flutter 应用程序后，我分心了其他工作。现在我回来了，再次尝试决定状态管理解决方案，通过当前批次的 YouTube 视频和 Medium 文章工作。

我最大的问题一直是访问在更大的应用程序中保持和维护状态的服务。一个很好的例子是访问“Firebase 身份验证”服务，该服务保存来自小部件树之外的许多 ViewModel/Controllers/etc 的当前用户的详细信息。

Provider - 有很多带有简单示例的视频，但是没有使用 Provider 从 ViewModels/Controllers/etc 访问服务的清晰/简单的方法，我被推向了 BLoC

BLoC - 我反对代码生成和样板，这不是 BLoC，是我 ;-)

Cubit - 看起来更适合我的风格，但在它被吸收回 BLoC 后，我不确定它是否受欢迎/使用，这对我的决定有影响

RiverPod - 我试图在 ChangeNotifier 上使用 RiverPod 和 StateNotifier，但它仍然不直观，而且我在尝试不可变状态时可能会创建更多的错误。要访问保持状态的服务，我可以绕过 Readers，我确信还有其他一些技术，但在我看来，它们有点迟钝，我担心我是否正在创建一个好的应用程序架构，或者只是试图符合当前的教条

GetX - 一年前编写了几个应用程序后，我选择了 GetX。这是解决我遇到的“状态”问题的清晰/简洁的方法。我仍在努力推进 RiverPod，但我越是挣扎，我就越想放弃它并跳回 GetX。此外，它还为我提供了清晰的导航和其他好东西。我还从 Ben Butterworth 重新生成了图表，GetX 仍在加速并即将超过 Provider，这是社区接受的好兆头

我会写的最长的回复......

Answer 2

正如有人对我说的关于 Riverpod（提供者改进）与 GetX：

在一天结束时，使用任何可以完成工作的东西。我认为我们不应该理想化（或狂热）这些框架中的任何一个。人们的接线也不同。一个人可能对 GetX 感觉更舒服，另一个人可能对 Riverpod 感觉更舒服（对每个人来说）。

我是从 Provider 开始的，现在用的是 GetX，为什么？因为 GetX 更简单，就这样。

Answer 3

我查看了 GitHub 上流行的状态管理解决方案的星星（有些不仅仅是状态管理）：

我的意见：信息getX（RED线）是新的增长比供应商更快。在几个月内，它将成为领导者，并最终成为明显/安全的选择。这也是我对 Flutter 与 React Native 的看法（让我们不要深入讨论）。因此，我将在本周末开始的新项目中使用 GetX。显然 GetX 的创建者夸大了 GetX 的性能，尽管我认为这不应该阻止人们使用它，除非他们使用它纯粹是因为维护者说得很快。

• Pub.dev喜欢：GetX 有 3643 个喜欢，比 Provider 的 3670 个喜欢略少（少 27 个）。
• GetX 还没有被认为是 Flutter 的最爱，但 Provider 是。
• Github star：GetX 有 2.8k，Provider 有 3.4k，但 GetX 有更好的轨迹。

此外，Navigator 2.0 还没有得到很好的接受，这给您使用大多数这些状态管理解决方案的基本方式增加了混乱。不过，GetX 具有导航功能，因此您不必担心 Navigation 1.0 与 2.0 的混淆。TLDR：它在混乱的世界中提供了简单性。

你可以从这里生成一个图表，它是Tim Qian的网站。

Answer 4

好！关于这类问题已经有很多答案和意见。最明显的答案是……没有正确的答案。而且不应该有。除了完成工作之外，还有多种因素。没有完成任何工作的正确方法。但是您应该始终选择与您或您的队友的理念相匹配的方式（好吧！没有什么能真正 100% 匹配）您的理念。

我曾经与 Provider 和 Bloc 一起工作，但现在 GetX 变得很明显，目前，它是 Flutter 开发多个方面的首选解决方案。

我只能分享我切换背后的推理。也就是说：GetX 是 Fl​​utter 中的一个生态系统/微框架。它并不臃肿，而是它的本意：有点完整的解决方案。我发现只用一个包就可以在一定程度上满足项目要求。使用 Provider 或 Bloc 时这是不可能的。我偶尔会遇到依赖性问题。现在迁移到零安全性是一个更大的问题。我不仅获得了状态管理解决方案，而且还获得了依赖管理、实用服务、更简单和健壮的导航、响应式设计以及单个包中的关注点分离！

大多数批评 GetX 是因为它没有以所谓的“ Flutter 方式”做事。如果 GetX 让我的生活更轻松，我就不能对这种“颤振方式”更加粗心。

由于我不认识作者/维护者，也不与他本人互动，那么我为什么要关心他是否粗鲁？

GetX 是一个开源项目，并且拥有不断壮大的社区。

Answer 5

我试过他们两个加上RiverPod 这是我所知道的：

Provider 适用于小型应用程序，但对于大型应用程序来说，这是一个很大的问题，除非您想使用它get_it并编写大量样板文件

最好使用RiverPod（重写provider） 或GetX而不是 ，provider因为两者都可以以一种良好而简单的方式将业务逻辑与 ui 分开。

因此，如果您想知道在两者之间进行选择GetX或RiverPod尝试两者并看看您对什么感到满意。 GetX比状态管理更容易，RiverPod并且拥有超越状态管理的东西，比如导航、小吃店等等。另一方面，RiverPod使用InheritedWidget并拥有更多选项（提供程序），例如ProviderScope它可以让您在小部件树中制作任何小部件const（这是我最喜欢的），因此您可以说它GetX具有更多的东西（状态管理除外）并且RiverPod具有更多的东西（在状态管理中）。

我无法对这两者进行全面比较，但它们都很好（imo 的最佳可用选项），两者都有优点和缺点，因此在决定选择什么或跳转到代码编辑器之前，您需要阅读一些有关它们的信息和试试看。