Closed scopendo closed 3 years ago
By definition, HookWidgets are not stateless. So that would be more confusing
The fact that they look similar doesn't mean that they are the same
I guess it depends on how one views "stateless" – clearly, a HookWidget is technically a StatelessWidget but I see your point that from an application point of view a hook widget (indirectly) maintains state. Makes StatefulHookWidget a bit more confusing for newcomers but I suppose that StatefulHookWidget use is relatively infrequent .
I'm using them a fair bit at the moment as I migrate a codebase from Provider to Riverpod+Hooks and will likely in time refactor to avoid them altogether through the use of additional hooks.
The fact that HookWidget extends StatelessWidget is more of an implementation detail. That wasn't the case before, and StatefulHookWidget wasn't a thing previously either.
Yeah, that's fair enough. Will close.
Describe the solution you'd like
We have
HookWidget
andStatefulHookWidget
. Given that they are Flutter Hooks equivalents forStatelessWidget
andStatefulWidget
I feel that it would be clearer ifHookWidget
were renamed toStatelessHookWidget
.Describe alternatives you've considered
Of course, we could add an abstract subclass of
HookWidget
calledStatelessHookWidget
but that would lead to confusion as which to use.Additional context
There is already a perceived high learning curve for those coming to Riverpod, where hook widgets become even more useful. It may be a small thing but I think it helps those new to be clear that a
HookWidget
is indeed stateless.P.S. I'm expecting this to be rejected but no harm in asking :)