Flutter и fullstack Dart в реальной разработке —
без занудства и ненужных абстракций.
Архитектура, практические приёмы, разборы кода.
Для Flutter-разработчиков, которые хотят увереннее чувствовать себя в реальных проектах
💬 @dartway_dev_ru_community
Post #84
561
State Management — это не про выбор библиотеки
Когда разработчики слышат про state management,
они думают про:
— Provider
— Riverpod
— BLoC
И кажется, что если выбрать “правильную” библиотеку
и аккуратно разложить всё по папкам —
то архитектура станет хорошей
Нет, не станет
—
Главный вызов state management —
найти баланс между консолидацией и инкапсуляцией
—
Первая крайность — монструозные стейты
Один большой объект с десятками полей,
на который завязан весь интерфейс
Вроде удобно
но в итоге:
— сложно понять, что влияет на что
— лишние перерисовки
— любое изменение тянет за собой всё
—
Вторая крайность — раздробленный хаос
Много маленьких кусков состояния,
сшитых через коллбеки, провайдеры и костыли
И любое изменение:
👉 требует лезть в несколько мест
👉 ломает связи между фичами
—
И вот здесь плохая новость:
универсального решения нет
В каждой задаче тебе нужно принимать решение:
— что выносить в отдельный state
— что оставить локально
— что просто передать параметром
—
State management — это не про библиотеку
Это про способность принимать эти решения
_____________________________________________________
State Management is not about choosing a library
When developers hear about state management,
they think of:
— Provider
— Riverpod
— BLoC
And it feels like if you pick the “right” library
and organize everything neatly into folders —
your architecture will become solid
It won’t
—
The real challenge of state management
is finding the balance between consolidation and encapsulation
—
The first extreme — monolithic state
A single large object with dozens of fields,
driving the entire UI
Seems convenient
but leads to:
— unclear dependencies
— unnecessary rebuilds
— changes affecting everything at once
—
The second extreme — fragmented chaos
Multiple small pieces of state
stitched together with callbacks, providers, and hacks
And any change:
👉 requires touching multiple places
👉 breaks feature boundaries
—
And here’s the uncomfortable truth:
there is no universal solution
In every case, you have to decide:
— what should be extracted into separate state
— what should stay local
— what can just be passed as a parameter
—
State management is not about a library
It’s about your ability to make these decisions
Когда разработчики слышат про state management,
они думают про:
— Provider
— Riverpod
— BLoC
И кажется, что если выбрать “правильную” библиотеку
и аккуратно разложить всё по папкам —
то архитектура станет хорошей
Нет, не станет
—
Главный вызов state management —
найти баланс между консолидацией и инкапсуляцией
—
Первая крайность — монструозные стейты
Один большой объект с десятками полей,
на который завязан весь интерфейс
Вроде удобно
но в итоге:
— сложно понять, что влияет на что
— лишние перерисовки
— любое изменение тянет за собой всё
—
Вторая крайность — раздробленный хаос
Много маленьких кусков состояния,
сшитых через коллбеки, провайдеры и костыли
И любое изменение:
👉 требует лезть в несколько мест
👉 ломает связи между фичами
—
И вот здесь плохая новость:
универсального решения нет
В каждой задаче тебе нужно принимать решение:
— что выносить в отдельный state
— что оставить локально
— что просто передать параметром
—
State management — это не про библиотеку
Это про способность принимать эти решения
_____________________________________________________
State Management is not about choosing a library
When developers hear about state management,
they think of:
— Provider
— Riverpod
— BLoC
And it feels like if you pick the “right” library
and organize everything neatly into folders —
your architecture will become solid
It won’t
—
The real challenge of state management
is finding the balance between consolidation and encapsulation
—
The first extreme — monolithic state
A single large object with dozens of fields,
driving the entire UI
Seems convenient
but leads to:
— unclear dependencies
— unnecessary rebuilds
— changes affecting everything at once
—
The second extreme — fragmented chaos
Multiple small pieces of state
stitched together with callbacks, providers, and hacks
And any change:
👉 requires touching multiple places
👉 breaks feature boundaries
—
And here’s the uncomfortable truth:
there is no universal solution
In every case, you have to decide:
— what should be extracted into separate state
— what should stay local
— what can just be passed as a parameter
—
State management is not about a library
It’s about your ability to make these decisions
- 👍 5
- ❤ 1
- 🔥 1
