Support for StatefulWidgets

[alfalcon90]

I'm looking into migrating one of my flutter projects to rearch but noticed there's no StatefulRearchConsumer widget in the library to replace the current StatefulHookWidget that I'm using from flutter_hooks.

Thanks for all the hard work, I'm excited to keep exploring the package.

[GregoryConrad]

Hi, and thanks for the interest!👋

That was an intentional design decision; the reason it wasn’t included was so that it’d encourage the use of side effects for handling state, especially for new users. While it can be handy for a quicker migration, I’d instead recommend porting a widget in its entirety over all at once.

[alfalcon90]

It's not so much about using side-effects vs not and more about the intricacies of some flutter widgets and their need to use StatefulWidgets. We've seen instances of certain widgets misbehaving or throwing errors when using HookWidget from flutter_hooks that then go away with StatefulHookWidget.

Then there's aesthetic reasons like being able to use WidgetHandle or WidgetRef from riverpod in other methods outside of build(). And lastly, whether or not it makes a huge performance difference, being able to use const with widgets that have final fields in the _MyWidgetState class.

These are just some of reasons we use StatefulWidgets but I guess we could wait and see if others in the community have a similar need. Unfortunately, this kinda blocks us from using rearch.

[GregoryConrad]

more about the intricacies of some flutter widgets and their need to use StatefulWidgets. We've seen instances of certain widgets misbehaving or throwing errors when using HookWidget from flutter_hooks that then go away with StatefulHookWidget.

can you please provide a use case? Everything you can do via StatefulWidgets should be possible via the build method alone in ReArch. If you give me an example of something you previously were doing via StatefulWidget it’s likely I can come up with a more elegant solution with side effects. I will say that not every lifecycle method of StatefulWidgets is currently exposed in the WidgetSideEffectApi, so if you need one that isn’t currently added please let me know so I can add it.

Then there's aesthetic reasons like being able to use WidgetHandle or WidgetRef from riverpod in other methods outside of build().

I’d definitely recommend against something like that in ReArch. You may use(xyzCapsule) outside build, but even that I wouldn’t recommend. Definitely don’t register side effects outside of build. ReArch was designed to be entirely functional + reactive, and as such there’s no need to manually write methods other than build (which itself is just a flutter-ism that ReArch will provide a macro for in the future so that all app code is comprised of pure functions and nothing else).

And lastly, whether or not it makes a huge performance difference, being able to use const with widgets that have final fields in the _MyWidgetState class.

All RearchConsumers should have const constructors. If you have a non-final field in a RearchConsumer, you are doing something wrong that should be handled via side effects instead.

Unfortunately, this kinda blocks us from using rearch.

Again, could you please provide an example of something you think you need StatefulWidget for? It’s likely there’s a better way to do it in ReArch via side effects. ReArch is a substantially different way of thinking than OOP/imperative/etc. that many are used to so it may have a a bit of a learning curve.

[GregoryConrad]

Also, just wanted to let you know that I haven’t forgotten about #69 ; waiting until I can get back to my laptop so I can fully address that (currently on vacation and out and about).