Беру свои слова назад. Посмотрел в реализацию, это просто тихий ужас. А после того как они еще и из get_storage "бенчмарк" в сравнении со скульлайтом затащили - это просто позорище. Никому не советую.
Работает, там он выполняет асинхронную операцию А также существуют кондишен импорты и веб/сервайс вокеры.
Все блоки работают в одном изоляте. Это решает сразу много проблем, к примеру не нужно ломать голову над тем, как между несколькими изолятами построить коммуникацию, или над тем, сколько изолятов запускать
И создает новую, в виде дополнительного расхода ресурсов и копирования зависимостей между изолятами
Я провёл несколько внутренних тестов...
Поздравляю, потерял 5% ресурсов на копирование и кучу оперативной памяти на поддержание изолята, ничего с этого не выиграв)
Еще раз повторю - пользуйтесь всем чем хотите на свое усмотрение, но не надо вводить людей в заблуждение. А лучше поймите как работает эвент луп и все ваши "проблемы" как рукой снимет.
Идея хорошая и правильная.
Но реализовать это правильно практически невозможно из за обилия подводных камней.
1) веб, нам ведь нужны будут сервайс/веб вокеры, раз асинк не годится, для веба он тем более не подойдет.
2) количеством выделяемых изолятов надо тонко управлять, ставя в очередь задания, коим не хватило места (в акведуке на бэке, например, по изоляту на каждые два ядра).
3) объекты между изолятами не копируются, их сериализация/десериализация в двоичные данные и обратно не та вещь, которой можно принебрегать. Также отсюда растут весьма неприятные баги, которые периодически фиксят (например тот же баг, когда enum в мейн эвент лупе не соответсвует enum'у в изоляте).
Для себя я вижу решение только оставить БЛоКи в покое в основном изоляте, а оперировать изолятами и тяжелой обработкой уже точечно в слое бизнес логики.
PS: если проектировать архитектуру для общения с изолятами и подобной изолированости — может вам стоит отказаться от BLoC'а в сторону EventBus?
Сможете рассматривать каждый изолят как отдельный микросервис, а шину как месседж брокер. Pub/Sub гораздо проще управлять решая подобные проблемы. Но это может оказаться всеже слишком избыточным для большинства не самых сложных приложений.
Логика также на дарт.
В большинстве CRUD приложений вам ничего кроме дарт и не потребуется.
Но никто не запрещает и на swift/obj c/java/kotlin/c/js (не только логику, но и интерфейс), просто придется несколько раз писать одно и тоже, для кроссплатформы.
1) заводим регистр сведений
2) заводим реквизит «первые 3 буквы» и реквизит «полное наименование», индексируем
3) выполняем запрос с подзапросом (сначало по первым 3 буквам, затем по полному наименованию).
4) получаем свои пикосекунды поиска
Как смасштабировать по нескольким реквизитам и нескольким словам, думаю, понятно.
В данном кейсе никакие эластиксичи не нужны. И миллион записей это копейки. Все это делается средствами 1с или СУРБД (смотря где вас застал этот кейс).
Проверено не раз, сам впервые столкнулся когда нужно было искать по табличке с миллиардами записей весом в 350 гигабайт (микросекунды до получения результата).
Вы не правы.
В своей статье Вы сравниваете архитектуру (стейт менеджмент), виджет (ui элемент), di и все это с оберткой над dart:async. Прям целая каша в голове.
Никто не сомневается, что можно написать hello world вообще не оперируя такими понятиями и вообще используя только setState и Future builder.
Собственно, в этом и состоит к вам претензия.
PS: если хотите, распишу вам подробнее, зачем нужен DI (Provider, оберточка над Inheriting Widget), зачем стейт менеджмент (BLoC, который, между прочим, на rxdart).
Стоило упомянуть, что Флатер это ООП реактивщина и одна из самых популярных архитектур — BLoC (способ отделения слоя UI и Бизнес логики), чем то похожа на редакс. Только тут не управление состояниями, а событие порождающие состояния и реакции интерфейса на их смену.
Если немного помечтать, то можно было бы еще упомянуть и фуксию, если «выстрелит» она, то это сразу +100 очков Грифиндору Флатеру.
Flutter для веба — уже на старте вполне неплохо себя показало, хоть и сыровато.
Получаются вполне симпатичные PWA, но при этом отрисовка анимаций не всегда плавная (адекватного отображения прокручивающихся списков удалось добиться увеличением размера элементов и указания физики списка).
Флатер и дарт весьма симпатичны и на них возлагаю большие надежды.
Из субъективных нареканий: выпилили рефлексию (надеюсь, что вернут), сложные объекты всегда передаются по ссылке, а примитивы по значению.
Мобильный флатер уже сейчас вполне годится для продакшена и вполне себе теснит РН.
Спасибо за статью, мой комментарий, наверное, вышел слегка сумбурным.
Это настоящий classic, я бы даже сказал pleasantly
Беру свои слова назад.
Посмотрел в реализацию, это просто тихий ужас.
А после того как они еще и из get_storage "бенчмарк" в сравнении со скульлайтом затащили - это просто позорище. Никому не советую.
compute-ом, ведь он тоже не работает в вебе)Работает, там он выполняет асинхронную операцию
А также существуют кондишен импорты и веб/сервайс вокеры.
Все блоки работают в одном изоляте. Это решает сразу много проблем, к примеру не нужно ломать голову над тем, как между несколькими изолятами построить коммуникацию, или над тем, сколько изолятов запускать
И создает новую, в виде дополнительного расхода ресурсов и копирования зависимостей между изолятами
Я провёл несколько внутренних тестов...
Поздравляю, потерял 5% ресурсов на копирование и кучу оперативной памяти на поддержание изолята, ничего с этого не выиграв)
Еще раз повторю - пользуйтесь всем чем хотите на свое усмотрение, но не надо вводить людей в заблуждение. А лучше поймите как работает эвент луп и все ваши "проблемы" как рукой снимет.
Но реализовать это правильно практически невозможно из за обилия подводных камней.
1) веб, нам ведь нужны будут сервайс/веб вокеры, раз асинк не годится, для веба он тем более не подойдет.
2) количеством выделяемых изолятов надо тонко управлять, ставя в очередь задания, коим не хватило места (в акведуке на бэке, например, по изоляту на каждые два ядра).
3) объекты между изолятами не копируются, их сериализация/десериализация в двоичные данные и обратно не та вещь, которой можно принебрегать. Также отсюда растут весьма неприятные баги, которые периодически фиксят (например тот же баг, когда enum в мейн эвент лупе не соответсвует enum'у в изоляте).
Для себя я вижу решение только оставить БЛоКи в покое в основном изоляте, а оперировать изолятами и тяжелой обработкой уже точечно в слое бизнес логики.
Пользуясь случаем порекламирую библиотеки замечательных разработчиков и моих друзей, которые могут помочь вам в этом нелегком деле)))
pub.dev/packages/worker_manager
pub.dev/packages/computer
PS: если проектировать архитектуру для общения с изолятами и подобной изолированости — может вам стоит отказаться от BLoC'а в сторону EventBus?
Сможете рассматривать каждый изолят как отдельный микросервис, а шину как месседж брокер. Pub/Sub гораздо проще управлять решая подобные проблемы. Но это может оказаться всеже слишком избыточным для большинства не самых сложных приложений.
Или просто в сиай пайплайне проверяете аналайзером?
Спасибо за вклад в развитие флатера)
Еще будут работы по отображению нативных интерфейсов во флатере, так что еще не вечер и лотти себя еще покажет.
Логика также на дарт.
В большинстве CRUD приложений вам ничего кроме дарт и не потребуется.
Но никто не запрещает и на swift/obj c/java/kotlin/c/js (не только логику, но и интерфейс), просто придется несколько раз писать одно и тоже, для кроссплатформы.
В догоночку, есть различные линты, подсказывающие, когда возможно использовать const.
dart-lang.github.io/linter/lints/prefer_const_constructors.html
dart-lang.github.io/linter/lints/prefer_const_constructors_in_immutables.html
dart-lang.github.io/linter/lints/prefer_const_declarations.html
dart-lang.github.io/linter/lints/prefer_const_literals_to_create_immutables.html
и тд.
Особенно полезно при построении интерфейса на флатере.
Но у нее очень посредственная кодогенерация и объекты которые собираешься хранить — не должны быть иммутабельными.
2) заводим реквизит «первые 3 буквы» и реквизит «полное наименование», индексируем
3) выполняем запрос с подзапросом (сначало по первым 3 буквам, затем по полному наименованию).
4) получаем свои пикосекунды поиска
Как смасштабировать по нескольким реквизитам и нескольким словам, думаю, понятно.
В данном кейсе никакие эластиксичи не нужны. И миллион записей это копейки. Все это делается средствами 1с или СУРБД (смотря где вас застал этот кейс).
Проверено не раз, сам впервые столкнулся когда нужно было искать по табличке с миллиардами записей весом в 350 гигабайт (микросекунды до получения результата).
Вы же понимаете, что это не ржд пишет, а ради шутки некто былинную "пасту" отправил?)
В своей статье Вы сравниваете архитектуру (стейт менеджмент), виджет (ui элемент), di и все это с оберткой над dart:async. Прям целая каша в голове.
Никто не сомневается, что можно написать hello world вообще не оперируя такими понятиями и вообще используя только setState и Future builder.
Собственно, в этом и состоит к вам претензия.
PS: если хотите, распишу вам подробнее, зачем нужен DI (Provider, оберточка над Inheriting Widget), зачем стейт менеджмент (BLoC, который, между прочим, на rxdart).
Если немного помечтать, то можно было бы еще упомянуть и фуксию, если «выстрелит» она, то это сразу +100 очков
ГрифиндоруФлатеру.Flutter для веба — уже на старте вполне неплохо себя показало, хоть и сыровато.
Получаются вполне симпатичные PWA, но при этом отрисовка анимаций не всегда плавная (адекватного отображения прокручивающихся списков удалось добиться увеличением размера элементов и указания физики списка).
Флатер и дарт весьма симпатичны и на них возлагаю большие надежды.
Из субъективных нареканий: выпилили рефлексию (надеюсь, что вернут), сложные объекты всегда передаются по ссылке, а примитивы по значению.
Мобильный флатер уже сейчас вполне годится для продакшена и вполне себе теснит РН.
Спасибо за статью, мой комментарий, наверное, вышел слегка сумбурным.