Some objects may have inter-dependencies. There are many advanced use cases where we need to make multiple objects accessible to our widgets.
#Flutter provider global state how to
In this article we have learned about scoped access as an alternative to global access.Īnd we have seen how to use Provider as a dependency injection system for Flutter.īy the way, this was just a basic introduction. So every time you need to propagate data down the widget tree, Provider should light-up in your brain. Well, Provider makes objects accessible to an entire widget sub-tree. Remember when I said that constructor injection is impractical with deeply nested widget trees? You can think of context as the position of a widget in the widget tree. Note about BuildContext: We can retrieve the FirebaseAuth object because we pass a BuildContext variable to Provider.of(context). And we can use our example code to illustrate this:Ĭlass SignInPage extends StatelessWidget There is one main problem with global access. So in this article we will explore a better alternative to global access.Īnd I will show how to write an API wrapper for FirebaseAuth in a follow-up article. we can’t easily swap FirebaseAuth with a different authentication service if we want to.Īnd we need to address these issues if we want to write clean, testable code.we cannot write a test to verify that signInAnonymously() is called when the sign-in button is pressed.However, global access via singletons leads to code that is not testable.Īnd in this case, our widgets become tightly coupled to FirebaseAuth. Many 3rd party libraries expose their APIs via singletons, so it is not uncommon to see them used like this. signInAnonymously () // HomePage await FirebaseAuth.
0 kommentar(er)
