Should flutter root widget always be StatelessWidget?

Question

When I read the doc in flutter, I have a question that should flutter root widget always be StatelessWidget?

 class MyApp extends StatelessWidget {
   @override
   Widget build(BuildContext context) {
     return MaterialApp(
       title: 'Flutter Code Sample for Navigator',
       // MaterialApp contains our top-level Navigator
       initialRoute: '/',
       routes: {
         '/': (BuildContext context) => HomePage(),
         '/signup': (BuildContext context) => SignUpPage(),
       },
     );
   }
 }

1. Because I think there's sometime need init function to call, and maybe not want the code of that write in HomePage. For example: check token expire or not, and decide go to HomePage or LoginPage.
2. Then the best option: should I change the root Widget to StatefulWidget, and just include the logic above in its initState function ?

Solution 1

Making root widget a StatefulWidget is useful when listen AppLifecycleState
such as do resume job like resume WebSocket connection

code snippet

class MyApp extends StatefulWidget {
  @override
  _MyAppState createState() => _MyAppState();
}
class _MyAppState extends State<MyApp> with WidgetsBindingObserver {
  AppLifecycleState _lastLifecycleState;
  @override
  void initState() {
    super.initState();
    initPlatformState();
    WidgetsBinding.instance.addObserver(this);
  }
  initPlatformState() async {
    Screen.keepOn(true);   
  }
  Future<void> resumeCallBack() {
    if (sl<WebSocketService>().webSocketState == 'lost') {
      sl<WebSocketService>().initWebSocket();
    }
    if (mounted) {
      setState(() {});
    }
    print("resumeCallBack");
  }
  Future<void> suspendingCallBack() {
    if (mounted) {
      setState(() {});
    }
    print("suspendingCallBack");
  }
  @override
  void didChangeAppLifecycleState(AppLifecycleState state) async {
    super.didChangeAppLifecycleState(state);
    print("AppLifecycleState Current state = $state");
    setState(() {
      _lastLifecycleState = state;
    });
    switch (state) {
      case AppLifecycleState.inactive:
      case AppLifecycleState.paused:
      case AppLifecycleState.detached:
      /*case AppLifecycleState.suspending:
        await suspendingCallBack();
        break;*/
      case AppLifecycleState.resumed:
        await resumeCallBack();
        break;
    }
  }
  @override
  Widget build(BuildContext context) {
    return new MaterialApp(
      title: 'Template',
      debugShowCheckedModeBanner: false,
      theme: new ThemeData(
        primarySwatch: Colors.blue,
      ),
      initialRoute: '/',
      routes: {
        '/': (context) => LoginPage(),

Solution 2

Yes, you can use StatefulWidget as your root parent. But, you should only use it when it makes sense.

Like, If you are initialising and observing some animations, firebase messaging, services, applifecycle states etc. which might require sometimes.

Otherwise Stateless widget are better to use.

Solution 3

It can be StatefulWidget or StatelessWidget. But placing a StatefulWidget in the root will impact your app performance because a simple state change in the StatefulWidget will cause the entire widget tree to rebuild and reduce your app performance.

always try to place StatefulWidget or InheritedWidget deep inside the widget tree.

better solution for your scenario is to use Providers or InheritedWidgets and listen to the token changes rather than changing the root widget to Stateful

Comments

[Salma]

Short answer is no

[MJ Montes]

No. It doesn't have to be Stateless. Unless you're mutating the state during lifecycle events on the root Widget

[JerryZhou]

@MJ Montes what if only need to execute some task, but not change any state it self ?

[MJ Montes]

yes. You can do the usual tasks in Stateless Widget