Хроники управления состоянием Flutter 6.

Если вы до сих пор следили за развитием управления состоянием до унаследованных виджетов, вот краткое изложение того, что это такое.

  • У нас есть какое-то состояние
  • У нас есть способ предоставить его или сделать доступным для всех виджетов, которые в нем нуждаются.
  • У нас есть способ обновлять состояние и запускать перестройку виджетов с использованием (потреблением) состояний.

Это в основном тандем.

Эволюция и существование новых подходов к управлению множеством состояний является результатом того, что программисты хотят иметь возможность поддерживать хорошие методы разработки программного обеспечения либо потому, что в противном случае читаемость кода и ремонтопригодность утомительны, либо просто потому, что мы этого хотим. Но в любом случае соблюдение этих принципов обычно очень важно и лежит в основе лучших практик программирования.

В прошлый раз мы посмотрели на унаследованные виджеты, и, каким бы хорошим ни было его решение, мы не могли не съежиться от того факта, что было слишком много шаблонных кодов. Эти шаблоны варьируются от; явное определение условий, при которых разница в значении предыдущего состояния с текущим состоянием должна вызывать перестройку потребляющих виджетов, чтобы иметь весь виджет с отслеживанием состояния, который запускает перестройку класса, включающего состояние (унаследованный виджет), который, в свою очередь, запускает перестройку потребляющих виджетов при соблюдении определенных условий (что за цикл).

По сути, унаследованные виджеты - это просто виджеты, которые хранят данные, и данные доступны для справки и использования виджетом, который унаследованный виджет обернут вокруг, и все потомки виджетов. Унаследованные виджеты также предоставляют средства, с помощью которых все виджеты (только те), которые потребляют или используют это значение, перестраиваются в случаях, когда это значение изменяется.

Когда мы посмотрели на унаследованные виджеты, которые мы создали, мы поняли, что они содержали только один вариант состояния.

Что, если бы мы решили иметь более одного?

Но если посмотреть на решение критически, если количество кликов должно измениться, оба виджета, которые потребляют исключительно клики и исключительно размер, будут перестроены, и наоборот, чего мы не хотим, поскольку это вызывает ненужные перестройки виджетов.

Попытка решить эту проблему означает замену нашей зависимости InheritedWidget на зависимость от нового класса, называемого унаследованной моделью.

И используя его как

Это просто кричит о шаблоне, и его трудно понять (мы этого не хотим). Кажется, что для выполнения простых вещей потребуется много работы и кода. (Я не собираюсь углубляться в InheritedModels, он используется только для представления - передать точку - целей в статье).

Так как же добиться того же соответствия, но с меньшим количеством кода?

Мы пользуемся услугами провайдеров.

Providers - это пакет, который был создан как оболочка для InheritedWidget. Он популярен, потому что в нем используется тот же синтаксис, что и у унаследованных виджетов, поэтому сохраняется некоторая последовательность. Он также имеет другие преимущества, поскольку решает проблемы унаследованных виджетов.

  • Наличие слишком большого количества шаблонного кода (громоздкого и сложного в обслуживании)
  • Наличие слишком большого количества вложенного кода, что затрудняет факторизацию унаследованных виджетов и может сбивать с толку.
  • Вложенный ад, когда у нас есть несколько InheritedWidgets, которые мы хотим использовать, или обернуть один виджет.

Поэтому давайте посмотрим, как использовать этот пакет, сначала для предоставления данных по дереву виджетов, а затем в последующих статьях, как уведомлять об изменениях и запускать перестройки (с помощью ChangeNotifiers и StateNotifiers).

Provider - это внешний пакет flutter, который вам нужно будет установить (добавить в файл pubspec.yaml), следуя инструкциям здесь https://pub.dev/packages/provider/install

После этого давайте посмотрим, как предоставлять данные. Для контекста у нас есть виджет BlueSquare, который представляет собой синий квадрат, который отображает количество кликов по всем экземплярам объектов BlueSquare, определенных как унаследованный виджет.

Унаследованный виджет, как определено здесь

Чтобы предоставить переменную clicks нашим виджетам BlueSquare, давайте начнем с создания класса «состояния» для хранения значения.

А с поставщиками мы делаем

Используется как

Как видно выше, мы можем видеть, что у нашего класса Provider есть тип, который в данном случае является нашим классом «состояния»; ClicksState и возьмите параметр create, который представляет собой просто функцию, которая принимает BuildContext и возвращает объект класса «состояния».

При использовании данных у класса провайдера есть метод of ‹T› (), который просто просматривает дерево над виджетом, в котором он вызывается, для экземпляра T, в нашем случае T представляет ClicksState. Как только он его находит, он получает доступ к запрошенным данным или информации, тем самым предоставляя данные, для раскрытия которых он используется.

Этот подход может быть полезен в том смысле, что вы можете использовать поставщика как такового для передачи данных между виджетами; данные, которые не нужно изменять (иногда передавать данные между страницами приложения или что-то в этом роде). Но в нашем случае нам нужно, чтобы состояние изменилось, так как мы можем это сделать?

В следующих двух частях статьи мы увидим, как обрабатывать данные об изменении состояния с помощью ChangeNotifiers, а затем с помощью StateNotifiers.

На этом наше знакомство с провайдером заканчивается, увидимся в следующем.