Flutter Sign-In Page: Using Bloc with StatefulWidget vs StatelessWidget

In a Flutter application, the choice between using a StatefulWidget and a StatelessWidget often depends on how you manage the state and the specific requirements of your user interface. When using the Bloc pattern for state management, you might wonder why a StatefulWidget is still necessary if Bloc is handling the state. Here’s an explanation:

When to Use StatefulWidget

1. Initial Setup and Configuration:
   • StatefulWidget can be useful for initializing and configuring certain properties that aren’t directly tied to your Bloc’s state.
   • Example: Initializing a controller or setting up listeners that aren’t directly managed by Bloc.
2. Widget Lifecycle:
   • Some widget lifecycle methods like initState, dispose, and didChangeDependencies are only available in a StatefulWidget.
   • Example: If you need to perform an action when the widget is first created or before it is destroyed, you need a StatefulWidget.
3. Local State Management:
   • For managing temporary, ephemeral state that doesn’t need to be shared across the app, a StatefulWidget can be more convenient.
   • Example: Managing the state of an animation controller or a text field focus node.

Using Bloc with StatelessWidget

When using the Bloc pattern, most of the state management logic can be handled by Bloc itself, and you can often use StatelessWidget in combination with BlocBuilder or BlocListener.

Example Scenario: Sign-In Page

Let’s consider a sign-in page where you might be tempted to use StatefulWidget. Here’s how you might structure it:

Using StatelessWidget with Bloc

class SignInPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Sign In')),
      body: Padding(
        padding: const EdgeInsets.all(16.0),
        child: Column(
          children: [
            BlocBuilder<SignInBloc, SignInState>(
              builder: (context, state) {
                return TextField(
                  onChanged: (value) {
                    context.read<SignInBloc>().add(SignInUsernameChanged(value));
                  },
                  decoration: InputDecoration(labelText: 'Username'),
                );
              },
            ),
            BlocBuilder<SignInBloc, SignInState>(
              builder: (context, state) {
                return TextField(
                  onChanged: (value) {
                    context.read<SignInBloc>().add(SignInPasswordChanged(value));
                  },
                  obscureText: true,
                  decoration: InputDecoration(labelText: 'Password'),
                );
              },
            ),
            BlocBuilder<SignInBloc, SignInState>(
              builder: (context, state) {
                if (state is SignInLoading) {
                  return CircularProgressIndicator();
                } else if (state is SignInError) {
                  return Text(state.message, style: TextStyle(color: Colors.red));
                } else {
                  return ElevatedButton(
                    onPressed: () {
                      context.read<SignInBloc>().add(SignInSubmitted());
                    },
                    child: Text('Sign In'),
                  );
                }
              },
            ),
          ],
        ),
      ),
    );
  }
}

Key Points:

• StatelessWidget: The entire SignInPage is a StatelessWidget since the state management is offloaded to the Bloc.
• BlocBuilder: Used to rebuild parts of the UI based on the Bloc’s state.
• context.read: Used to dispatch events to the Bloc.

When to Use StatefulWidget in This Context:

1. Non-Bloc State Management: If you need to manage state that is not part of your Bloc, like a TextEditingController for the text fields or focus nodes.
2. Lifecycle Management: If you need to perform actions when the widget is created or destroyed (e.g., creating a TextEditingController in initState and disposing it in dispose).

Example with StatefulWidget for Controllers:

class SignInPage extends StatefulWidget {
  @override
  _SignInPageState createState() => _SignInPageState();
}

class _SignInPageState extends State<SignInPage> {
  final _usernameController = TextEditingController();
  final _passwordController = TextEditingController();

  @override
  void dispose() {
    _usernameController.dispose();
    _passwordController.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Sign In')),
      body: Padding(
        padding: const EdgeInsets.all(16.0),
        child: Column(
          children: [
            TextField(
              controller: _usernameController,
              onChanged: (value) {
                context.read<SignInBloc>().add(SignInUsernameChanged(value));
              },
              decoration: InputDecoration(labelText: 'Username'),
            ),
            TextField(
              controller: _passwordController,
              onChanged: (value) {
                context.read<SignInBloc>().add(SignInPasswordChanged(value));
              },
              obscureText: true,
              decoration: InputDecoration(labelText: 'Password'),
            ),
            BlocBuilder<SignInBloc, SignInState>(
              builder: (context, state) {
                if (state is SignInLoading) {
                  return CircularProgressIndicator();
                } else if (state is SignInError) {
                  return Text(state.message, style: TextStyle(color: Colors.red));
                } else {
                  return ElevatedButton(
                    onPressed: () {
                      context.read<SignInBloc>().add(SignInSubmitted());
                    },
                    child: Text('Sign In'),
                  );
                }
              },
            ),
          ],
        ),
      ),
    );
  }
}

Conclusion:

While using Bloc for state management often allows you to use StatelessWidget, there are cases where StatefulWidget is still necessary or more convenient, especially for managing widget-specific states and lifecycle events.