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.
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:
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.