[CLI]: Provide CLI support for stateful views

[ratsey]

Is your feature request related to a problem? Please describe.

A number of issues reperted here with regard to stateful widgets. Current functionality works well with stateless widgets but creating stateful seems to land us back into more manual creation techniques.

Describe the solution you would like

Provide a --stateful switch to the stacked create view command to generate boilerplate code for a stateful view.

Additional Context

If not to be supported, provide updated documentation on best practice when wishing to use the stacked framework with a stateful view. ie, where and how to create and reference a viewmodel.

[FilledStacks]

Hey, stateful widgets work the same as a normal stateless widget. Viewmodel is the same, the widget is the same. Instead of using a StackedView you can simply just use the original way of using stacked with the ViewModelBuilder. Given that everything is a widget you can always substitute one widget for another.

The ViewModelBuilder is just a widget so it can be used anywhere you can use any other widget 😄 see example below.

class StatefulStackedExample extends StatefulWidget {
  StatefulStackedExample({Key? key}) : super(key: key);

  @override
  State<StatefulStackedExample> createState() => _StatefulStackedExampleState();
}

class _StatefulStackedExampleState extends State<StatefulStackedExample> {
  @override
  Widget build(BuildContext context) {
      return ViewModelBuilder<StatefuleStackedExampleViewModel>.reactive(
      viewModelBuilder: () => StatefuleStackedExampleViewModel(),
      builder: (context, model, child) => Center(child: Text('Stateful Example'),),
    );
  }
}

As for the feature request. Its the first time its coming up to use stateful widgets with a state management setup but if it comes up more we'll spend some time adding the functionality.

[ratsey]

Exactly what I did. It's just that I've become so use to using stacked create view I'd almost forgotten how to do it!

The problem I'm trying to solve is one involving GoogleMaps. I think it's just that the way I have it coded currently, it's regenerating the map controller, redrawing the map, and moving the camera to the user location which takes some time. Perhaps I just need to revisit that to make it less obvious with the stateless implementation.

I was previously using a Flutter Stack and Visibility widgets but it doesn't seem right to have the entire app showing and hiding all the widgets that way from the same view. Plus I lose all the joys of page navigation.

I've added the AutomaticKeepAliveClientMixin on the stateful implementation but it doesn't seem to prevent the complete map update.

I agree it does seem odd to use a stateful widget with a state management setup, so I'm probably just barking up the wrong tree and need to refactor! LOVE Stacked - it really streamlines Flutter development.

[FilledStacks]

I see, haha. I'm becoming super lazy with the manual code writing too 😅 It's so much better with the cli.

And thanks for using Stacked, that's been our goal. To provide a fast-tracked way of building quality production applications.

[FilledStacks]

@ratsey what was the use case for you that required a stateful widget.

I'm busy building the Stacked roadmap and would like to figure out if there's an underlying feature we can provide that can supply a solution to your problem.

[ratsey]

@FilledStacks It's really as noted above - when using Google Maps there's a callback used that the Maps component uses when it has finished being setup. That exposes a reference to a 'map controller' and seems quite an expensive transaction in terms of time to complete. This means that when a view goes out of scope and gets unloaded, the controller has to be regenerated and so there's a period where the map isn't visible before it gets redrawn. I don't believe the controller can be cached and reused - it seems to be specific to a maps instance.

My usage is when navigating to a settings page, the previous views get unloaded, so when going back to the map, it's not a smooth user experience since the user has to wait for the map to regenerate a new controller and redraw itself from scratch.

If the state of the map view can be retained, along with the controller, my hope is that the map does not get 'unloaded' and so will immediately be available, and left in the same state it was before navigating away.

Hope that rambling makes sense.