в любом случае, в будущем, я вижу Флаттер как альтернативу одновременно таким вещам как РН и Електрон, только с лучшей реализацией. другое дело, что этот инструмент больше для нативщиков предназначен, чем веб-разработчиков

с анимацией в РН все плохо ?

нет, не так. Для веберов порог вхождения ниже, и то при условии, что они на реакте писали. Но все это заканчивается в тот момент, когда нужно переставить писать приложения использую только готовые компоненты и либы

FB 64битку сделали ?

FB 64битку сделали ?

Ребят если сайт на Vue + laravel, интеграция через api подойдёт на RN?

FB 64битку сделали ?

Сделали. Она не в stable ещё.

видел в истории чата твой комментарий насчет RN Fabric реархитектуризации. он был не очень положительным. твое впечатление насчет Фабрика не поменялось?

Нет. Но это всё равно лучше, чем флаттер (если речь про это)

Можешь аргументировать? Просто интересно мнение человека, который за этим следит и понимает происходящее

18го Vue что то новое готовит

Можешь аргументировать? Просто интересно мнение человека, который за этим следит и понимает происходящее

И вот так стоит на 100%... В эмуляторе не открывается....

он то гибридный, но джс бридж выглядит как какой-то костыль

Это плюсы RN, которые flutter не реализует (по крайней мере я при просмотре документации и чтении кода не понял как это сделать): 1. Возможность писать нативно при желании. Можно только несколько экранов сделать на RN, а несколько нативно. (Это не значит, что я так буду делать, это значит мне нужна потенциальная возможность так сделать. Это "подушка безопасности", если что-то не реализуется на JS, я это могу написать нативно, пусть несколько раз, по кол-ву платформ, но по крайней мере могу.) 2. Возможность встроить нативные виджеты в RN View. (То же самое, только в меньшем масштабе) 3. В RN у меня есть возможность расширять JS api быстрыми синхронными вызовами (по крайней мере теоретическая), flutter общается с нативом только через очередь и изменить это у конечного программиста шансов нет. 4. React (jsx на самом деле) всё таки дает очень большую гибкость в определении того, что декларативно, а что нет и где код лежит. 5. В RN работая с нативным кодом, я использую наработанные много лет технологии, надежные и хорошо изученные. То же можно сказать о JS, если не кидаться сразу использовать экспериментальные фичи ))) 6. Вот у нас сейчас есть шареный между вебом и мобилкой код. В вебе это 42% от всего приложения. В мобилке около 35%. это не компоненты, это api, модели данных, вспомогательные классы. Я слабо представляю как нормально код на dart использовать в веб, не цельно, а как отдельные библиотеки. 7. А и ещё. Я сейчас имею возможность отказаться от использования раздражающих меня вещей (типа setState в React, redux) и использовать то, что мне удобно (mobx). Теперь вопрос, есть ли у меня такая гибкость в Flutter? Из документации я понял, что нет.

Почему JS бридж костыль? Это как раз его основная фича, что это JS. Ты для мобилок пишешь почти как для веба. Те же зависимости, react, state managers, ws, axios. На flutter у тебя так уже нельзя.

это и фича и недостаток одновременно

Почему недостаток, можно аргумент?

Почему недостаток, можно аргумент?

Товарищи, есть react-navigation tab navigator - при нажатие на таб нужно показать модалку и после подтверждения на ней действия, показать открытый таб, как такое можно реализовать?:) 🤔

Товарищи, есть react-navigation tab navigator - при нажатие на таб нужно показать модалку и после подтверждения на ней действия, показать открытый таб, как такое можно реализовать?:) 🤔

Товарищи, есть react-navigation tab navigator - при нажатие на таб нужно показать модалку и после подтверждения на ней действия, показать открытый таб, как такое можно реализовать?:) 🤔

🤔на него и смотрю,но вот хз как вызвать модалку компонентную, а не простой alert

Насчёт 7, если мы говорим о глобал стейт менеджменте, то у флаттера очень много решений, и пока не понятно какое лучше применять: scoped model, bloc, redux, mobx (последний кстати официальной командой поддерживается) Насчёт 6, у них же есть angular dart, поэтому теоретически тоже можно шерить бизнес-логику

Вот я в их faq залез и вижу там: Q. Should I use Angular or Polymer? Use AngularDart. Polymer Dart is no longer supported and is likely to break in Dart 2. At Flutter Live we announced Hummingbird as an experimental way to write web applications. We’ll let you know when Hummingbird is ready to use. Скажите, а оно мне надо учить и тем более использовать в реальных проектах технологию, которая в любой момент лишится поддержки?

скорее всего с появлением Hummingbird интерес к АнгулярДарту действительно потеряется

Ребят, я правильно понимаю, что UI state лучше хранить в обычном стейте, а не в редаксе?

Ребят, я правильно понимаю, что UI state лучше хранить в обычном стейте, а не в редаксе?

Зависит, но чтобы не обмазываться derived state лучше заранее думать как все перенести в редакс

А что значит derived state?

Когда стейт от пропсов зависит

Ребят, а я могу обойтись без RCTViewManager враппера на ios для нативного компонента?

тенденция показывает, что выживает джс) но я думаю эти технологии будут со-существовать, просто реакт нейтив будет использоваться для аппчиков попроще. все сейчас в руках фейсбука, у них больше комьюнити, больше adoption-a со стороны крупных компаний и надеюсь, что появление такого конкурента как флаттер, только подтолкнет их на какие-то новые свершения

Я так понимаю, это не оч? Я читал статью, где говорили, что надо юзать редакс + полностью стейтлесс компоненты

Эмм... а как? Он определяет какой view и shadow view инстанцировать (ну и ещё props). В принципе можно попробовать написать один универсальный, но думаю, проще всё же здесь архитектуре следовать. (Они же их ещё интроспектят как раз на прдмет props из core)

так вот я и спрашиваю как 🙂 а то у меня вьюха супер простая, для нее этот мэнеджер будет только view методом и объявлением пропс)

Тогда я думаю всё таки лучше не пытаться без него обойтись ) Он маленький там и так всё в макросы обернуто, так что почти декларативный. И это хорошо, когда есть объект с временем жизни бриджа и четкой зоной ответственности. Больше эту ответственность некуда вынести.

В блоге реакта есть статья, кейворды you probably don't need derived state

т.е. даже всякие стейты отображения модалок надо на редаксе фигачить?

Когда стейт от пропсов зависит

Да, есть такая проблема, тем более когда componentWillReceiveProps деприкейнтнули, а getDerivedStateFromProps так не работает. Но не тащить же такую мелочь в redux? Нарушается независимость мелких компонентов.

Да, есть такая проблема, тем более когда componentWillReceiveProps деприкейнтнули, а getDerivedStateFromProps так не работает. Но не тащить же такую мелочь в redux? Нарушается независимость мелких компонентов.

это нормально. Стейт нужен только для визуализации компонентов, а не для работы с данными. Хранить глобальные состояния в СМ это нормально. Все сразу становится прозрачно

Пипл, как можно делать реквест на сервер, но что бы не ждать ответа от него? Мне надо делать около 3-4 реквестов по нажатию одной кнопки, но их результат грубо говоря не важен. Это сокетами реализуют?

не обрабатывай ответ)

Так слушатель же все-равно создается?

а как можно глобально снести expo cli?