See simple state article in the resources section. The widgets that listen to the state and rebuild on a change are generally called builder widgets. We can hide futures behind a ValueNotifier, but can be done with streams as well.
If the UI needs to listen to state that’s in a ValueNotifier, then you should use a ValueListenableBuilder widget. The long name is rather unfortunate because it’s job is quite simple. Just rebuild a little section of the UI with the new value.
- getit: to access the state
- config.dart: it contains all we need in most of the application.
- base.dart: all we need for our state framework :)
- every page is a class that contains effect, reducer and state, and we
- register pages in the app.dart
- so from any component can access other pages state we also can have a global common state
- views access 'page' using getit
- state only function is 'apply' to change for a new copy of the state, that is in the 'value' variable from the
- access to database, API, etc... only in effect.
- effects, reducers and actions only contain functions, but the state is indeed a class, once it's the only part that we need to keep data in the memory. Following this pattern we go for a more functional approach.
- to change the state we have ONLY one function, 'apply', and business logic is concentrated only on reducers.
Use the graphqlbin to play. You can point to https://graphql.bitquery.io .
- graphql - dart graphql client
- config:
- boot.dart: all the initalizations needed when the application starts