State management is one of the most debated topics in Flutter. Some engineers like Bloc, others prefer Riverpod. But after working on large-scale Flutter apps with dozens of screens and business rules, one thing becomes obvious:
\nWhat matters most is not which library you pick, but how you organise responsibilities between UI, business logic, and state.
\nIn this article, I\u2019ll walk you through a ViewModel-driven architecture using Cubit.<\/p>\n
In most projects, a single Cubit or Bloc class ends up doing everything:<\/p>\n
As your app grows, this approach becomes hard to scale, test, or reason about. Your Cubit becomes a God class, doing too much, too often.<\/p>\n
To solve this, we can introduce a ViewModel layer<\/p>\n
What is a ViewModel?<\/strong> For example: Each ViewModel has two main responsibilities: MainState build() => MainState(<\/em> By splitting logic into ViewModels: –<\/strong><\/p>\n Below is the code example:-<\/strong><\/p>\n UI States:-<\/strong> @freezed factory TeacherState.empty() => @freezed factory StudentState.empty() => @freezed factory MainState.empty() => MainState( Each ViewModel mutates private fields and exposes a fresh state from build().<\/p>\n class TeacherViewModel<\/strong> { void refresh(Teacher teacher) { TeacherState build() => TeacherState( class StudentViewModel<\/strong> { void refresh(Student student) { StudentState build() => StudentState( Cubit never talks to TeacherViewModel or StudentViewModel directly.<\/p>\n class MainViewModel<\/strong> { void refresh({required Teacher teacher, required Student student}) { MainState build() => MainState( class MainCubit<\/strong> extends Cubit<MainState> { MainCubit() : super(MainState.empty());<\/p>\n void loadData() { _mainVM.refresh(teacher: teacher, student: student); TeacherSection UI<\/strong><\/p>\n class TeacherSection<\/strong> extends StatelessWidget { const TeacherSection({super.key, required this.teacher});<\/p>\n @override <\/p>\n class StudentSection extends StatelessWidget { const StudentSection({super.key, required this.student});<\/p>\n @override class TeacherStudentScreen extends StatelessWidget { @override Encapsulation<\/strong> \u2192 Each ViewModel is a focused unit and will handle specific UI logic\/state. Example Unit Test<\/strong><\/p>\n test(‘TeacherViewModel builds correct state’, () { This isn\u2019t about inventing yet another state management library. It\u2019s about discipline:<\/p>\n By applying this ViewModel-driven Cubit architecture, your Flutter codebase becomes cleaner, easier to test, and ready to scale \u2014 no matter how complex your app grows.<\/p>\n <\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Introduction State management is one of the most debated topics in Flutter. Some engineers like Bloc, others prefer Riverpod. But after working on large-scale Flutter apps with dozens of screens and business rules, one thing becomes obvious: What matters most is not which library you pick, but how you organise responsibilities between UI, business logic, […]<\/p>\n","protected":false},"author":2140,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":19},"categories":[518],"tags":[4969,4968],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/74735"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/2140"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=74735"}],"version-history":[{"count":16,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/74735\/revisions"}],"predecessor-version":[{"id":76855,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/74735\/revisions\/76855"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=74735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=74735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=74735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nA ViewModel is a boundary object that manages the state and logic for one specific UI component.<\/p>\n
\nTeacherViewModel<\/strong> handles teacher-related logic.
\nStudentViewModel<\/strong> handles student-related logic.
\nMainViewModel<\/strong> interacts with both ViewModels and connects with the Cubit.<\/p>\n
\nrefresh(object) \u2192<\/strong> update internal fields with fresh data
\nbuild() \u2192<\/strong> return a UI-ready immutable state after necessary logic is performed.
\nNote:- The view model can contain other logic methods as well.<\/p>\nHow It Fits with Cubit:-<\/strong><\/h1>\n
\n
\n\u00a0 \u00a0teacher: _teacherVM.build(),<\/em>
\n\u00a0 \u00a0student: _studentVM.build(),<\/em>
\n);<\/em>
\n
\n<\/strong>This keeps a single entry point<\/strong> (MainViewModel) between Cubit and the business logic.<\/p>\n\n
\nState will contain UI variables.<\/p>\n\n
\nclass TeacherState<\/strong> with _$TeacherState {
\nconst factory TeacherState({
\nrequired String name,
\nrequired String subject,
\nrequired int experience,
\n}) = _TeacherState;<\/p>\n
\nconst TeacherState(name: ”, subject: ”, experience: 0);
\n}<\/p>\n
\nclass StudentState<\/strong> with _$StudentState {
\nconst factory StudentState({
\nrequired String name,
\nrequired int grade,
\nrequired int age,
\n}) = _StudentState;<\/p>\n
\nconst StudentState(name: ”, grade: 0, age: 0);
\n}<\/p>\n
\nclass MainState<\/strong> with _$MainState {
\nconst factory MainState({
\nrequired TeacherState teacher,
\nrequired StudentState student,
\n}) = _MainState;<\/p>\n
\nteacher: TeacherState.empty(),
\nstudent: StudentState.empty(),
\n);
\n}<\/p><\/blockquote>\nViewModels<\/strong><\/h1>\n
\nString _name = ”;
\nString _subject = ”;
\nint _experience = 0;<\/p>\n
\n_name = teacher.name;
\n_subject = teacher.subject;
\n_experience = teacher.experience;
\n}<\/p>\n
\nname: _name,
\nsubject: _subject,
\nexperience: _experience,
\n);
\n}<\/p>\n
\nString _name = ”;
\nint _grade = 0;
\nint _age = 0;<\/p>\n
\n_name = student.name;
\n_grade = student.grade;
\n_age = student.age;
\n}<\/p>\n
\nname: _name,
\ngrade: _grade,
\nage: _age,
\n);
\n}<\/p><\/blockquote>\nMainViewModel<\/strong><\/h1>\n
\nfinal TeacherViewModel _teacherVM = TeacherViewModel();
\nfinal StudentViewModel _studentVM = StudentViewModel();<\/p>\n
\n_teacherVM.refresh(teacher);
\n_studentVM.refresh(student);
\n}<\/p>\n
\nteacher: _teacherVM.build(),
\nstudent: _studentVM.build(),
\n);
\n}<\/p><\/blockquote>\nCubit<\/strong><\/h1>\n
\nfinal MainViewModel _mainVM = MainViewModel();<\/p>\n
\nfinal teacher = TeacherState(name: ‘Mr. Smith’, subject: ‘Math’, experience: 12);
\nfinal student = StudentState(name: ‘John’, grade: 8, age: 14);<\/p>\n
\nemit(_mainVM.build());
\n}
\n}<\/p><\/blockquote>\nUI<\/strong><\/h1>\n
\nfinal TeacherState teacher;<\/p>\n
\nWidget build(BuildContext context) {
\nreturn Card(
\nmargin: const EdgeInsets.symmetric(vertical: 8),
\nchild: ListTile(
\ntitle: Text(‘Teacher: ${teacher.name}’),
\nsubtitle: Text(
\n‘Subject: ${teacher.subject}\\nExperience: ${teacher.experience} yrs’,
\n),
\ntrailing: IconButton(
\nicon: const Icon(Icons.refresh),
\nonPressed: () {
\n\/\/ Example action – reload teacher data
\ncontext.read<MainCubit>().loadData();
\n},
\n),
\n),
\n);
\n}
\n}<\/p><\/blockquote>\nStudentSection UI<\/strong><\/h1>\n
\nfinal StudentState student;<\/p>\n
\nWidget build(BuildContext context) {
\nreturn Card(
\nmargin: const EdgeInsets.symmetric(vertical: 8),
\nchild: ListTile(
\ntitle: Text(‘Student: ${student.name}’),
\nsubtitle: Text(
\n‘Grade: ${student.grade}\\nAge: ${student.age}’,
\n),
\ntrailing: IconButton(
\nicon: const Icon(Icons.edit),
\nonPressed: () {
\n\/\/ Add logic here
\n},
\n),
\n),
\n);
\n}
\n}<\/p><\/blockquote>\nTeacherStudentScreen<\/strong><\/h1>\n
\nconst TeacherStudentScreen({super.key});<\/p>\n
\nWidget build(BuildContext context) {
\nreturn BlocProvider(
\ncreate: (_) => MainCubit()..loadData(),
\nchild: BlocBuilder<MainCubit, MainState>(
\nbuilder: (context, state) {
\nreturn Scaffold(
\nappBar: AppBar(title: const Text(‘Teacher & Student’)),
\nbody: Padding(
\npadding: const EdgeInsets.all(16),
\nchild: Column(
\nchildren: [
\nTeacherSection(teacher: state.teacher),
\nStudentSection(student: state.student),
\n],
\n),
\n),
\n);
\n},
\n),
\n);
\n}
\n}<\/p><\/blockquote>\nAdvantages of the view model<\/strong><\/h1>\n
\nTestability<\/strong> \u2192 You can unit test TeacherViewModel without Cubit or UI.
\nComposable<\/strong> \u2192 MainViewModel is just a facade add more child VMs without touching Cubit.
\nPredictable<\/strong> flow \u2192 All updates through refresh() \u2192 build() \u2192 emit().<\/p>\n
\nfinal vm = TeacherViewModel();
\nvm.refresh(const Teacher(name: ‘Dr. Ray’, subject: ‘Chemistry’, experience: 10));
\nfinal s = vm.build();
\nexpect(s.name, ‘Dr. Ray’);
\nexpect(s.subject, ‘Chemistry’);
\nexpect(s.experience, 10);
\n});<\/p>\nConclusion<\/strong><\/h1>\n
\n