FilledStacks / FilledStacks/provider_architecture
Reusing ViewModel with ChangeNotifierProvider.value constructor
- Dominant language
- Dart
- Stars
- 86
- Forks
- 15
- PR merge metrics
- No merged PRs in 30d
Description
Hi,
first of all, thank you very much for this fantastic package, it makes my MVVM life much easier.
I am holding my data models in a List inside of my view model. I do not want to dispose the view model and recreate my data every time I navigate away and back to a certain screen, which is why I hold my view model as a lazy singleton using get_it. This works fine but throws an error when the ChangeNotifierProvider constructor is called within the ViewModelProvider built function with a reused view model.
What I am currently doing is a reimplementation of the ViewModelProvider class where I call the ChangeNotifierProvider.value constructor inside the built function, which gives me the opportunity to reuse my view model.
```
@override
Widget build(BuildContext context) {
if (widget.providerType == _ProviderType.WithoutConsumer) {
return ChangeNotifierProvider.value(
value: _model,
child: widget.builder(context, _model, null),
);
}
return ChangeNotifierProvider.value(
value: _model,
child: Consumer(
builder: widget.builder,
child: widget.staticChild,
),
);
}
```
My suggestion is to provide an additional parameter in the ViewModelProvider.withConsumer and .withoutConsumer constructor _bool reuse = false_, which will be looked for in the build function. If _reuse == true_, the alternative ChangeNotifierProvider.value constructor could be called.
Or, alternatively, what would be the disadvantage of always using the .value constructor?
Thank you very much for your feedback!
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the ViewModelProvider.withConsumer and .withoutConsumer constructors into their build function, focusing on how ChangeNotifierProvider currently manages the reused ViewModel. Compare the requested reuse parameter and ChangeNotifierProvider.value behavior with the existing lifecycle assumptions; done means the requested reuse case works without incorrectly disposing the singleton model.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- dart, flutter
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100