Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change Design about how user can register his own Cache Drivers #63

Open
kareemradwan opened this issue May 3, 2023 · 0 comments
Open

Comments

@kareemradwan
Copy link

kareemradwan commented May 3, 2023

PART OF GTC OPEN SOURCE INTIATIVE

Hi @salahamassi,

thank you and your team for a great work, I have a comment maybe help you on your framework.

I have a suggestion for improving the registration process for custom cache drivers in flutter-bond. Currently, the documentation suggests editing the CacheServiceProvider file and registering the custom class using GetIt. However, I think this approach has some drawbacks.

Problem

Passing the GetIt object to the developer can potentially cause security and stability issues. The developer can unregister and override dependencies, which can lead to unexpected behavior.

Proposed Solution

I propose that the registration function should return a Future of List cache drivers instead of taking the GetIt object as a parameter. This way, the framework can handle the registration process and ensure that the custom driver is registered correctly.

Here's an example of how the registration function can be implemented:

Future<List<CacheDriver>> register() async {
  var store = CacheConfig.defaultStore;
  var defaultStoreDriver = CacheConfig.stores[store]?['driver'];

  List<CacheDriver> customDrivers = [];
  
  CacheConfig.stores.forEach((key, value) {
    if (value['driver'] == defaultStoreDriver) {
      customDrivers.add(SharedPreferencesCacheDriver(GetIt.instance));
    } else {
      if (value['driver'] == 'in_memory') {
        customDrivers.add(InMemoryCacheDriver(GetIt.instance));
      }
    }
  });

  return Future.value(customDrivers);
}

Trade-offs

This approach may limit the flexibility of the framework and prevent advanced users from customizing the behavior of the cache driver. However, I believe that the benefits of improved security and stability outweigh the drawbacks.

Please let me know if you have any feedback or suggestions.
Thank you for your attention.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant