Provider — популярне рішення для управління станом у Flutter. Ми часто бачимо, як розробники витрачають тижні на переписування управління станом, почавши з Provider, а потім усвідомивши його обмеження. Проблема не в Provider, а в неправильній архітектурі: хаотичні ChangeNotifier, відсутність шару репозиторіїв, неконтрольовані перерисовки. У цій статті ділимося перевіреним підходом до налаштування Provider-архітектури, який використовуємо в комерційних проектах — від стартапів до продуктів з аудиторією 100 000+ користувачів. Provider дозволяє реалізувати управління станом у 2 рази швидше, ніж BLoC, за рахунок меншого об'єму бойлерплейту. Згідно з офіційною документацією Flutter, Provider — рекомендований вибір для малих та середніх додатків.
Чому Provider — правильний вибір для невеликого проекту?
Пакет provider (зараз на версії 6.x) обгортає InheritedWidget у зручний API та позбавляє від ручного пробросу залежностей. Для команди з 1–3 осіб та додатку з 10–20 екранами це прагматичний вибір: мінімум бойлерплейту, максимум читабельності. Provider входить у топ-3 пакетів Flutter за завантаженнями — понад 3 мільйони на місяць. Він стабільний, документований та підтримується командою Flutter.
Базова структура з ChangeNotifier
class ProfileNotifier extends ChangeNotifier { final UserRepository _repository; ProfileNotifier(this._repository); UserProfile? _profile; bool _isLoading = false; String? _error; UserProfile? get profile => _profile; bool get isLoading => _isLoading; String? get error => _error; Future<void> load(String userId) async { _isLoading = true; _error = null; notifyListeners(); try { _profile = await _repository.getProfile(userId); } catch (e) { _error = e.toString(); } finally { _isLoading = false; notifyListeners(); } } } Реєстрація в дереві віджетів:
MultiProvider( providers: [ RepositoryProvider(create: (_) => UserRepositoryImpl()), ChangeNotifierProxyProvider<UserRepositoryImpl, ProfileNotifier>( create: (ctx) => ProfileNotifier(ctx.read()), update: (ctx, repo, prev) => prev!..updateRepo(repo), ), ], child: MyApp(), ) У віджеті використовуйте context.watch<ProfileNotifier>() для підписки на зміни або context.read<ProfileNotifier>() для виклику методів без підписки.
Оптимізація перерисовок з Selector
Головна пастка Provider: context.watch() всередині build() перезбирає весь віджет при будь-якому notifyListeners(). Якщо ProfileNotifier викликає notifyListeners() тричі за одне завантаження — три перерисовки. Рішення: Selector<ProfileNotifier, UserProfile?> підписується тільки на конкретне поле, перерисовка тільки при його зміні.
Selector<ProfileNotifier, bool>( selector: (_, notifier) => notifier.isLoading, builder: (_, isLoading, __) => isLoading ? const CircularProgressIndicator() : const SizedBox(), ) Додатково: розділіть один ChangeNotifier на кілька за змістом — наприклад, AuthNotifier, CartNotifier, SettingsNotifier. Використовуйте ChangeNotifierProxyProvider для зв'язку між ними. Consumer Widget також допомагає читати тільки необхідні дані.
Як налаштувати MultiProvider для складних залежностей?
Зазначимо: коли додаток зростає, один ChangeNotifier перестає справлятися. MultiProvider дозволяє реєструвати кілька провайдерів на різних рівнях. Важливо правильно упорядкувати залежності: якщо ProfileNotifier залежить від UserRepository, то UserRepository має бути вище. Використовуйте ChangeNotifierProxyProvider для передачі залежностей між провайдерами. Для базового flutter provider setup достатньо п'яти кроків: визначити Notifier'и, створити репозиторії, налаштувати MultiProvider, підключити віджети та написати тести.
Порівняння Provider з альтернативами
| Критерій | Provider 6.x | Riverpod 2.x | BLoC 9.x |
|---|---|---|---|
| Залежність від контексту | Так | Ні | Так |
| Портованість у тести | Середня | Легка | Легка |
| Обробка помилок | Ручна | Вбудована | Вбудована |
| Продуктивність | Висока | Висока | Середня |
| Складність вивчення | Низька | Середня | Висока |
| Підтримка асинхронності | ChangeNotifier + Stream | AsyncValue | Stream |
Provider виграє у швидкості впровадження та читабельності коду. Якщо ваш проект не вимагає складних потоків даних або детального тестування — залишайтеся на Provider. Для більш гнучкого тестування та реактивних даних — розгляньте Riverpod. Для enterprise-додатків з сотнями екранів — BLoC.
Типові сценарії використання Provider
| Сценарій | Рекомендований патерн |
|---|---|
| Просте читання даних | Provider або ChangeNotifier |
| Форма з полями | Multiple ChangeNotifier або FormBloc |
| Аутентифікація | ChangeNotifier + Stream |
| Кешування запитів | ProxyProvider або RepositoryProvider |
Приклад тестування Notifier
void main() { test('ProfileNotifier loads profile', () async { final repo = MockUserRepository(); final notifier = ProfileNotifier(repo); await notifier.load('1'); expect(notifier.isLoading, false); expect(notifier.profile, isNotNull); }); } Що входить в роботу (deliverables)
- Проектування: діаграма залежностей Notifier'ів та Repository, вибір місць для MultiProvider.
- Реалізація: написання ChangeNotifier'ів, ProxyProvider, інтеграція з REST/GraphQL, Firebase або Supabase.
- Тести: unit-тести на кожен Notifier (ізольовано), widget-тести з ProviderScope (для Riverpod) або MultiProvider.
- Документація: README з архітектурною схемою та описом потоків даних.
- Навчання команди: сесія code review та best practices (30 хвилин).
- Підтримка: 2 тижні після здачі — виправлення помилок, відповіді на запитання.
Процес роботи
- Аналіз вимог (0.5–1 день): вивчаємо екрани, бізнес-логіку, джерела даних. Визначаємо, чи достатньо Provider або потрібне потужніше рішення.
- Проектування архітектури (0.5–1 день): малюємо граф залежностей, вирішуємо, які Notifier'и будуть незалежними, які — об'єднані.
- Реалізація (2–4 дні): пишемо код, підключаємо API, налаштовуємо тести.
- Тестування та QA (1–2 дні): перевіряємо коректність станів, відсутність зайвих перерисовок, покриття тестами.
- Деплой та документація (0.5 дня): пушимо код, пишемо README, передаємо деплой.
Загальний термін — від 5 до 10 робочих днів залежно від складності. Вартість розраховується індивідуально після аудиту поточного коду. Замовте налаштування Provider-архітектури під ваш проект — отримайте чистий код без болю.
Типові помилки при налаштуванні Provider
- Зберігання стану у віджетах: використовуйте Provider для передачі даних, не дублюйте у локальному State.
- Надмірне використання
context.watch: замініть наSelectorабоConsumerдля оптимізації. - Ігнорування dispose: обов'язково звільняйте ресурси в
dispose()ChangeNotifier (відписка від стрімів, закриття з'єднань). - Змішування Provider та інших рішень: не використовуйте одночасно Provider, BLoC та GetIt — визначтеся з одним підходом.
Наша команда має 10+ років досвіду комерційної Flutter-розробки, понад 40 реалізованих проектів. Ми сертифіковані як Flutter-розробники (Google Associate Android Developer). Гарантуємо, що архітектура буде масштабованою та тестованою. Надаємо гарантію 60 днів на всі архітектурні рішення. Отримайте консультацію з архітектури вашого додатку — зв'яжіться з нами для оцінки.