Комментарии 14
нет тут ни какого выбора если приложение маленькое хватит и инхеритов гетИкс кусок говнища это давно всем известно
Можете конструктивно описать свою позицию?
Он скорее всего имеет в виду что год два назад GetX при многократном использовании приводил к появлению глюков и снижал производительность всего приложения, причём глюки появлялись как там где непосредственно используется GetX, так и там, где в коде к GetX обращений не было и для сложных проектов в момент дедлайна последнее было однозначно весело.
Но я не считаю GetX говном, во-первых года два прошло, он наверняка улучшился, во-вторых ту простоту и скорость, которую он даёт хочется боготворить.
Согласен что BLoC - это новое хорошо забытое старое MVC. Но слишком много классов.
Моё мнение: паттерн не важен. Если опытный человек ясно видит что он делает - любой паттерн будет и удобочитаемым и производительным и т д. На старте невозможно учесть всё, да и не нужно, все популярные проекты сталкивались с переписыванием своего кода с нуля пару тройку раз, потому что изначально не было учтено расширение куда-то там, но если всё учитывать - это тоже снижает скорость разработки так, что один день проект просто может стать неактуальным, потому что какой то на коленке сделанный конкурент уже выстрелил. Часто в современных проектах то что можно реализовать одним виджетом растягивают в класс, это печально.
Bloc хорош для тех приложений, когда проект переписывают с Java или Csharp на Dart. GetX хорош для быстрого создания прототипа. А огромное тестирование конечно ждёт обоих)
Кто будет текст контроллеры освобождать ?
Только по этим двум строкам понятен непрофессионализм и незнание фреймворка
А что скажете про MobX?
Хорошая и недооцененная штука. Я по ней делал доклад год назад https://www.youtube.com/watch?v=hIVirQHx1nk (надеюсь, тут можно указывать ссылку).
Автор тот же, который делал MobX для React (это порт с веба), есть коммьюнити с несколькими активными чуваками и спонсорами, что позволяет предположить, что он не загнется в ближайшее время. Бойлерплейта значительно меньше, чем в Bloc.
Два минуса я бы все-таки упомянул:
В документации модели делают как сторы - не согласен с этим. Модели надо делать как обычные классы с final переменными, а обсерваблы как final Observable<T>.
Не всегда очевидно, на какую именно переменную триггерится Observer. Он реагирует на любые обсерваблы внутри себя. Сейчас в issues идет обсуждение, не сделать ли дополнительно обсерверы с ручным (явным) подписанием на обсерваблы (как Selector в провайдере).
Опишем конструктивно. Использовать GetX - очень плохая идея. В нем проблема именно в том, что он является одновременно всем: и стейт-менеджер, и сервис-локатор, и роутер, и локализации, и разные утилитки - и всё это работает из рук вон плохо, с огромным количеством багов.
Очень много функционала, копирующего встроенный функционал Флаттера (напр., update - это ChangeNotifier, показ диалогов). Весь код краденный или плохо переписанный с других пакетов (без указания авторства). obs-переменные - списаны с пакета observabl_ish. Локализация основана на устаревшем easy_localization, и так далее.
Автор забил на своё творение и уже года 2 его не поддерживает.
Я поначалу интересовался им (хотя и не рискнул тянуть в прод), но когда вышел Navigator 2.0, а GetX его спустя полгода так и не поддержал, понял, что можно забыть про эту игрушку.
По своей сути, это усовершенствованный Server Locator 2.0, который дает возможность не использовать Context.
А что, простите, плохого, в Context? Это очень важная концепция во Флаттере, без которой не обойтись. Если вы не понимаете его, рекомендую разобраться. Насколько я помню, в GetX из-за отсутствия контекста были баги с неправильной отрисовкой диалогов.
Горячо рекомендую взглянуть на MobX - тот же принцип с реактивным точечным обновлением UI, но активно мэйнтейнится, и всё работает идеально. Я туда контрибьютил немного. GetX в сравнении с ним - отсутствует необходимая оптимизация (компьютеды и экшены).
Мы на своем проекте используем связку MobX + get_it + go_router + slang - в итоге имеем тот же тулсет, что и GetX, но все пакеты регулярно обновляются и поддерживаются.
Интересный факт: GetX - единственный очень популярный пакет без отметки flutter favourite. С чего бы это...
У GetX нормальная документация - все понятно там. А Вы пишете за это минус для него - тут как раз плюс. Вы говорите что масштабируемость лучше у Блок-а. Масштабируемость это как раз увеличение сущностей(ибо это увеличение обьемов задач) А Блок оперирует минимальными сущностями. При больших обьемах это "ад многообразия"* 3 ( ибо у блока 3 файла на сущность) И после этого Вы пишете что это его плюс? Используя Блок Вы тут еще и get_it используете. Читать такой код(еще и смасштабированый) может только автор и то когда напьется. Блок слишком многословен и на нем по практике настаивают в основном люди-хейтеры. Так что статья в принципе хорошая но точно ее нельзя считать руководством к действию
Статья неконструктивна. Вы не можете сравнивать несопоставимые вещи. get - это огромный комбайн всего и вся сомнительного качества, пакет bloc предоставляет только стейт-менеджмент.
Далее, сквозь весь текст путаются понятия. Если коротко, BLoC != пакету bloc, MVC != GetX, BLoC != GetX .
Ещё кое-что. Признайтесь честно, вы смотрели исходный код get ? Подключите последнюю preview версию get: ^5.0.0-release-candidate-5 , которая есть на pub.dev и посмотрите. Посмотрите, что эта библиотека из себя представляет, что импортирует, из чего состоит, в особенности проверьте степень документации и комментирования, и обратите внимание на закомментированные участки кода. Вот, из прекрасного:
Оно вам точно нужно в проде или где-то ещё?
get-5.0.0-release-candidate-5/lib/get_navigation/src/routes/get_transition_mixin.dart
Не стройте иллюзий, этим нельзя пользоваться всерьёз.
Clean Architecture это принципы построения архтектуры, не архитектура и не паттерн.
DDD это так же набор принципов.
MVC это таки паттерн. Для слоя презентации, ни разу не архитектура, славится довольно сильной для последней моды связностью, предоставляя вьюшке самой обращаться за данными в модель и интерпретировать их, хотя двунаправленно общается с обеими, если это убрать будет уже MVP.
BLoC это брендированная реализация MVI с упором на "некий компонент бизнес-логики" в аббревиатуре не фигурирующий. Но вы же не понимаете паттерны буквально? Если у нас три буквы - это не означает что в реализации будет только три класса. Он у нас в примитивном виде и стейт-менеджер и интерактор, причем в одноименном пакете есть вместо Bloc-а Cubit который тупо вью модель из MVVM (так же легким движением руки превращающееся в MVI), так что можно вот этими самыми лапками из него сделать такой же блок. Или свалить эту обязанность на настоящий интерактор, который применим и в блоке. Короче так похожи, что мама родная не узнает.
GetX - в первую голову сервис-локатор и потом все остальное, стейт менеджмент там прямо скажем так себе, локаль требует доработки напильником, чо там еще есть? У меня есть в проде поделка с гетиксом, он там только для di и локали, причем последнюю приходится генерить самопальным скриптом иначе это оч плохо бьется с командой когда у тебя есть, например, чувак отвечающий за локализацию. С тем же успехом можно было бы взять гет ит как сервис-локатор и нагенерить удобную для себя локализацию самому (+1 не сильно-то и сложный класс). На то и рассчитывал если что-то пойдет не так. Но вроде покашляет еще.
Дальше больше. Как будто надергали кусков ото всюду даже не попытавшись их осмыслить. Немного страшно за флаттер-комьюнити с такими спикерами и таким залом.
А что про Riverpod молчат? Есть ли у него своя ниша и стоит ли на него обращать внимание тем, кому стейт-менеджмент пока неведомая хрень?
Да, вполне есть. Сам пакет развивается и комьюнити растёт.
Не уверен, что его стоит изучать прям первым, все-таки его подходы достаточно отличаются от ванильного флаттера. Riverpod, в отличии от BLoC, не рекомендует использовать какую-то определенную архитектуру, а скорее предоставляет инструментарий, на котором уже можно ее строить. Но при должном понимании это достаточно мощное решение, которое может сильно улучшить разработку и поможет избегать различных проблем
Документация для библиотеки flutter_bloc очень хороша, это и привлекло, захотелось погрузиться в изучение и самого паттерна и библиотеки, однако по мере изучения столкнулся с тем, что библиотека требует во первых хранить состояние в отдельном классе, что не критично но не всегда хотелось бы это делать, а во вторых что более важно, объект этого класса должен быть иммутабельным (т.е. неизменным), и это значит, что когда меняется состояние, мы не изменяем объект, а вместо этого, делаем его копию. Причем автор очень так крепко настаивает на этой идее и в целом кажется в сообществе сложился консенсус что это хорошо и правильно. Здесь был пулл реквест на добавление возможности использования иммутабельных объектов состояния (чтобы можно было форсировать оповещение, даже если не был создан новый объект), но он не был принят, хотя автор библиотеки в принципе открыт к обсуждению .
Мне же больше понравилась библиотека Provider (на ней кстати и основана сама flutter_bloc), и хотя сейчас она не развивается, и документация по ней сильно хуже, зато она как мне кажется более гибкая и простая.
Да, есть наследник провайдера, библиотека Riverpod, однако в документации явно указывается что рекомендуется также использовать иммутабельные объекты, для хранения состояния, что меня и оттолкнуло от изучения.
Да, конечно есть доводы в пользу иммутабельности объекта состояния, но я не могу свыкнуться с идеей, что если например состояние представляет из себя отображаемый список товаров, то для добавления нового элемента, нам надо сделать целую копию этого списка.
Сравнение архитектурных паттернов GetX и BLoC