React Native если и загнется, то по совершенно другим причинам.
- Если типизация - проблема - можно просто использовать TypeScript, тем более в мире RN это сейчас вполне мейнстрим.
- Facebook использует RN в своих проектах.
И вот тут основная проблема - они пилят его для себя, сами используют и сами определяют роадmap, исходя из своих потребностей, просто иногда отдавая иногда что-то в OpenSource, а Flutter - это прям продукт.
Лучше посмотреть сначала на то, что такое Firebase и RabbitMQ
Firebase - это просто БД, которая будет вызывать через SDK коллбэк при изменениях в требуемых данных.
Вот тут разбирается примерная структура БД для чата в Firebase https://stackoverflow.com/questions/44535831/fireb...
Про RabbitMQ - там нужно подписывать на каналы, да, сообщения лучше типизировать.
Слушайте, вспоминаю что что-то такое было, но это была очень простая ошибка - то ли нейминг файла и класса не совпадал, ,то ли папка с воркерами не подгружалась.
То есть то, что он не видит его из консоли означает что этот worker просто не видим для приложения.
Не, Rails при помощи драйвера jquery-ujs делает такую вещь - если у какого-то тега ( скажем, ссылки ) есть аттрибут data-confirm="xxx", то автоматом перед переходм по этой ссылке выводится диалог "xxx [ok] [cancel]" и переход происходит только если ok.
А хотелось бы не confirm с [ok] [cancel] а prompt, при этом так же изящно, в UJS стиле.
Появился нюанс - если загрузка HTML из WebView происходит из файловой системы, то все работает, аналогичный HTML полученный через HTTP - не цепляет интерфейс.
С другой стороны, я вижу что народ бросаются юзать все, о чем увидит в Railscasts, без понимания зачем это нужно, в результате кода становится явно больше, а толку — нет. Просто во всех задачах что мне приходилось решать для работы с paperclip точно нужно было меньше усилий + всегда был какой-то потрах с RMagick в деплое, и я пытаюсь понять usecase для которого удобен carrierwave.
Есть большая ловушка в понимании «стандартных паттернов» вначале и когда заказчик начинает что-то видеть работающее у себя на сайте. Я всегда оговариваю такие вещи до начала. Никаких «например», «как в xxxx» или «и.т.д» к старту лучше не оставлять
Я всегда опасаюсь, когда заказчик говорит «ну и заполнение товаров, и стандартные функции». Там в несколько раз может быть разница по объему работ. Я знаю что то, что написано действительно можно сделать за несколько часов, но чтобы отсатисфачить реального заказчика, времени уйдет больше
Сорри, если это выглядело как предложение сделать сайт.
Просто тут упущен момент, в изучении ценовой политики ( я немного утрирую уровни)
— Студент, который не знает ничего кроме CMS и немного PHP запросит одну сумму
— Профи, который знает и Ruby и PHP и Python запросит другую сумму
— Посредник, который потом отдаст исполнителю — еще больше
— Студия — еще больше.
Более того, цена будет зависеть от того, из какого региона исполнитель.
Значит ли это, что узнав сумму у студента который сделает на PHP вы сможете сделать за эти деньги сайт у профи? Я думаю нет. Сможете ли вы у студента заказать сложный сайт на RoR? Вряд ли.
Фишка в том, что я видел на PHP магазины и за 400k, а на этапе «хочу магазин» вилка объема работ может быть в несколько раз. Поэтому имеет смысл пожалуй сравнивать все таки конкретное ТЗ, а не то, что каждый исполнитель, имеющи опыт заказов определенной сложности, домыслит при виде «сколько стоит интернет магазин»
Есть gem magic_encoding, который пихает везде где нужно такие комменты.
И — я не люблю делать из RoR то, от чего я ушел из JavaEE и юзать i18n без причин, просто создавая себе геморой.
- Если типизация - проблема - можно просто использовать TypeScript, тем более в мире RN это сейчас вполне мейнстрим.
- Facebook использует RN в своих проектах.
И вот тут основная проблема - они пилят его для себя, сами используют и сами определяют роадmap, исходя из своих потребностей, просто иногда отдавая иногда что-то в OpenSource, а Flutter - это прям продукт.