ethanblake4 / flutter_eval

Code push for Flutter, powered by dart_eval

Home Page:https://pub.dev/packages/flutter_eval

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Request: Support of InheritedWidget

bgoncharuck opened this issue · comments

I want to start by expressing my gratitude to the author for excellent work in enabling code push functionality.
The plugin has proven to be incredibly valuable for our Flutter projects, making the app update process smoother and more efficient on design part.

While the eval plugin currently supports the use of BuildContext, I would like to kindly request the addition of support for InheritedWidget.
ChangeNotifier is a widely used mechanism for managing state in Flutter applications. By enabling InheritedWidget support, we can ensure that the ChangeNotifier implemented within the eval plugin can seamlessly communicate state changes to the entire widget tree, simplifying complex state management scenarios.
InheritedWidget is also invaluable for maintaining global configurations or settings within an app. With this support, developers can use eval to dynamically update and distribute these configurations throughout the app.

Looking for any updates or solutions regarded InheritedWidget use through eval.
This will be a significant enhancement that would make the plugin even more versatile and beneficial to the Flutter community.

commented

Hi and thanks for the kind words :)

InheritedWidget is a particularly difficult case since Dart has no mechanism for dynamically specifying type parameters. dependOnInheritedWidgetOfExactType requires specifying the type parameter T and there is no way dart_eval can do that dyamically, outside of having a giant piece of code with every single possible Widget type mapped to that function. As you can imagine, generating that for every single function that takes type parameters is unrealistic. Doing it for that one function only is more doable, but still a far-future project.

Since support for state management packages like Riverpod is much easier, that'll likely happen first.

But is it possible to make bridge to exact one component? If we don't want to build a universal solution, but some strongly typed solution for exact one native plugin?

commented

@nosovk Of course yes, there is no restrictions on what you can do with bridging.

@bgoncharuck could we make bridge to webview only? Not a universal solution, but exactly one that required?