Exploring Alternatives to setState in Flutter: InheritedWidget, Provider, Bloc, Redux, and Riverpod

6.2.4 Alternatives to setState

State management is a crucial aspect of Flutter development, ensuring that your app’s UI reflects the current state of its data. While setState is a straightforward method for managing state in Flutter, it may not be the best choice for all scenarios, especially as your app grows in complexity. In this section, we’ll explore several alternatives to setState, each offering unique advantages for different use cases. We’ll cover InheritedWidget, Provider, the Bloc pattern, Redux, and Riverpod, providing insights into when and how to use each.

InheritedWidget and InheritedModel

Understanding InheritedWidget

InheritedWidget is a powerful feature in Flutter that allows data to be efficiently passed down the widget tree. It serves as the foundation for many state management libraries, enabling widgets to access shared data without needing to pass it explicitly through constructors.

• How It Works: InheritedWidget provides a way to propagate data down the widget tree. When a widget depends on an InheritedWidget, it can access the data provided by the InheritedWidget and rebuild itself when the data changes.

• Use Case: InheritedWidget is ideal for scenarios where you need to share data across multiple widgets without tightly coupling them. It’s particularly useful for global settings or themes.

• Example:

  class MyInheritedWidget extends InheritedWidget {
    final int data;
  
    MyInheritedWidget({Key? key, required this.data, required Widget child})
        : super(key: key, child: child);
  
    @override
    bool updateShouldNotify(MyInheritedWidget oldWidget) {
      return oldWidget.data != data;
    }
  
    static MyInheritedWidget? of(BuildContext context) {
      return context.dependOnInheritedWidgetOfExactType<MyInheritedWidget>();
    }
  }
  

InheritedModel

InheritedModel extends the capabilities of InheritedWidget by allowing widgets to depend on specific aspects of the data, reducing unnecessary rebuilds.

• Use Case: Use InheritedModel when you need more granular control over which parts of the widget tree should rebuild in response to data changes.

• Example:

  class MyInheritedModel extends InheritedModel<String> {
    final int data;
  
    MyInheritedModel({Key? key, required this.data, required Widget child})
        : super(key: key, child: child);
  
    @override
    bool updateShouldNotify(MyInheritedModel oldWidget) {
      return oldWidget.data != data;
    }
  
    @override
    bool updateShouldNotifyDependent(
        MyInheritedModel oldWidget, Set<String> dependencies) {
      return dependencies.contains('data') && oldWidget.data != data;
    }
  
    static MyInheritedModel? of(BuildContext context, String aspect) {
      return InheritedModel.inheritFrom<MyInheritedModel>(context, aspect: aspect);
    }
  }
  

Using Provider

Provider is a popular state management solution in Flutter that simplifies the use of InheritedWidget. It offers a more intuitive API and is widely recommended for its ease of use and flexibility.

• How It Works: Provider uses InheritedWidget under the hood to propagate data down the widget tree. It provides a simple way to manage state and dependencies, making it easier to build reactive applications.

• Use Case: Provider is suitable for most applications, especially those that require a straightforward approach to state management.

• Example:

  class MyModel with ChangeNotifier {
    int _counter = 0;
  
    int get counter => _counter;
  
    void increment() {
      _counter++;
      notifyListeners();
    }
  }
  
  void main() {
    runApp(
      ChangeNotifierProvider(
        create: (context) => MyModel(),
        child: MyApp(),
      ),
    );
  }
  

Bloc Pattern

The Bloc pattern is a design pattern that separates business logic from UI, making it easier to manage complex state and logic.

• How It Works: Bloc stands for Business Logic Component. It uses streams to manage state, allowing you to handle asynchronous data flows and complex state transitions.

• Use Case: Bloc is ideal for applications with complex business logic or those that require a high degree of separation between UI and logic.

• Example:

  class CounterBloc {
    final _counterController = StreamController<int>();
  
    Stream<int> get counterStream => _counterController.stream;
    int _counter = 0;
  
    void increment() {
      _counter++;
      _counterController.sink.add(_counter);
    }
  
    void dispose() {
      _counterController.close();
    }
  }
  

Redux

Redux is a predictable state container for Dart and Flutter applications, offering a unidirectional data flow.

• How It Works: Redux uses a single store to hold the entire state of your application. Actions are dispatched to modify the state, and reducers specify how the state changes in response to actions.

• Use Case: Redux is suitable for large applications where predictability and traceability of state changes are critical.

• Example:

  final store = Store<int>(counterReducer, initialState: 0);
  
  int counterReducer(int state, dynamic action) {
    if (action == 'INCREMENT') {
      return state + 1;
    }
    return state;
  }
  

Riverpod

Riverpod is an advanced, safe, and flexible state management solution for Flutter, offering improvements over Provider.

• How It Works: Riverpod provides a more robust API with better support for testing and error handling. It eliminates some of the limitations of Provider, such as context dependencies.

• Use Case: Riverpod is ideal for developers looking for a modern, flexible state management solution with advanced features.

• Example:

  final counterProvider = StateProvider<int>((ref) => 0);
  
  class CounterApp extends ConsumerWidget {
    @override
    Widget build(BuildContext context, ScopedReader watch) {
      final counter = watch(counterProvider).state;
      return Text('$counter');
    }
  }
  

Comparison of Alternatives

Each state management solution has its strengths and is suited for different scenarios:

• InheritedWidget/InheritedModel: Best for simple data sharing across the widget tree.
• Provider: Recommended for most applications due to its simplicity and flexibility.
• Bloc: Suitable for complex applications with intricate business logic.
• Redux: Ideal for large applications requiring predictable state management.
• Riverpod: Offers advanced features and flexibility, suitable for modern Flutter applications.

Transitioning from setState()

Transitioning from setState to a more robust state management solution can be done incrementally:

• Start Small: Begin by refactoring a small part of your app to use an alternative solution, such as Provider.
• Test Thoroughly: Ensure that your new state management approach works as expected by writing tests and validating functionality.
• Iterate: Gradually refactor other parts of your app, testing each change to ensure stability.

Exercises

To solidify your understanding, try refactoring a simple app that uses setState() to use Provider instead. This exercise will help you grasp the practical aspects of using a state management solution in Flutter.

Quiz Time!