Closed narcodico closed 2 years ago
@narcodico Will this change allow us to pass a List<Widget
as opposed to a List<Pages>
with onGeneratePages
?
@narcodico Will this change allow us to pass a
List<Widget
as opposed to aList<Pages>
withonGeneratePages
?
No. But you could potentially use ValueListenableBuilder
similar to BlocBuilder
to build different widgets, but that kinda goes against the whole concept of flow builder, since when you're creating one you'll specify the onGeneratePages
which will determine the stack of pages by using the current flow state.
This change would be beneficial when needing to build some UI based on the flow state/part of it. This change could potentially eliminate a lot of scenarios where you make the flow depend on a bloc's state simply because you need to build UI while also being able to drive a flow.
@narcodico thanks for opening an issue!
There have been some recent changes to refactor FlowController
to extend ChangeNotifier
rather than to implement Listenable
(see #61). As a result, you should be able to use an AnimatedBuilder
with the FlowController
to rebuild some UI based on the state (available in flow_builder v0.0.5).
Let me know what you think, thanks!
@felangel that will also do the job! 👍
Awesome, closing for now but let me know if you have any additional feedback/suggestions and I'm happy to reopen this 👍
Is your feature request related to a problem? Please describe. Currently
flow_builder
can't be used to build widgets. Althoughflow_builder
's responsibility is building the navigation stack, users could also benefit from being able to useValueListenableBuilder
with aFlowController
.Describe the solution you'd like
FlowController<T>
should implementValueListenable<T>
instead ofListenable
. The only downside is this would forceFlowController
to overrideValueListenable
'svalue
. Right now the value's role is played by thestate
property. Couple of options to overcome this:and leave the rest of the implementation as it is. Weird solution to say the least, but I guess it's the only way to keep the
state
naming 🙄and deprecate
state
for the next release; we could then removestate
and keepvalue
to better align with flutter naming conventions. I'd prefer this route.If you like this change I'm willing to open a PR.