provider_kit is a state management toolkit for Flutter, built to work seamlessly with the provider package. It simplifies state handling with predefined widgets, reduces boilerplate, and efficiently manages loading, error, and data states. With built-in async support, state observers, caching, and enhanced notifiers.

Before	After

• Getting started
• State
  • State Notifier
  • State Widgets
    • State Listener
    • State Builder
    • State Consumer
  • Multi State Widgets
    • Multi State Listener
    • Multi State Builder
    • Multi State Consumer
• View State
  • View State Notifier
  • Async View State Notifier
  • View State Widgets Provider
  • View State Widgets
    • View State Listener
    • View State Builder
    • View State Consumer
  • Multi View State Widgets - How Multi View State Widgets work
    • Multi View State Listener
    • Multi View State Builder
    • Multi View State Consumer
  • Cache Mixins
    • Ex View State Cache Mixin
    • Data State Copy Cache Mixin
• Nested State Listener
• Notifier Observer
• Templates
  • Vs Code Template Setup
  • Android Studio and IntelliJ Template Setup
  • Taking full advantage of templates
• Best Practices for Managing Additional State in provider kit

dependencies:
  provider_kit: ^0.2.0
  provider: ^6.1.5

Make sure to register your provider to gain full advantage of this package.

ChangeNotifierProvider(
  create: (_) => MyProvider(),
  child: ...
)

For more information and details about registering your provider, see the documentation of provider package.

Alright, now lets dive in !

State management is simplified using StateNotifier (or any object implementing StateValueListenable) and various widgets designed for listening, building, and consuming state changes efficiently.

StateNotifier acts as the core class of this library, similar to ValueNotifier but with enhanced capabilities. By extending StateNotifier, our providers become observable, allowing widgets to listen and react to state changes.

Note: All state widgets in this package are generic over any object implementing StateValueListenable. StateNotifier is the default implementation provided by ProviderKit.

class MyProvider extends StateNotifier<int> {
  CounterProvider() : super(0);

  void increment() => state++;
  void decrement() => state--;
}

To listen to state changes from our provider, we use built-in widgets that are designed to interact with the StateNotifier. Each widget includes an optional provider attribute. By default, state widgets automatically search the widget tree for the corresponding provider type (e.g., MyProvider). Alternatively, we can pass a specific provider instance using the provider attribute.

Note: These widgets are not limited to StateNotifier; any object implementing StateValueListenable can be used.

• State Widgets include StateListener, StateBuilder, StateConsumer.

A widget that listens for state changes and executes side effects without rebuilding the UI.

StateListener<MyProvider, MyDataType>(
  provider: provider, // Optional
  listenWhen: (previous, current) => previous != current, // Default, optional
  shouldCallListenerOnInit: false, // Default, optional
  listener: (context, state) {
    // Can execute side effects here
  },
  child: YourWidget(),
);

A widget in which the builder will be triggered on state change.

StateBuilder<MyProvider, MyDataType>(
  provider: provider, // Optional
  rebuildWhen: (previous, current) => previous != current, // Default, optional
  builder: (context, state, child) {
    return Text('Count: $state');
  },
  child: YourStaticWidget(), // Optional, won't be rebuilt
);

A widget that combines the features of both StateListener and StateBuilder.

StateConsumer<MyProvider, MyDataType>(
  provider: provider,
  listenWhen: (previous, current) => previous != current, // Default, optional
  shouldCallListenerOnInit: false, // Default, optional
  listener: (context, state) {
    // Can execute side effects here
  },
  rebuildWhen: (previous, current) => previous != current, // Default, optional
  builder: (context, state, child) {
    return Text('Count: $state');
  },
  child: YourStaticWidget(), // Optional, won't be rebuilt
);

💡 Tip: Passing a StateValueListenable instance directly (such as a StateNotifier)? Use NotifierBuilder, NotifierListener, or NotifierConsumer instead of StateBuilder, StateListener, or StateConsumer to avoid repeatedly typing <StateValueListenable<T>, T>.

// ✅ Clean
NotifierBuilder<int>(provider: counterProvider, builder: ...)

// ❌ Verbose
StateBuilder<StateValueListenable<int>, int>(provider: counterProvider, builder: ...)

For automatic provider lookup, use the original widgets instead.

With Multi State Widgets, we can listen to the states of multiple providers using a single widget. However, these widgets won't try to read the provider.

Note: The providers' states can be of the same type or different types (dynamic).
The providers themselves are not limited to StateNotifier; any object implementing StateValueListenable can be used.

• Multi State Widgets include MultiStateListener, MultiStateBuilder and MultiStateConsumer.

A widget that listens to the state of multiple providers, and a state change in any of the providers will trigger the listener callback.

MultiStateListener<MyDataType>(
  providers: [provider1, provider2, provider3],
  listenWhen: (previous, current) => previous != current, // Default, optional
  shouldCallListenerOnInit: false, // Default, optional
  listener: (context, states) {
    // Can execute side effects here
  },
  child: YourWidget(),
);

A widget that listens to the state of multiple providers, and a state change in any of the providers will trigger the builder.

MultiStateBuilder<MyDataType>(
  providers: [provider1, provider2, provider3],
  rebuildWhen: (previous, current) => previous != current, // Default, optional
  builder: (context, states, child) => Text(states.toString()),
  child: YourStaticWidget(), // Optional, won't be rebuilt
);

A widget that combines both the features of MultiStateListener and MultiStateBuilder.

MultiStateConsumer<MyDataType>(
  providers: [provider1, provider2, provider3],
  listenWhen: (previous, current) => previous != current, // Default, optional
  shouldCallListenerOnInit: false, // Default, optional
  listener: (context, states) {
    // Can execute side effects here
  },
  rebuildWhen: (previous, current) => previous != current, // Default, optional
  builder: (context, states, child) {
    return Text('Count: $states');
  },
  child: YourStaticWidget(), // Optional, won't be rebuilt
);

ViewState is a sealed class representing different states of a view. It supports various states such as Initial, Loading, Data, Empty, and Error. Each state has specific properties and behaviors.

A Typical use case for ViewState is when fetching data asynchronously. For example, it can be from a server or local storage. It can also be used in operation-based scenarios like authentication features.

Important Note: EmptyState will be used only for Iterable data types. For Example when your T is a List, Set etc.

ViewStateNotifier is a StateNotifier that manages ViewState<T>. It simplifies state management by handling various states such as loading, empty, data, and error for a given data type.

By default the initial state of ViewStateNotifier is LoadingState.

class MyViewStateProvider extends ViewStateNotifier<List<Item>> {
  final Repository _repo = Repository();

  MyViewStateProvider() : super(const InitialState()) {
    init();
  }

  Future<void> init() async {
    try {
      state = const LoadingState();
      final List<Item> items = await _repo.getItems(10);
      if (!mounted) return; // Guard against disposal
      if (items.isEmpty) {
        state = const EmptyState();
        return;
      }
      state = DataState(items);
    } catch (e, s) {
      state = ErrorState(e.toString(), e, s, onRefresh);
    }
  }

  void onRefresh() {
    state = const LoadingState();
    init();
  }
}

Note: Use mounted to check whether the notifier is still alive before updating state after asynchronous operations. This prevents "used after disposed" errors.

Tired of manually implementing the same logic for every provider? No worries! Introducing AsyncViewStateNotifier—a more efficient way to manage our view state.

AsyncViewStateNotifier automates state management, eliminating the need to repeatedly extend ViewStateNotifier and implement the same boilerplate logic. It streamlines fetching, handling empty states, error management, and retry mechanisms.

By default the initial state of AsyncViewStateNotifier is LoadingState.

Instead of writing the entire MyViewStateProvider which we seen above, we can simply extend AsyncViewStateNotifier like this:

class MyViewStateProvider extends AsyncViewStateNotifier<List<Item>> {

  @override
  FutureOr<List<Item>> fetchData() => Repository().getItems(10);
}

That's it! 🎉

✅ Automatically fetches data upon initialization.
✅ Transitions to LoadingState before fetching.
✅ If the data is Iterable and if its empty, it switches to EmptyState.
✅ Catches exceptions and converts them into ErrorState.
✅ Includes a built-in onRefresh function, which rebuilds the initialization logic.
✅ Passes the onRefresh function, exception, and stack trace to ErrorState.
✅ Internally guarded with mounted – For safe async state updates.

Note FlutterError exceptions are re‑thrown and not converted to ErrorState. This ensures that fatal programming errors (e.g., assertion failures) are not masked by the UI.

With AsyncViewStateNotifier, state management becomes cleaner, more efficient, and hassle-free.

Lets customize our MyViewStateProvider to the fullest.

class MyViewStateProvider extends AsyncViewStateNotifier<List<Item>> {
  // by default `initialState` is `LoadingState`.
  // by default `disableEmptyState` is false.
  MyViewStateProvider()
      : super(initialState: const InitialState(),
      //disabling empty state will set the state to `DataState` instead of `EmptyState`
       disableEmptyState: true);

  @override
  FutureOr<void> init() async {
    // `init` is internally guarded
    // Custom initialization logic goes here

    state = const LoadingState();
    List<Item> items = await fetchData();

    if (!mounted) return; // Guard against disposal

    // Additional processing, such as filtering, can be done here
    state = DataState(items);
  }

  @override
  FutureOr<List<Item>> fetchData() async {
    // Fetch data from an API or database
    return [];
  }

  ///  **Custom error state handling**
  @override
  ErrorState<List<Item>> errorStateObject(Object error, StackTrace stackTrace) {
    String message = "Something went wrong";

    // Custom error message handling
    if (error is MyException) {
      message = error.message;
    }

    return ErrorState<List<Item>>(message, error, stackTrace, refresh);
  }

  ///  **Custom loading state**
  @override
  LoadingState<List<Item>> loadingStateObject() {
    return const LoadingState<List<Item>>('Data is Loading...');
  }

  ///  **Custom empty state**
  @override
  EmptyState<List<Item>> emptyStateObject() {
    return const EmptyState<List<Item>>('No data available.');
  }

  ///  **Optional refresh override**
  @override
  Future<void> refresh() async {
    // Perform any additional refresh logic if needed
    super.refresh();
  }
}

Note: Even if refresh is not passed inside the ErrorState for retry mechanism, the refresh will be automatically be read by the View State Widgets as long as the provider extends AsyncViewStateNotifier.

In a typical application, most screens fetch data from a server or local storage. On every view screen, we compare the state and display the appropriate widget based on that state. For example:

• LoadingWidget when the state is loading
• ErrorWidget when the state is error
• EmptyWidget when the data list is empty
• DataWidget when the data is successfully fetched

Instead of checking the state type and passing the respective widgets for every single screen, we can reuse the same widgets across all screens. We can streamline this process by wrapping our MaterialApp with ViewStateWidgetsProvider and supplying custom widgets for each state.

Note: These widgets will be used internally by ViewStateBuilder,ViewStateConsumer,MultiViewStateBuilder and MultiViewStateConsumer which we’ll explore soon below.

ViewStateWidgetsProvider is simply an inherited widget that provides consistent state based widgets across our app.

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return ViewStateWidgetsProvider(
      //supply your initial state widget
      initialStateBuilder: (isSliver) {
        const widget = Center(child: Text("Initial State"));
        return isSliver ? const SliverToBoxAdapter(child: widget) : widget;
      },
      //supply your empty state widget
      emptyStateBuilder: (message, isSliver) {
        Widget widget = Center(child: Text(message ?? "No Data Available"));
        return isSliver ?  SliverToBoxAdapter(child: widget) : widget;
      },
      //supply your error state widget
      //onRetry will refresh the provider 
      errorStateBuilder: (errorMessage, onRetry, exception, stackTrace, isSliver) {
        final widget = Center(
          child: Column(
            mainAxisSize: MainAxisSize.min,
            children: [
              Text(errorMessage ?? "An error occurred",
                  style: const TextStyle(color: Colors.red)),
              TextButton(
                  onPressed: onRetry, child: const Text("Retry")),
            ],
          ),
        );
        return isSliver ? const SliverToBoxAdapter(child: widget) : widget;
      },
      //supply your loading state widget
      loadingStateBuilder: (message, progress, isSliver) {
        const widget = Center(child: CircularProgressIndicator());
        return isSliver ? const SliverToBoxAdapter(child: widget) : widget;
      },
      child: const MaterialApp(
          //..
          ),
    );
  }
}

Additionally, you can wrap any section of your widget tree with ViewStateWidgetsProvider to completely redefine its state widgets, or use ViewStateWidgetsProvider.override to update only specific state builders while inheriting the rest from the parent ViewStateWidgetsProvider.

class ProfileScreen extends StatelessWidget {
  const ProfileScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return ViewStateWidgetsProvider.override(
      context: context,
      // Overrides ONLY the loading builder for this subtree, used internally by `ViewStateWidgets`.
      loadingStateBuilder: (message, progress, isSliver) {
        const widget = Center(child: ProfileSkeletonLoader());
        return isSliver ? const SliverToBoxAdapter(child: widget) : widget;
      },
      child: const ProfileView(),
    );
  }
}

Note: In errorStateBuilder, the errorMessage, onRetry, exception, and stackTrace are automatically passed to the function if your provider is providerKit.

These widgets are similar to State Widgets but are designed to adapt based on the corresponding ViewState. They listen to a provider that extends either ViewStateNotifier or AsyncViewStateNotifier, ensuring they respond dynamically to state changes.For example MyViewStateProvider which we learned above.

• View State Widgets includes ViewStateListener, ViewStateBuilder, ViewStateConsumer.

This widget provides individual listener callbacks for each ViewState, allowing customized behavior based on the current state.

ViewStateListener<MyViewStateProvider, MyDataType(
  dataStateListener: (data) => context.showToast(data.toString()),
  child: YourWidget(),
)

Each callback is triggered based on the current ViewState, allowing dynamic response handling within ViewStateListener.

This widget provides individual builder for each ViewState, allowing customized behavior based on the current state.

Important Note: initialStateBuilder, loadingStateBuilder, emptyStateBuilder and errorStateBuilder that we supplied to ViewStateWidgetsProvider will be used by this widget internally by default.

ViewStateBuilder<MyViewStateProvider, MyDataType>(
  // Other ViewState builders will be assigned from the `ViewStateWidgetsProvider`.
  // We can override them here in `ViewStateBuilder` if needed.
  // loadingBuilder: (message, progress, isSliver) => ,
  dataBuilder: (data) => Text(data.toString()),
)

The ViewStateBuilder allows customization of UI rendering for different ViewStates, enabling dynamic UI updates based on the current state.

This widget combines features of both ViewStateListener and ViewStateBuilder. We can use this widget when we need both listeners and builders functionality.

Important Note: initialStateBuilder, loadingStateBuilder, emptyStateBuilder and errorStateBuilder that we supplied to ViewStateWidgetsProvider will be used by this widget internally by default.

ViewStateConsumer<MyViewStateProvider, MyDataType(
  dataStateListener: (data) {
    print(data);
  },
  dataBuilder: (data) => Text(data.toString()),
)

Multi View State Widgets allow us to listen to multiple providers' ViewStates with a single widget. However, these widgets do not read the provider.

Note: Our providers states can either be of the same types or dynamic.

Key Difference: Unlike ViewStateListener, ViewStateBuilder, and ViewStateConsumer, Multi View State Widgets require a list of providers as a mandatory attribute.

• Multi View State Widgets inlcudes MultiViewStateListener, MultiViewStateBuilder and MultiViewStateConsumer.

The behavior of MultiViewStateBuilder, MultiViewStateListener, and MultiViewStateConsumer depends on the collective states of the provided ViewStates. The highest-priority state in the list determines which builder or listener is triggered.

• If any provider is in ErrorState, the errorStateListener (or errorBuilder) will be invoked.

• The first encountered ErrorState data will be passed to the errorStatelistener or errorBuilder.

• If no ErrorState is found, but at least one provider is in InitialState, the initialStateListener (or initialBuilder) will be invoked.

• If no ErrorState or InitialState exists, but at least one provider is in LoadingState, the loadingStateListener (or loadingBuilder) will be invoked.

• First encountered LoadingState message will be passed to the loadingStatelistener or loadingBuilder.

• progress will be aggregated from all LoadingStates into a single combined value.

• If none of the above states are present, but at least one provider is in EmptyState, the emptyStateListener (or emptyBuilder) will be invoked.

• The first encountered EmptyState message will be passed to the emptyStatelistener or emptybuilder.

• Only If all providers are in DataState, the dataStateListener (or dataBuilder) will be invoked.

• First encountered state applies to all states except DataState.
• LoadingState progress is aggregated from all active LoadingStates into a single combined value.
• Modifying listenWhen or rebuildWhen overrides the default priority logic which will results in triggering listener or builder whenever any provider's state changes.

If some providers have data while others return empty, triggering EmptyState may not be ideal.

Solution: Avoid using EmptyState in the provider logic. Instead, handle empty cases manually inside dataBuilder.

This ensures EmptyState won’t be triggered unless all providers return an empty state.

The MultiViewStateListener allows listening to multiple ViewState providers simultaneously. It merges their states into a unified ViewState, enabling centralized state management without manually handling multiple providers.

Check How Multi View State Widgets Work for more detailed information about how which state is triggered

MultiViewStateListener<MyDataType>(
  providers: [viewStateProviderOne, viewStateProviderTwo, viewStateProviderThree],
  dataStateListener: (dataStates) {
    print(dataStates);
  },
  child: YourChild(),
);

The MultiViewStateBuilder enables building UI based on multiple ViewState providers simultaneously. It merges their states into a unified ViewState.

Important Note: initialStateBuilder, loadingStateBuilder, emptyStateBuilder and errorStateBuilder that we supplied to ViewStateWidgetsProvider will be used by this widget internally by default.

MultiViewStateBuilder<MyDataType>(
  providers: [viewStateProviderOne, viewStateProviderTwo, viewStateProviderThree],
  dataBuilder: (dataStates) {
    return YourWidget(dataStates);
  },
);

Combines the features of MultiViewStateListener and MultiViewStateBuilder in a single widget.

Important Note: initialStateBuilder, loadingStateBuilder, emptyStateBuilder and errorStateBuilder that we supplied to ViewStateWidgetsProvider will be used by this widget internally by default.

MultiViewStateConsumer<MyDataType>(
  providers: [viewStateProviderOne, viewStateProviderTwo, viewStateProviderThree],
  dataStateListener: (dataStates) {
    print(dataStates);
  },
  dataBuilder: (dataStates) {
    return YourWidget(dataStates);
  },
);

Some mixins to help with ViewState caching and data caching that will come handy.

This mixin can be used on provider with ViewState support like ViewStateNotifier or AsyncViewStateNotifier. It provides caching capabilities for different view states. It keeps track of the most recent state of each type and allows easy retrieval of cached states.

• Stores the last known state for each ViewState type.
• Allows accessing cached states via getter methods.
• Clears cached states when disposed to free up memory.

class MyViewStateProvider extends ViewStateNotifier<MyDataType> with ExViewStateCacheMixin {
  // Your implementation here
}

This mixin can be used on provider with ViewState support like ViewStateNotifier or AsyncViewStateNotifier. We can use this mixin to cache original data.

sometimes we do local filtering on data we fetched from server and when user cancel filter we need to show the original data back which is exactly when we should use this mixin.

• Stores the latest DataState<T> and data when saveDataStateCopy is called.
• Provides access to the cached DataState<T> and its data object.
• Allows clearing cached state manually using clearDataStateCopy.

class MyViewStateProvider extends AsyncViewStateNotifier<List<String>> with DataStateCopyCacheMixin {
  void updateDataState(List<String> newData) {
    final newState = DataState(newData);
    saveDataStateCopy(newState);
    state = newState;
  }

  void clearFilter(){
    state = dataStateCopy!; 
  }
}

NestedStateListener is a widget that nests multiple state listeners within a single widget. It allows you to combine different types of listeners and manage them together efficiently.

• Supports nesting multiple state listeners.
• Works seamlessly with StateListener, ViewStateListener, MultiStateListener, and MultiViewStateListener.
• Reduces boilerplate code by combining multiple listeners into a single widget.

NestedStateListener(
      listeners: [
        StateListener<MyProvider,DataType>(
          listener: (context, state) {
            // Handle state changes
          },
        ),
        MultiStateListener<DataType>(
          providers: [ProviderOne(),ProviderTwo()],
          listener: (context, states) {
            // Handle state changes
          },
        ),
        ViewStateListener<MyProvider,DataType(
          dataStateListener: (data) {
            // Handle view state changes
          },
        ),
        MultiViewStateListener<DataType>(
          providers: [ProviderOne(),ProviderTwo()],
          dataStateListener: (states) {
            // Handle state changes
          },
          
        ),
      ],
      child: MyChildWidget(),
    );

Note: Ensure that the listeners list contains at least one listener to avoid an empty nesting.

The NotifierObserver helps you monitor the lifecycle of all notifiers in your application.
It can be used for debugging, logging, analytics, or any other cross‑cutting concern – it receives callbacks whenever a notifier is created, changes state, throws an error, or is disposed.

Assign an implementation of NotifierObserver to the static observer field on NotifierBase.
This is typically done at the start of your app, before running the MaterialApp.

void main() {
  // Set the global observer
  NotifierBase.observer = MyNotifierObserver();
  runApp(const MyApp());
}

class MyNotifierObserver extends NotifierObserver {
  @override
  void onChange(NotifierBase notifier, Change change) {
    super.onChange(notifier, change);
    debugPrint(
      'notifier onChange -- \${notifier.runtimeType}, '
      '\${change.currentState.runtimeType} ---> \${change.nextState.runtimeType}',
    );
  }

  @override
  void onCreate(NotifierBase notifier) {
    super.onCreate(notifier);
    debugPrint('notifier onCreate -- \${notifier.runtimeType}');
  }

  @override
  void onError(
      NotifierBase notifier, Object error, StackTrace stackTrace) {
    debugPrint(
      'notifier onError -- \${notifier.runtimeType} '
      'Error: \$error StackTrace: \$stackTrace',
    );
    super.onError(notifier, error, stackTrace);
  }

  @override
  void onDispose(NotifierBase notifier) {
    super.onDispose(notifier);
    debugPrint('notifier onDispose -- \${notifier.runtimeType}');
  }
}

This guide provides step-by-step instructions for setting up the ProviderKit Template in VS Code and Android Studio/IntelliJ on both Mac & Windows.

1. Open VS Code.
2. Press Cmd + Shift + P (Mac) or Ctrl + Shift + P (Windows).
3. Type "Snippets: Configure Snippets" and select it.
4. Choose dart.json to open the Dart snippets file.

1. Copy the following snippet:

   {
     "AsyncViewStateNotifier Template": {
       "prefix": "pkit",
       "description": "AsyncViewStateNotifier template",
       "body": [
         "import 'dart:async';",
         "",
         "import 'package:provider_kit/provider_kit.dart';",
         "",
         "class ${1:ProviderName}Provider extends AsyncViewStateNotifier<${2:DataType}> {",
         "",
         "  @override",
         "  FutureOr<${2:DataType}> fetchData() async {",
         "    return ;",
         "  }",
         "",
         "}",
         "",
         "typedef ${1:ProviderName}ViewState = ViewState<${2:DataType}>;",
         "",
         "typedef ${1:ProviderName}InitialState = InitialState<${2:DataType}>;",
         "typedef ${1:ProviderName}LoadingState = LoadingState<${2:DataType}>;",
         "typedef ${1:ProviderName}EmptyState = EmptyState<${2:DataType}>;",
         "typedef ${1:ProviderName}DataState = DataState<${2:DataType}>;",
         "typedef ${1:ProviderName}ErrorState = ErrorState<${2:DataType}>;",
         "",
         "typedef ${1:ProviderName}ViewStateBuilder = ViewStateBuilder<${1:ProviderName}Provider, ${2:DataType}>;",
         "typedef ${1:ProviderName}ViewStateListener = ViewStateListener<${1:ProviderName}Provider, ${2:DataType}>;",
         "typedef ${1:ProviderName}ViewStateConsumer = ViewStateConsumer<${1:ProviderName}Provider, ${2:DataType}>;"
       ]
     }
   }

2. Paste it inside dart.json.

3. Save the file (Cmd + S on Mac, Ctrl + S on Windows).

1. Open any Dart file.
2. Type "pkit" and press Tab to insert the template.

• Pressing Tab should move the cursor to the next snippet placeholder (e.g., from ProviderName to DataType).

• If Tab does not move to the next placeholder, follow these troubleshooting steps:

  Troubleshooting Steps

  1. Check your settings:

     • Open VS Code Settings (Ctrl + , or Cmd + ,).
     • Search for "Tab Completion" and set it to onlySnippets.

  2. Restart VS Code after changing the setting.

  3. Disable conflicting extensions:

     • If you have Tabnine VS Code extension, try disabling it.
     • Some AI-powered extensions override Tab behavior.

1. Open IntelliJ IDEA or Android Studio.
2. Go to Settings (Ctrl + Alt + S on Windows/Linux, Cmd + , on Mac).
3. Navigate to Editor → Live Templates.

1. Click on the + (Add) button.
2. Select Template Group.
3. Name it ProviderKit.
4. Paste the below code after selecting the created group.

<template name="providerkit" value="import 'dart:async';&#10;&#10;import 'package:provider_kit/provider_kit.dart';&#10;&#10;class $NAME$Provider extends AsyncViewStateNotifier&lt;$DATA_TYPE$&gt; {&#10;&#10;  @override&#10;  FutureOr&lt;$DATA_TYPE$&gt; fetchData() async {&#10;    return ;&#10;  }&#10;}&#10;&#10;typedef $NAME$ViewState = ViewState&lt;$DATA_TYPE$&gt;;&#10;typedef $NAME$InitialState = InitialState&lt;$DATA_TYPE$&gt;;&#10;typedef $NAME$LoadingState = LoadingState&lt;$DATA_TYPE$&gt;;&#10;typedef $NAME$EmptyState = EmptyState&lt;$DATA_TYPE$&gt;;&#10;typedef $NAME$DataState = DataState&lt;$DATA_TYPE$&gt;;&#10;typedef $NAME$ErrorState = ErrorState&lt;$DATA_TYPE$&gt;;&#10;&#10;typedef $NAME$ViewStateBuilder = ViewStateBuilder&lt;$NAME$Provider, $DATA_TYPE$&gt;;&#10;typedef $NAME$ViewStateListener = ViewStateListener&lt;$NAME$Provider, $DATA_TYPE$&gt;;&#10;typedef $NAME$ViewStateConsumer = ViewStateConsumer&lt;$NAME$Provider, $DATA_TYPE$&gt;;" description="AsyncViewStateNotifier template" toReformat="false" toShortenFQNames="true">
  <variable name="NAME" expression="" defaultValue="" alwaysStopAt="true" />
  <variable name="DATA_TYPE" expression="" defaultValue="" alwaysStopAt="true" />
  <context>
    <option name="DART" value="true" />
    <option name="FLUTTER" value="true" />
  </context>
</template>

1. Open a Dart file.
2. Type pkit and press Tab or Enter.
3. The template expands, allowing you to fill in NAME and DATA_TYPE.

AsyncViewStateNotifier provides a structured way to manage view states efficiently. Below is a template that allows you to create a FeedProvider using AsyncViewStateNotifier.

import 'dart:async';
import 'package:provider_kit/provider_kit.dart';

class FeedProvider extends AsyncViewStateNotifier<List<Item>> {
  @override
  FutureOr<List<Item>> fetchData() async {
    return []; // Fetch data from an API or database
  }
}

typedef FeedViewState = ViewState<List<Item>>;

typedef FeedInitialState = InitialState<List<Item>>;
typedef FeedLoadingState = LoadingState<List<Item>>;
typedef FeedEmptyState = EmptyState<List<Item>>;
typedef FeedDataState = DataState<List<Item>>;
typedef FeedErrorState = ErrorState<List<Item>>;

typedef FeedViewStateBuilder = ViewStateBuilder<FeedProvider, List<Item>>;
typedef FeedViewStateListener = ViewStateListener<FeedProvider, List<Item>>;
typedef FeedViewStateConsumer = ViewStateConsumer<FeedProvider, List<Item>>;

Note: Above FeedProvider generated by the template can be used for any View State Widgets and Multi View State Widgets.

Using typedefs in AsyncViewStateNotifier offers several advantages:

Instead of writing long generic types, typedefs make it easier to understand what each state represents:

FeedViewState viewState;

compared to:

ViewState<List<Item>> viewState;

By adding Feed in front of state widgets, it's easier to identify which provider they belong to. Example:

FeedViewStateBuilder(
  builder: (context, state) {
    // Handle state changes
  },
)

instead of:

ViewStateBuilder<FeedProvider, List<Item>>(
  builder: (context, state) {
    // Handle state changes
  },
)

Instead of specifying the provider and data type every time, typedefs allow you to use shorter, meaningful names.

By defining typedefs, you ensure that the correct data types are used throughout the app, preventing common mistakes.

Since provider_kit is built with ChangeNotifier as its base, there are multiple ways to use the provider.

When managing state in provider_kit, you may need additional parameters like pagination, filters, or metadata alongside your primary data (e.g., List<Item>). Here are three structured approaches to handle this efficiently:

Since provider_kit extends ChangeNotifier, you can declare additional variables inside the provider and update them using notifyListeners(). These variables can be listened to via Selector in the UI.

class MyProvider extends AsyncViewStateNotifier<List<Item>> {
  PaginationData? paginationData;
  FilterData? filterData;

  void updatePagination(PaginationData newData) {
    paginationData = newData;
    notifyListeners();
  }
}

❌ Avoid this approach as it mixes multiple responsibilities within a single provider, making it harder to maintain and test.

A better approach is to store all related data inside DataState, ensuring clear separation of concerns.

DataState((
  pagination: PaginationData(),
  filter: FilterData(),
  items: List<Item>(),
));

✅ Advantages:

• Keeps all relevant data encapsulated in a single object.
• Improves maintainability and separation of concerns.
• Easier to test and manage.

A scalable approach is to keep pagination and filter logic in separate providers and link them using ProxyProvider.

class PaginationProvider extends AsyncViewStateNotifier<PaginationData> {}

class FilterProvider extends AsyncViewStateNotifier<FilterData> {}

ProxyProvider<PaginationProvider, MyProvider>(
  update: (_, pagination, myProvider) =>
      myProvider!..updatePagination(pagination.state),
)

✅ Advantages:

• Encourages modularity and reusability.
• Keeps providers focused on a single responsibility.
• Enhances performance by updating only necessary state.

Few features of this package were inspired by flutter_bloc.

Have a feature request or found a bug? Feel free to open an issue on the GitHub Issue Tracker. Your feedback helps improve ProviderKit!

ProviderKit is backed by a comprehensive automated test suite covering widgets, state management, listeners, edge cases, and other core package functionality.

Stay updated and reach out for collaborations!
Website: Ram Prasanth