Слияние кода завершено, страница обновится автоматически
Оригинальная статья: https://levelup.gitconnected.com/flutter-state-management-in-2021-when-to-use-what-98722093b8bc
Иногда выбор меньшего количества вариантов может быть полезным, например в React обычно популярны один или два решения для управления состоянием, а в Flutter с конца 2020 года каждый месяц появляются новые решения для управления состоянием. Поэтому здесь мы выделим основные преимущества и недостатки этих решений, чтобы помочь вам выбрать наиболее подходящее решение для управления состоянием.
Обычно есть два решения для управления состоянием, которые можно использовать без изменения файла pubspec.yaml, что в большинстве случаев достаточно.
Метод setState действует только в локальной области видимости. Если ваш Widget нуждается в изменении своего собственного состояния, то метод setState будет лучшим выбором.
Например, если требуется изменение положения переключателя (включено/выключено) или хранение изменённого текста ввода, в этом случае нет необходимости рассматривать другие пакеты управления состоянием.
Моя рекомендация заключается в следующем: если состояние переменной необходимо только внутри данного Widget или в дереве компонентов всего лишь один родительский Widget, это считается локальным диапазоном, и использование StatefulWidget является самым подходящим решением.Если вам нужно передать состояние вниз по дереву компонентов, просто поместите переменную в конструктор подчиненного Widget; если же одну и ту же переменную нужно передать более чем одному Widget, тогда стоит рассмотреть более широкие способы управления состоянием.
Рассмотрим тот же переключатель, который был упомянут выше. Если этот переключатель управляет тем, находится ли приложение в темной или светлой теме, то в этом случае потребуется повышение уровня доступа к состоянию до точки, где оно сможет эффективно распространяться по дереву компонентов.
Когда вы используете сторонние библиотеки для реализации этой задачи, давайте рассмотрим InheritedWidget.
InheritedWidget позволяет любому нижележащему Widget обращаться к его свойствам. Это значит, что можно иметь переменную, например:
enum Тема { темная, светлая }
Внутри InheritedWidget любой Widget, связанный с темой, может получить доступ к теме через MyInheritedWidget.of(context).тема, и этот Widget автоматически перестраивается при обновлении темы.
Прямое использование InheritedWidget имеет недостаток в виде большого количества шаблонного кода, которое привносится в систему Widgets.
BLoC может быть одним из самых старых решений для управления состоянием в Flutter (не считая scoped_model). И он до сих пор выглядит неплохо.Недавно BLoC добавил Cubit в свой набор инструментов, что помогает ему оставаться актуальным, так как Cubit снижает количество шаблонного кода, что делает миграцию проще. По моему мнению, BLoC отлично работает в обоих этих областях:
BLoC хорошо работает в области нестрашной гибкости: многие могут это воспринять отрицательно — они хотят быстрее менять своё приложение, не пиша слишком много кода.
Однако для команд это положительно: ограничивая гибкость, можно гарантировать, что всё будет работать так, как было задумано первоначальными разработчиками. Например, если состояние имеет значения 1, 2 и 3, то другие программисты не случайно поменяют его значение на 4, что является преимуществом негибкости.
BLoC основан на событийном подходе, где события должны быть определены. Вызов API может запустить событие, которое приведёт к появлению состояния CallingAPIState, а затем, когда вызов завершится, состояние HaveAPIResultsState.
Если вам важно строго определять свои события и состояния, то BLoC идеально подходит для вас. Однако, если вам нужна гибкость и скорость разработки, то BLoC может не быть лучшим выбором.
Из-за исторических причин Provider также представлен здесь. Он прост, чист и хорош... но есть недостатки и возможности для улучшения.Provider можно рассматривать как использование InheritedWidget, что позволяет уменьшить количество шаблонного кода. В действительности Provider построен на основе InheritedWidget, просто уменьшая количество кода, которое вам нужно написать.
Если ваше приложение уже использует Provider, продолжайте использовать его. Это отличный пакет для управления состоянием, нет необходимости переходить на другое решение.
Однако есть места для улучшения, и я считаю, что RiverPod лучше всего справился с этими возможностями для улучшения.
На сайте RiverPod они называют себя "Provider, but different". Этот подход очень точно передает идею. Несмотря на то что Provider значительно сократил количество шаблонов, есть ещё места для улучшений. Кроме того, Provider зависит от BuildContext, что в большинстве случаев является положительной стороной (заставляет использовать дерево виджетов), но иногда получение доступа к BuildContext в нужном месте становится проблемой.
RiverPod улучшает возможности Provider следующими способами:- Меньше шаблонов: RiverPod отлично справился со снижением количества шаблонов Provider. Разработчики могут регистрировать один глобальный контейнер вместо регистрации каждого провайдера отдельно. (Некоторым может показаться пугающим наличие всего этого в одном месте — не волнуйтесь, вы можете контролировать свои пакеты.)
BuildContext: Это также положительно, как уже упоминалось выше. Иногда получить доступ к BuildContext в нужном месте невозможно.Provider не находится в дереве. Это огромное преимущество, которое экономит много времени.RiverPod представляет собой лишь альтернативную версию Provider, но более плавную и эффективную. Если вы начинаете новый проект и планируете использовать Provider, я настоятельно рекомендую рассмотреть использование RiverPod.Вот несколько других решений, которые были исследованы при выборе системы управления состоянием, но в конечном итоге не были выбраны:
GetX: Я не являюсь поклонником GetX. Этот пакет пытается выполнять множество задач, что ограничивает его гибкость. Если вам требуется "полный набор" функциональностей от третьего лица, GetX может быть хорошим выбором, но я пробовал его и не был доволен.
get_it: get_it не является системой управления состоянием — однако многие используют его таким образом. Если рассматривать его как систему управления состоянием, это приведет к путанице.
redux / fish_redux / mobx: Эти решения имеют корни в React и имеют очень похожий стиль. Однако я считаю, что для Flutter лучше иметь специально разработанную систему управления состоянием, которая будет чище и проще.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )