search

rrousselGit / provider

InheritedWidgets, but simple
https://pub.dev/packages/provider
MIT License
5.11k stars 512 forks source link

Introducing Provider.shared for Efficient SharedInstance Management #871

Closed dadagov125 closed 7 months ago

dadagov125 commented 7 months ago

Problem

In the current implementation of the application with navigation between screens, there is a need to use the same instance (e.g., state management or service) on different screens, such as ScreenA and ScreenB. The approach that involves creating an instance at a level above MaterialApp results in the instance remaining in memory throughout the application's lifecycle, which is not optimal given its limited use.

Passing data between screens via navigation arguments is limited and not always suitable for working with complex data structures or in the context of declarative navigation.

Solution

A proposed approach involves using a shared repository (SharedInstances) for temporarily storing and subsequently reusing instances. This repository will automatically delete unused instances, freeing up resources.

Mechanism:

  1. On ScreenA, an instance is created and registered in SharedInstances.
  2. When navigating to ScreenB and needing to use the same instance, the provider checks for the presence of the required instance in SharedInstances. If found, the instance is reused.
  3. After ScreenA and ScreenB are removed from the widget tree, the corresponding instance is deleted from SharedInstances.

Advantages

changeset-bot[bot] commented 7 months ago

⚠️ No Changeset found

Latest commit: 203a7f1ef4101f3e39879423dbc811b2a1d0d655

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

rrousselGit commented 7 months ago

Hello!

I appreciate your eagerness to contribute, but this is skipping steps. Before making a PR, it is critical to first open an issue to discuss the proposed changes.

As it is, it is too early for me to review a PR, because I'm not sure I agree with the proposed API quite yet.

Do you mind opening an issue first, so we can move discussion there? I'll close this in the meantime, and we could reopen it later once this is sorted.

dadagov125 commented 7 months ago

Ok! I'll bring this up for discussion!