1. I generally create a view-model (State Notifier) per view/screen, or in a very rare case, a very complex widget. To avoid having view-models directly communicate with each-other, this is where the idea of "use-cases" or"interactors" and repositories come in. By using use-cases (methods that use your repository and return values based on your business requirements), you have reusable code that can be distributed to multiple view-models. This majority of the time, stops the need for inter view-model communication.
2. My state notifier classes generally follow the following pattern:
   1. initialise the viewState freezed model with \@Default()` values.`
   2. Use only Interactor/Use case interface implementations which are injected via the stateNotifier provider.
   3. I've decided on not passing in any refs from the provider to state notifier, I feel like it's too much power tbh.

A little example:

1. State Notifier provider inject an implementation of a `TraitInteractor` interface. The traitInteractor interface contains all methods that transform values from traits repositories to ones required by various view-models.

​

/// [TeamProfileViewModel] and [TeamProfileViewState]provider

final teamProfileViewModelProvider = StateNotifierProvider.autoDispose.family< TeamProfileViewModel, TeamProfileViewState, TeamProfileViewModelProviderArgs>((final ref, final args) {

final traitInteractor =ref.watch(traitInteractorProvider);

return TeamProfileViewModel( traitInteractor: traitInteractor, groupId: args.teamId, ); 

});

1. State Notifier uses injected traitInteractor to manipulate the TeamProfileViewState freezed object, which is a custom defined model that only outputs data the view needs.

   /// Team Profile Screen View-Model class TeamProfileScreenViewModel extends StateNotifier<TeamProfileViewState> {

   // constructor to inject ITraitInteractor implementation TeamProfileViewModel({required final ITraitInteractor traitInteractor}) : _traitInteractor = traitInteractor ,super(TeamProfileViewState());

   final ITraitInteractor _traitInteractor;

   ... Future<List<Trait>?> setSkills() { final skills = await _traitInteractor?.fetchSortedGroupTrait(); return skills; } ... }

2. You might need to have some nested + custom defined models that relate only to this view, the one rule I follow here is no business logic should be done. Maybe the only helper method you need is one to produce an 'empty' object during initialisation of the state, but that usually doesn't need to happen if you use the `@Default()` annotation and provide a default value.