Провайдер Flutter против GetX для управления государством

Question

Я собираюсь начать новый проект Flutter и не могу выбрать между Provider и GetX . Есть и другие варианты, но мои товарищи по команде убеждены в использовании GetX, пока я прошел курс Flutter, и он использовал пакет Provider для управления состоянием.

Итак, у меня есть приблизительное представление о подходах обеих библиотек, но когда использовать какую библиотеку - моя реальная проблема. Плюс я не нашел по этому поводу конструктивного обсуждения, хотя были некоторые критические замечания по поводу раздутия GetX и грубости автора :(

Итак, требуются технические и честные взгляды.

Спасибо

Answer 1

Как кто-то сказал мне о Riverpod (улучшенный провайдер) и GetX:

В конце дня используйте все, что выполняет свою работу. Я не думаю, что мы должны идеализировать (или фанатизировать) какие-либо из этих фреймворков. Люди тоже устроены иначе. Один человек может чувствовать себя более комфортно с GetX, а другой с Riverpod (каждому свое).

Я начал с Provider и сейчас использую GetX, почему? Потому что GetX проще, вот так.

Answer 2

После написания нескольких приложений Flutter я отвлекся на другую работу. Теперь я вернулся и снова пытаюсь выбрать решение для управления состоянием, прорабатывая текущую партию видео на YouTube и статей на Medium.

Моя самая большая проблема всегда заключалась в доступе к службам, которые хранят и поддерживают состояние в большом приложении. Хорошим примером может быть доступ к службе Firebase Authentication, которая хранит сведения о текущем пользователе из ряда ViewModels /Controllers/ и т. Д., Находящихся за пределами дерева виджетов.

Provider - много видео с простыми примерами, но без четкого / простого способа доступа к службам из ViewModels /Controllers/ и т. Д. С помощью Provider, меня подталкивали к BLoC

BLoC - я против генерации кода и шаблонов, это не BLoC, это я ;-)

Cubit - выглядит более многообещающим для моего стиля, но после того, как он был снова поглощен BLoC, я не уверен, что он популярен / используется, что имеет вес в моих решениях.

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

GetX - написав несколько приложений год назад, я остановился на GetX. Это был ясный / лаконичный способ решения "государственных" проблем, которые у меня были. Я все еще пытаюсь продвинуться вперед с RiverPod, но чем больше я борюсь, тем больше у меня возникает соблазн отказаться от него и просто вернуться к GetX. Плюс это дает мне чистую навигацию и другие полезности. Я также восстановил график от Бена Баттерворта, и GetX все еще ускоряется и собирается обогнать Provider, что является хорошим знаком для принятия сообществом.

Самый длинный ответ, который я когда-либо напишу ....

Answer 3

Я посмотрел на звезды GitHub для популярных решений для управления состоянием (некоторые из них не просто управление состоянием):

Мои наблюдения: GetX (КРАСНАЯ линия) новый и растет быстрее, чем Provider. Через несколько месяцев он станет лидером и, в конечном итоге, очевидным / безопасным выбором. То же самое я отношу к Flutter vs React Native (не будем вдаваться в подробности 😅). Поэтому я буду использовать GetX для нового проекта, который начал в эти выходные.

• Pub.dev любит : GetX имеет 3643 любит, чуть меньше (27 меньше) Провайдер с 3670 любит.
• GetX пока не признан фаворитом Flutter, но провайдер -.
• Звезды Github: у GetX 2,8 тыс., У провайдера 3,4 тыс., Но у GetX траектория лучше.

Кроме того, Navigator 2.0 не получил должного отклика и вносит путаницу в основной способ использования большинства этих решений для управления состоянием. GetX имеет функции навигации, поэтому вам не нужно беспокоиться о путанице между навигацией 1.0 и 2.0. TL; DR: он обеспечивает простоту в мире путаницы.

Вы можете создать график здесь , это веб-сайт Тима Кяня .

Answer 4

Хорошо! На этот тип вопросов уже есть так много ответов и мнений. И самый очевидный ответ ... нет правильного ответа. И не должно быть. Помимо выполнения работы, существует множество факторов. Нет правильного способа выполнить какую-либо работу. Но вы всегда должны выбирать способ, который соответствует (ну, ничто действительно не соответствует на 100%) вашей философии или философии ваших товарищей по команде.

Раньше я работал как с Provider, так и с Bloc, но теперь GetX становится очевидным, и в настоящее время это мое предпочтительное решение для многих аспектов разработки Flutter.

Я могу только поделиться своими рассуждениями о переключателе. То есть: GetX - это экосистема / микро-фреймворк внутри Flutter. Он не раздут, это то, чем он должен быть: в некотором роде законченное решение. Я обнаружил, что требования проекта могут быть частично удовлетворены только одним пакетом. Что было невозможно при использовании Provider или Bloc. И иногда я сталкивался с проблемами зависимости. И теперь это более серьезная проблема при переходе на нулевую безопасность. Я получаю не только решения для управления состоянием, но и управление зависимостями, служебные службы, более простую и надежную навигацию, адаптивный дизайн и разделение задач в одном пакете!

Большую часть критики получает GetX за то, что он не делает вещи так называемым « способом Flutter ». Я не могу быть более безразличным к этому « способу Flutter », если GetX облегчит мне жизнь.

И если я не знаю и не общаюсь с автором / сопровождающим лично, то почему я должен заботиться о его грубости?

GetX - это проект с открытым исходным кодом, и его сообщество постоянно растет.

Answer 5

Я пробовал их оба плюс вот что я знаю:

Провайдер хорош для небольших приложений, но для больших приложений это большое НЕТ, если вы не хотите использовать его с и написать много шаблонов

Лучше использовать (переписать), а не поскольку оба могут легко и просто отделить бизнес-логику от пользовательского интерфейса.

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

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

Answer 6

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

А) Вам не нужно заворачивать целиком в виджете, чтобы обеспечить область виджетов вниз по дереву виджетов, когда вам нужно перестроить. Если вам нужно что-то перестроить, достаточно просто обернуть это прямо в один виджет, и это помогает упростить работу.

Б) Доступ к переопределение любого расширяемого класса заменяет виджета с отслеживанием состояния. Это позволяет радикально очистить код пользовательского интерфейса и использовать большинство или все виджеты без сохранения состояния.

C) Добавление к класс позволяет повторно использовать анимацию и контроллеры вкладок на разных страницах и дальнейшее сокращение кода в вашем пользовательском интерфейсе.

D) предоставляют отличные мощные функции для добавления слушателей в наблюдаемые потоки.

E) Множество интересных мелочей, которые экономят время, т.е. против а первый работает без использования метода сборки, потому что не требует контекста.

В целом оба варианта являются отличным выбором, и их легче всего освоить. Провайдер был рекомендован Google неспроста, потому что он надежен, прост и важен. Итак, опять же, вы не ошибетесь в любом случае. Но по причинам, о которых я упомянул, Getx стал моим предпочтительным решением.

Answer 7

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

Мне лично нравится использовать Getx в первую очередь для маршрутизации, а Riverpod - для управления состоянием. Я совершенно уверен, что есть много других способов сочетать / согласовывать управление состоянием с обоими и создавать шаблон, который работает для вас.

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

Просто следуйте своей интуиции, худшее действие - бездействие. Вы всегда можете исправить это позже.