FilledStacks / FilledStacks/provider_architecture

Reusing ViewModel with ChangeNotifierProvider.value constructor

Open
#10 3 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.