Flutter: изменяемые поля в виджетах без сохранения состояния

Класс StatelessWidget помечен как immutable. Однако я использую scoped model, что означает, что я избегаю StatefulWidget и использую model для изменения state в StatelessWidget. Это приводит к тому, что у меня non-final fields в StatelessWidget, что не вызывает errors, потому что это просто warning. Но мне было интересно, есть ли способ лучше?


flutter dart state statelesswidget immutability
person footurist    schedule 07.11.2018    source источник
comment
Пожалуйста, добавьте пример кода. То, что вы делаете, звучит неправильно.   -  person boformer    schedule 07.11.2018

Ответы (2)


arrow_upward
8
arrow_downward

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

Классы extension StatefulWidget должны следовать тому же правилу, потому что они также реконструируются. Только State, который может содержать изменяемые поля, сохраняется во время жизни виджета в дереве макета.

Нет причин избегать StatefulWidget. Это фундаментальный строительный блок Flutter.

Фактически, ScopedModelDescendant также является виджетом с отслеживанием состояния. Основное преимущество scoped_model заключается в том, что вы можете отделить бизнес-логику от уровня виджетов. Это не устраняет необходимость в виджетах с отслеживанием состояния.

Используйте виджеты с отслеживанием состояния для:

  • Внедрение моделей с заданной областью видимости в дерево (виджет, который строит виджет ScopedModel). Сохраните экземпляр Model в State.
  • Сохранение пользовательского ввода (TextEditingController, состояние флажка)
  • Анимированные виджеты, требующие AnimationControllerсек.
  • Для хранения всего, что заканчивается на Controller (TabController, ScrollController, ...)

Часто бывает хорошей идеей сделать виджеты "страницы" (виджеты, которые создают Scaffold, доступные с помощью Navigator) с сохранением состояния. Часто это хосты для моделей с оптическим прицелом.

person boformer    schedule 07.11.2018
comment
Очень полезно! Как вы думаете, было бы ошибкой иметь ScopedModel, обернутую вокруг корневого MaterialApp, который действует как менеджер и содержит экземпляры всех других моделей, чтобы сделать их доступными из всех частей приложения? Повлияет ли это на производительность отрицательно? - person footurist; 07.11.2018
comment
Это не повлияет на производительность, но было бы чище использовать отдельный виджет ScopedModel для каждой модели, которая вам нужна (просто чередуйте их, опять же без влияния на производительность). - person boformer; 07.11.2018
comment
Создавайте модель с ограниченным объемом только в том случае, если вам нужна функция notifyListeners. В общем, если вам нужно только предоставить какую-то глобальную услугу, вы можете использовать простой InheritetWidget, который предоставляет услугу (услуга будет простым классом) - person boformer; 07.11.2018
comment
Я действительно рекомендую вам взглянуть на исходный код scoped_model, чтобы понять, что происходит - person boformer; 07.11.2018
comment
Я только что это сделал. И я задавался вопросом, подходит ли мне в любом случае модель с осциллографом. Если вы не возражаете, я бы очень быстро описал мою проблему с архитектурой: мне нравятся очень короткие классы, потому что это помогает мне сохранять контроль. На практике я бы создал виджет для каждой страницы, затем для каждой части пользовательского интерфейса страницы, а затем, возможно, снова разделил бы каждый из них, если у них много контента. - person footurist; 07.11.2018
comment
Проблема: мне нужно общение между ними. И чтобы избежать какого-то ада с конструкторами, я попробовал этот подход к управлению моделями с ограниченной областью видимости, который вкладывает модели с ограниченной областью видимости для каждого создаваемого мной класса, чтобы у меня был доступ к ним из всех частей приложения (я знаю, ленивый). - person footurist; 07.11.2018
comment
Как вы думаете, есть ли лучший подход для выполнения того, что я хочу, сохраняя при этом короткую структуру классов, которая помогает мне контролировать и иметь возможность запускать перестройку этих классов из любого места? - person footurist; 07.11.2018

arrow_upward
0
arrow_downward

Вот вам вопрос:

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

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

Как вы знаете, подходы к управлению состоянием приложения - это набор методов, которые позволяют вам как разработчику:

  • для привязки данных к виджетам.

Связывание данных с виджетами, в свою очередь, помогает вам как разработчику:

  • чтобы перестраивать виджеты автоматически при каждом изменении связанных данных.

Возможно, для этой цели вы можете использовать rxdart:

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

person UsabilitySpace    schedule 14.07.2020