Комментарии 11
Спасибо. GetX своей универсальностью и отпугивает:( нужно все так поковыряться в нем
А Вы попробуйте с малого, например, с obs/Obx
- реактивных состояний.
Как говорится в оригинальной доке:
Если это ваша переменная:
var name = 'Jonatas Borges';
то, чтобы сделать ее реактивной, достаточно добавить
obs
var name = 'Jonatas Borges'.obs;
и в UI для реактивного поведения, нужно всего лишь обернуть ее в
Obx
:
Obx(() => Text("${controller.name}"));
Никаких кодогенераторов, никаких стримбилдеров наружу, и прочего бойлерплейта. Вся сложность спрятана под капотом библиотеки. Такая лаконичность делает код прозрачным, легким для прочтения и понимания.
И самое главное, вам не надо идти на компромисс между чистотой и принципами ООП. К примеру, чтобы добиться инкапсуляции переменной, не требуется никаких ухищрений (спасибо @AndrewPiterov за решение):
// Делаем переменную приватной
final _name = 'Jonatas Borges'.obs;
// Навешиваем геттер
get name$ => _name.value;
// И сеттер
set name(String value){
if(value.isNotEmpty){
_name(value);
}
}
и все. Реактивность UI не сломается, ничего вообще не надо менять. Obx(() => Text("${controller.name}"))
по-прежнему останется реактивным, хотя в других местах кода можно использовать controller.name
, как обычную переменную, ведь она таковой и является. Это решение очень изящно реализовано в коде библиотеки, там вообще стоит покопаться для развития.
Как вы думаете, почему при всей своей популярности и супер скорости это творение так и не удостоилось "Flutter Favorite", мб разработчики флаттер знают что то неведомое вам?
Не знаю, мб Вы знаете?
Я отнюдь не призываю к использованию Get тех, кто по тем или иным причинам не хочет этого делать. Я раскрываю тему дополнительного удобства для тех, кто им пользуется.
по своему не большому опыту с getx, с ним возникает много проблем из-за возни со стейтом при навигации, приходится учитывать много разных деталей и при этом придумывать костыли, чтоб контроллер не умирал при глубокой навигации. Думаю, что это проблема новичка, но с другими стейт-менеджерами такой возни не было.
При этом библиотека как-то берет на себя много задач, тот же dependency injection, по факту сделаный как сервис локатор, собственная навигация. В целом, библиотека сделана так, чтоб вгрызться в ваш проект и никогда из него уйти, и не понятно, что ждет проект при росте.
Возможно. Мы используем из Getx только GetxService, GetxController и их отличный локатор. Я не понимаю, почему из локаторов сделали жупел, думаю из-за неправильного перевода ) Он такой же DI-инструмент, да вот хоть Фоулера почитать. Навигация у него тоже кстати ничего, правда после выхода Navigator 2.0 я как-то больше к последней склоняюсь. С падением контроллеров не сталкивались, уже пяток больших проектов на Getx - полет нормальный. А по поводу вгрызться - ничего такого. Вполне себе соседствуют eazy_localization вместо Getx.localization, Dio вместо GetConnect, Getx очень дружелюбная либа. Ну и попробуйте отказаться от FlutterBloc
, если вы начали его использовать - тоже хапнете работенки. Так с любой более-менее серьезной либой будет. Getx очень изящно и легковесно сделан под капотом с точки зрения реактивности, Obs/Obx и протчая... Одно удовольствие работать.
Смотрю на эти числа и думаю, ответ на ваш вопрос возможно не в плоскости либы как таковой, а в психологической, межличностной или какой-то другой.
Известно ли вам кто такой Филип Грачек? а Реми вам известен?
на те вот на почитать перед сном
https://twitter.com/filiphracek/status/1468565501701939203
https://twitter.com/remi_rousselet/status/1468524635608256516?t=Uh7VJYqr_IYGtBcACH4Law&s=09
Ох, пахнуло снобизмом-то как! Наша команда умеет в BuildContext
достаточно, чтобы связно объяснить на JobInterview про все три дерева Flutter, про их задачи и не ляпать антипаттерны типа Widget _someFunc()
. Более того, наша команда понимает, что бездумное использование как Get, так и любого другого подхода - это путь в никуда. Наша команда знает, как под капотом устроен, к примеру, Obx
, или уже проще - Get.width
. Именно поэтому мы никогда не напишем MediaQuery.of(context).size.width
, вместо Get.width
, потому что чтобы достичь одного и того же результата первый соберет с десяток вызовов, а второй - всего один, чтобы достичь одного и того же результата: size = window.physicalSize / window.devicePixelRatio
.
В нашей команде вполне себе соседствуют BLoC
на уровне Model/Logic
и GetxControllers/GetxService
на уровне View/ViewModel
, потому что они вполне себе дружат и каждый выполняет свою роль наилучшим образом, а писать многословные конструкты из flutter_bloc
- увольте! Более того, Getx отлично сочетается с rxdart
, как ни странно. В нашем инструментарии, как у хорошего строителя (позволю себе аллегорию), есть и дрель, и шуруповерт и перфоратор и даже отверточек набор. Каждый мастер умеет в инструменты, подходящие под контекст (контекст задачи, если будет угодно).
Бездумное следование за авторитетами ничуть не лучше бездумного делания чего-либо. Вы подумайте об этом как-нибудь на ночь.
GetX for Flutter. Dependency Injection для частных случаев