Comments 21
А кто-то меняет фронт с Dart на TypeScript+React... ))
Flutter - наше всё, конечно. Но просто попробуйте GoLang.
У всех задачи разные. На многих вполне серьёзных проектах вообще всё по-старинке, html+php+js, и на то есть свои веские основания.
Простите, а как на Go фронт писать?
Сайт написанный на GO https://go-app.dev/
Согласен, поскольку эти подозрения меня самого никогда не покидали.
Но когда у тебя такой богатый выбор инструментов, как понять, что А будет лучше Б, С и Д? Про какой ни прочтёшь, так они все хорошие, а значит обязательно где-то притаились грабли :-)
А раз пока нет четкого понимания, что именно мне требуется, кроме простоты, то считаю лучшим выбором взять и опробовать то, что лежит в основе. По крайней мере пока что привычка "искать недостающие ответы в исходниках ядра" меня ещё не подводила :-)
А что мешает setStateом обновлять точечно? А для прокидывания изменений по дереву виджетов использовать inhiretedwidget или provider? Проблема setstate только в том что логика от ui не отделена. В производительности ты ничего не проигрываешь
Ну setState обновляет весьма массово - всё дерево виджетов, которое под ним...
С другой стороны, разработчики говорят, что делает он это весьма экономно, всё объекты, которые можно сохранить, система сохраняет, просто цепляет старые инстансы состояния к новым инстансам виджетов, не более.
Понятно, что стрелять setState как из пулемета - не очень хорошо.
С другой стороны, вот у меня в приложении виджет с карточкой, он одновременно может проигрывать анимацию переворачивания, перетаскивания, а сверху ещё виджет-прелоадер. И всё это я оптимизировал примерно никак - просто использовал готовые модули, заворачивая один написанный кем-то виджет с анимацией в другой, тоже с анимацией... А каждый кадр анимации - это, на секундочку, setState... Нууу, согласен, в веб-версии оно, пожалуй, уже лагает...
Я боюсь, что чтобы оценить пользу стейт-менеджера для своего проекта, надо всё-таки на старте понимать, с какой проблемой ты столкнется, плюс понимать особенности работы самого стейт-менеджера, чтобы понимать, что его механика работы действительно решает твою проблему.
Иначе это будет просто слепое копирование паттерна, "потому что мне так в учебном курсе сказали".
Под капотом все популярные стейтменеджеры - это тот же InheritedWidget + StreamBuilder. Разница лишь в api и в том, что же хранится в InheritedWidget. Рокетсайнс никакого нет, достаточно разобраться с этими штуками, чтобы легко по своему вкусу уже выбрать между готовыми решениями. Изучать внутреннее устройство каждого решения нет необходимости.
Моё личное мнение – какими бы болячками ни болели сейчас Dart и Flutter, на данный момент это наиболее удачное кроссплатформенное решение, которое я видел.
Под критерии, которые вы описали, определенно, лучше подходит Haxe. Не смотрели?
Честно сказать, впервые от вас вот и услышал.
Конечно, не дело давать "экспертные заключения", посмотрев сайт проекта с мобильника, но похоже, что это решение больше подходит под шеринг бизнес-логики, а уже слой интерфейса придется пилить каждый раз заново, используя доступный для каждой платформы свой API...
В результате, интерфейсы можно шарить не только под веб-мобайл-десктоп, но еще и под консоли типа Switch и PlayStation.
Кроме того, можно взять тот же React Native, для которого есть экстерны под Haxe.
Спасибо, интересно! И правда, с беглого взгляда наискосок такого не узнаешь.
А вы на нём, если не секрет, какие вещи создавали?
В качестве хобби кучу всего, игровые прототипы, утилиты, в том числе с использованием c/c++ библиотек. Периодически попиливаю свою библиотеку для лэйаута (в том числе, интерфейсов). Кое-что есть на гитхабе, там ник такой же, как и здесь.
Спасибо за интересную статью. Использовать дарт на бэке в серьезном проекте я, конечно, не стал бы, просто потому что нереально потом будет хороших бэкендеров найти на поддержку. Но из любопытства все равно интересно.
Не совсем понял какие сложности с авторизацией у Firebase. Там же можно просто скачать JSON с приватным ключом от сервисного гуглового аккаунта и положить его в ресурсы. Для самого взаимодействия с фаером использовать при этом их SDK. Все. Для типовых задач за глаза должно хватить
Спасибо за статью - хорошо написано, и даёт представление о процессе именно вашего вникания.
От себя добавлю, что главная проблема дарта - малое количество готовых библиотек, но они здорово растут в количестве и качестве, вангую, что скоро этой проблемы не будет
Пара вопросов:
1) какая самая неожиданная вещь была для вас во флаттере? что-то вроде "шоооо, зачем именно так?!"
2) приходилось ли руками подправлять код js после билда веб-версии? (Мне - регулярно приходится, что б работал скролл внутри фрейма)
3) как вы обходите то, что при импорте html библиотеки не билдится моб версия? (Мой рабочий вариант - комментирование импорта, так как условный импорт не спас совсем)
4) попробуйте не поднимать каждый раз новый стек роутов, так как по кнопке "назад" я возвращаюсь в пред экран, хотя он по идее уже не должен быть доступен. Или так и задумывалось?
5) setState и streamBuilder хватает для большинства задач, особенно при нормальной доке, те камрады, что говорят про setState и "перерисовку всего" не учли логику рендера флаттера или злоупотребляют ключами виджетов. Конечно уже на крупных проектах нужно что-то просто заставляющее технически всех писать в схожем стиле.
6) а где брали дизайн для карточек?
7) андроид тоже можно билдить в докере
Самым неожиданным, как я уже говорил выше, был вау-эффект от того, что всё сразу работает, как задумывалось, ещё при первом запуске. Я бОльшую часть своего кода в жизни написал на PHP, и там вот довольно типичная ситуация, что написал один раз - теперь начинай гонять свой код в различных условиях, потому что где-то обязательно в переменной будет совсем не то, что ты ожидаешь. При этом сам ты можешь писать просто идеальный код, но достаточно одной какой-то или довольно старой библиотеки, или либы, которую автор написал, спустя рукава, несколько неопределённых аннотаций - и даже максимально строго настроенный линтер в IDE уже не спасёт. А у многих он настроен же вообще кое-как, если вообще есть привычка обращать внимание на его предупреждения. В Dart же такие вольности невозможны, как бы ни был убог твой личный редактор кода - проект просто не скомпилится. И это хорошо!
В остальном я бы не сказал, что язык меня как-то удивил своими синтаксическими возможностями. Даже напротив, после PHP я чувствовал себя "немного связанным", но со временем научился выкручиваться. Больше всего меня удручает система наследования, а именно то, что статические методы и свойства не наследуются. Просто раздражает каждый раз копипастить один и тот же кусок кода, чтобы сделать класс синглтоном. И ещё раздражает необходимость прокидывать каждый именованный параметр в конструктор класса-родителя, когда наследуемся. Сам Flutter вдоль и поперёк завален этими простынями кода, в котором просто параметры прокидываются из одного конструктора в другой. И при этом разработчики не морьщась заявляют, что они борятся с лишним кодом, они за простоту, лаконичность и так далее и так далее... Как так?! Так что дизлайков Dart от меня тоже получил.Нет, руками ничего не правил, чему, признаться, был приятно удивлён. Я ожидал, что мне придётся искать какой-то способ выкинуть из проекта импорт класса, работающего на изолятах, но даже этого не пришлось делать: проект прекрасно работает, только при рендере зависимого виджета выскакивает эксепшн. Скрыл зависимый виджет - решил проблему.
Не возникало такой ситуации. В целом я очень осторожно подходил к выбору библиотек на проект, если было подозрение, что либа "слишком web-ориентирована" или "слишком мобильно-ориентирована" - я старался найти альтернативы.
Ага, понимаю, о какой проблеме вы говорите :-) Я её видел, но мне показалось несущественным, пожтому просто махнул рукой. Ведь скорее всего все эти экраны с документацией при регулярном использовании просто поотключают да и всё. А уж ребятам, кто раньше игры вёл, такие вещи и вовсе не нужны. Более насущная пробелма вскрылась, когда мы собрались тестировать игру в реальных условиях. Предполагается, что мобильник с картами будет передаваться по кругу между игроками. И несколько раз вознгикла ситуация "Ой, я тут случайно кнопку нажал, разблокируй телефон обратно, плиз". Телефон разблокировали, а андроид тем временем прибил приложение. Не страшно. если играем без "магии" - ну, перемешабтся карты, переживём. Но мы играли с "магией", то есть там игрок мог оставить "бомбу", которая "взорвалась" бы через несколько ходов и принудила бы дроугого игрока менять свою историю в соответствии с заданными условиями. И вот это всё потерялось. Тут -то я и понял, что совсем забыл о сохранении состояния, чего на мобилках забывать непростительно.
Лайк :-)
Да попросил у ребят скинуть мне сканы колод, которые у них уже были в бумаге. Где уж они их брали - не ведаю, наверняка просто надёргали как-то из интернета. Вообще в былые времена движуха была куда активнее, у многих были "кастомные" колоды под себя, даже специально тренировали гейм-мастеров, проводили "экзамены", но потом @may-cat стало скучно всем этим заниматься, и я могу его понять :-) На самом деле я даже не знаю, когда точно всё это начиналось. Ну, лет 10 назад как минимум, потому что тогда мы с Игорем только познакомились. Но, скорее всего, ещё больше.
Не пробовал, но уверен, что да... эхх, вот бы под Mac/iOS можно было бы билдить в докере и тестить на эмуляторе... Ну, для друзей-яблочников, собственно, я и поднял web-версию.
Очень даже работает похожий подход, например мы разрабатываем огромную сложную платформу для анализа данных, научных вычислений и интерактивной визуализации на Дарте: https://datagrok.ai
Если кому-то интересны детали, вот здесь наше выступление на Дартапе как раз на эту тему: https://www.youtube.com/watch?v=lDcTVlfJoFg&ab_channel=WrikeTechClub
Да, спасибо, смотрел эту конференцию, в том числе рекомендовал ваше выступление посомтреть всем интересующимся. Очень вдохновляет... с одной стороны. С другой - подход работает, но как мне кажется, во многом за счёт неимоверного скилла людей, стоящих у технических истоков проекта. Это совсем другое дело, чем если думать о том, как же запилить проект в ограниченный бюджет, с легко подменяемыми и быстро обучаемыми разработчиками и т.п. Вон, выше в комментариях и сайты на Go люди пишут, и этот подход тоже работает, но в скольких специфических случаях он экономически выгоден?
Что я пока вижу - на дарте и в бэк, конечно, тоже можно, но в подавляющем большинстве случаев все-таки не нужно, а во-вторых неизвестно, что будет через год, два, пять.... библиотеки под него рождаются так же быстро, как и умирают, и если нет решимости и целесообразносити вкладываться в собственные разработки, то без внятных сторонних библиотек для бэкенда сам по себе дарт не очень-то и нужен.
Dart, Flutter и кроссплатформа: небольшой разбор на практике