Phonegap и Cordova разные проекты, с отдельным развитием. Cordova продолжает, Phonegap остановился.
Веб-разработчики (фронтендеры), профессионалы в PWA, работающие со сложными веб-приложениями, с большой кодовой базой (конечно на TS или JS + Flow), FLUX-архитектурой, кэшированием в локальном хранилище, знакомыми с процессами рендеринга HTML, CSS в браузерах, которые понимают, что мобильные веб-сайты это не просто схлопнутый Bootstrap.
Да, они могут что-то сделать на платформах типа Cordova/Phonegap.
А «хуяк-хуяк и в продакшен», не обижайтесь, используется везде, не только в программировании, со всеми вытекающими.
Интересный кейс. Уже встречал подобное несколько раз, а один — даже немного поучавствовал но только в качестве консультанта, в разработку не погружался.
Всегда рассматривал PG + postgrest как быструю реализацию для несложных проектов сервер-клиент. Postgrest тут, как простой и стабильный веб-сервер для прямого маппинга таблиц PG в RESTful API. Преимущество в том, что по сути выкидываем из 3-х звенной архитектуры, звено с сервером приложений. Недостаток — риск в том, что при определенных задачах формирования данных для клиента, мы переносим бизнес-логику в звено с СУБД.
Вот задачу связанную со структурой данных должен решать отличный профессионал, который прекрасно понимает и реляционные модели и иерархические, знать SQL, NoSQL и т.д. Иначе будет боль и разочарование. Это как от SQL к NoSQL и видишь большие глаза SQL-разработчика, который не понимает, что теперь имя юзера хранится чуть больше, чем везде где только можно, а не в одной таблице.
Вопрос, у вас структура данных учитывает особенности такой архитектуры с PG и JSON? Насколько она очевидна и проста?
Ну нет, какая мода? Придумали что-то для решения задачи, использовали в рабочих проектах и… на этом не остановились. Решили поделиться, сделали документацию, открыли код, создали коммьюнити, все это выросло в новую специализацию с рабочими местами (с неплохой оплатой). Но и на этом не остановились. А мы просто наблюдаем и решаем, использовать или нет.
Если показалось не «вау», значит потребности просто нет.
Хорошее уточнение про зависимости. Тут автор похоже автоматически, по привычке использует паттерн, при котором функция остаётся неизменной, но только при неизменных зависимостях (пропсах).
По useCallback. Я тоже подумал, что автор будет где-то ещё использовать метод. И ещё момент: если компонент ре-рендерится, то useCallback не статичен, так?
С начала 2020-го постепенно, осторожно перевожу существующие проекты на хуки, но еще пока рискую начинать использовать их в новых (больше из-за того, что начинает страдать скорость разработки). И пока остается redux с коннекторами, еще более-менее приятно работать с глоб. стейтом. Но когда пытаюсь избавиться от него в пользу контекста с селекторами (хуками), то сталкиваюсь с тем, что вы написали выше: длинный перечень useCallback/useMemo. Пытаюсь скомпоновать. Плохо удается.
Продолжаю лопатить статью за статьей, читаю рецепты, копаюсь в шаблонах сторонних проектов. Ваш коммент заставляет задуматься.
Для примера, возьмем тот же JS и типизацию. В самом простом варианте, мы начали разработку веб-приложения. И, да, проще создать index.html и app.js и начать разрабатывать. И, да, не просто начать разработку на TS: надо настроить среду, WebPack, инсталлировать кучу зависимостей и вспом. библ. Но для кого это не просто? Для бегиннера? Да, для него это будет не просто. А куча зависимостей и вспом. либ, не решают далее массу задач, для которых пришлось бы самому писать код? И не решают ли они задачи совместной разработки?
И вот мы проект развивается и мы имеем наш index.html и спагетти в app.js. Я согласен, что не нужно палить из пушки по воробьям, но попадать в ловушку «время/качество» тоже не стоит. Проф. за меньшее время со сложным инструментарием сделает то, что средний спец. с небольшим набором инструментов. Ну, тут уже вопрос цены. Да, можно рискнуть качеством.
Продуктивность должна быть качественной. Когда разработчик спрашивает «быстрее или качественнее» задумайтесь о его проф. уровне. Он не обязательно плохой разработчик, но явно не владеет сложными инструментами. И это чаще поправимо.
Работа с интеропом одна из задач, но правильнее было бы сказать, что решаются задачи удобного взаимодействие с другими средами исполнения или API-интерфейсами (интероп часть этих определений).
Не подумайте, что «удобство» в данном смысле заменяет «правильно». Любое взаимодействие нуждается в проверке (и типизации, чаще всего).
Тем не менее, например в C# (начиная с 4-й версии), добавили динамическую типизацию, что продиктовано скорее необходимостью и решает определенные задачи при разработке. Автор немного преуменьшает роль дин. типизации.
О списках спорить не буду, тем более нагруженный рендер позиции может быть причиной тормозов и трудно представить, что его можно вынести за мост на нативную сторону. Правда, в документации RN указывается на асинхронный рендер и связанное с этим поведение и выгоды (пробелы при очень быстром скролле, сам скролл без тормозов).
Основной поток JS должен заниматься запросами и бизнес логикой, перед этим запустив анимацию. Если анимация нативная (Animated), то ей все равно, чем занимается основной поток JS. Запустите анимацию с usingNativeDriver и заблокируйте основной поток JS и увидите, что анимация не прерывается.
С Shadow DOM уже заинтересовали и тут вопрос — React Native использует Shadow DOM? Это же не React в среде DOM, как тогда? Если есть пруфы буду рад почитать.
Мы можем миновать state в узких местах и избежать сравнивания дерева, React Native дает инструменты для этого.
Понять из-за чего происходят тормоза при дозагрузке данных на Android, поможет только отладка и счетчики произв. Уверен, что при передаче анимации и запросов в БД на нативную сторону проблема начинает проявляться уже там. И тут надо подумать о принудительных задержках, например, дождаться запуска анимации, затем делать запросы и т.д.
Буду благодарен, если поделитесь ссылкой на приложение :)
Насколько я знаю из собственного опыта, баги на разных устройствах и разных версиях платформ обнаруживаются не только в библ. для RN/Flutter но и в нативной разработке и тут даже разраб. под отдельную платформу приходится туго (больше касается android). Возникает дилемма: наполнить код if/else для каждой версии или слегка «забить» на пользователей старых версий. В кроссплатформ. разработке аналогично поступают и разработчики библ. Ну, обобщая — это общий вопрос.
Разница в производительности? Логика, UI? На вопрос «Чем больше анимированных элементов на экране, тем ниже производительность» попробуйте сами ответить с оглядкой на то, что в итоге происходит рендеринг нативных компонент, не важно RN/Flutter или сборка со среды разработки Android Studio / XCode. Ну, полно сравнительных тестов и результат таков, что даже RN где-то выигрывает (при этом процент прироста настолько мал, что можно пренебречь). Смысла нет сравнивать нативные UI, один из которых построен декларативно, другой — «нативно» drag&drop в среде разработки.
Автор с первых строк не совсем корректно сравнивает нативную разработку и ее преимущества с широкой экосистемой кросс-платформенной разработки. И это печально.
Сразу разделите гибридные решения на основе WebView (Phonegap/Cordova, Ionic) от гибридных решений типа React Native, Flutter, Xamarin. Это технически абсолютно разные направления. Одинаковые только концептуально (один код — разные платформы).
Во вторых — сервер здесь не при чем. Приложения нативные или гибридные — все они работают offline. Это изначально условие для любых приложений, которое может нарушаться только концептуально (например, Инстаграмм или Фейсбук или остатки на складе в реальном режиме времени).
Итак, для начала стоит ответить на простой вопрос: в чем отличие <View /> в React Native от нативного UIView в iOS и View в Android? (подсказка: Ни в чем. <View /> трансформируется в UIView или во View в зависимости от платформы)
Поэтому сравнивать UI сделанный в React Native с UI сделанный в XCode или Android Studio нельзя. Это одно и тоже (по качеству, производительности, кастомизации). И это касается всех элементов. Нет, правда всех. React Native даже Date Picker отображает, путем вызова конструктора нативного picker для каждой платформы. А Animate API, direct manipulation, useNativeDriver? Удивительно, но на уровне платформ разницы тоже нет. Да, создание компонента прилетело из декларативного описания, но компонент-то нативный и анимация тоже. И еще вопрос на засыпку, кто сегодня не выдумывает колеса или не использует решения с декларативным описанием интерфейса, вместо drag and drop в среде разработки?
Если копнуть глубже, там где требуется нативный код, то да — надо писать исключительно для платформы, нативно. Когда мы говорим «глубже», это глубже, чем камера, файловая система, отпечатки пальцев, карты. Короче это не простой доступ к hardware, с которым ни у React Native ни у Flutter вопросов нет. Даже Phonegap/Cordova давно решили эти проблемы с нативными плагинами (с переменным успехом и стабильностью), но не решили проблемы с производительностью WebView.
Ни RN ни Flutter не считают прямой доступ к нативному API за bad practices там, где это действительно необходимо и дают все инструменты для этого, не ограничивая. Зато reusable-код штампованной бизнес-логики впечатляет настолько, что даже <Button /> и <ButtonIOS /> на каждом шагу не очень расстраивают. Даже OpenGL в React Native и нативной разработке — это одна библиотека и частота кадров будет зависеть только от того, как быстро работает логика в каждом фрейме (и вот только здесь-то JS в виртуалке может уступить нативному коду).
Приведите один пример из своего опыта, где «глубже» это действительно что-то за рамками простого доступа hardware, карт? Может быть, сложная обработка изображений за границами популярных фильтров? Про UI уже сказал выше, повторюсь — не сравнивайте, это одно и тоже.
Веб-разработчики (фронтендеры), профессионалы в PWA, работающие со сложными веб-приложениями, с большой кодовой базой (конечно на TS или JS + Flow), FLUX-архитектурой, кэшированием в локальном хранилище, знакомыми с процессами рендеринга HTML, CSS в браузерах, которые понимают, что мобильные веб-сайты это не просто схлопнутый Bootstrap.
Да, они могут что-то сделать на платформах типа Cordova/Phonegap.
А «хуяк-хуяк и в продакшен», не обижайтесь, используется везде, не только в программировании, со всеми вытекающими.
Всегда рассматривал PG + postgrest как быструю реализацию для несложных проектов сервер-клиент. Postgrest тут, как простой и стабильный веб-сервер для прямого маппинга таблиц PG в RESTful API. Преимущество в том, что по сути выкидываем из 3-х звенной архитектуры, звено с сервером приложений. Недостаток — риск в том, что при определенных задачах формирования данных для клиента, мы переносим бизнес-логику в звено с СУБД.
Вот задачу связанную со структурой данных должен решать отличный профессионал, который прекрасно понимает и реляционные модели и иерархические, знать SQL, NoSQL и т.д. Иначе будет боль и разочарование. Это как от SQL к NoSQL и видишь большие глаза SQL-разработчика, который не понимает, что теперь имя юзера хранится чуть больше, чем везде где только можно, а не в одной таблице.
Вопрос, у вас структура данных учитывает особенности такой архитектуры с PG и JSON? Насколько она очевидна и проста?
Если показалось не «вау», значит потребности просто нет.
Хорошее уточнение про зависимости. Тут автор похоже автоматически, по привычке использует паттерн, при котором функция остаётся неизменной, но только при неизменных зависимостях (пропсах).
По useCallback. Я тоже подумал, что автор будет где-то ещё использовать метод. И ещё момент: если компонент ре-рендерится, то useCallback не статичен, так?
Продолжаю лопатить статью за статьей, читаю рецепты, копаюсь в шаблонах сторонних проектов. Ваш коммент заставляет задуматься.
И вот мы проект развивается и мы имеем наш index.html и спагетти в app.js. Я согласен, что не нужно палить из пушки по воробьям, но попадать в ловушку «время/качество» тоже не стоит. Проф. за меньшее время со сложным инструментарием сделает то, что средний спец. с небольшим набором инструментов. Ну, тут уже вопрос цены. Да, можно рискнуть качеством.
Не подумайте, что «удобство» в данном смысле заменяет «правильно». Любое взаимодействие нуждается в проверке (и типизации, чаще всего).
Не превращайте Хабр с сообщество тех-нытиков.
Основной поток JS должен заниматься запросами и бизнес логикой, перед этим запустив анимацию. Если анимация нативная (Animated), то ей все равно, чем занимается основной поток JS. Запустите анимацию с usingNativeDriver и заблокируйте основной поток JS и увидите, что анимация не прерывается.
С Shadow DOM уже заинтересовали и тут вопрос — React Native использует Shadow DOM? Это же не React в среде DOM, как тогда? Если есть пруфы буду рад почитать.
Мы можем миновать state в узких местах и избежать сравнивания дерева, React Native дает инструменты для этого.
Понять из-за чего происходят тормоза при дозагрузке данных на Android, поможет только отладка и счетчики произв. Уверен, что при передаче анимации и запросов в БД на нативную сторону проблема начинает проявляться уже там. И тут надо подумать о принудительных задержках, например, дождаться запуска анимации, затем делать запросы и т.д.
Буду благодарен, если поделитесь ссылкой на приложение :)
Разница в производительности? Логика, UI? На вопрос «Чем больше анимированных элементов на экране, тем ниже производительность» попробуйте сами ответить с оглядкой на то, что в итоге происходит рендеринг нативных компонент, не важно RN/Flutter или сборка со среды разработки Android Studio / XCode. Ну, полно сравнительных тестов и результат таков, что даже RN где-то выигрывает (при этом процент прироста настолько мал, что можно пренебречь). Смысла нет сравнивать нативные UI, один из которых построен декларативно, другой — «нативно» drag&drop в среде разработки.
Сразу разделите гибридные решения на основе WebView (Phonegap/Cordova, Ionic) от гибридных решений типа React Native, Flutter, Xamarin. Это технически абсолютно разные направления. Одинаковые только концептуально (один код — разные платформы).
Во вторых — сервер здесь не при чем. Приложения нативные или гибридные — все они работают offline. Это изначально условие для любых приложений, которое может нарушаться только концептуально (например, Инстаграмм или Фейсбук или остатки на складе в реальном режиме времени).
Итак, для начала стоит ответить на простой вопрос: в чем отличие <View /> в React Native от нативного UIView в iOS и View в Android? (подсказка: Ни в чем. <View /> трансформируется в UIView или во View в зависимости от платформы)
Поэтому сравнивать UI сделанный в React Native с UI сделанный в XCode или Android Studio нельзя. Это одно и тоже (по качеству, производительности, кастомизации). И это касается всех элементов. Нет, правда всех. React Native даже Date Picker отображает, путем вызова конструктора нативного picker для каждой платформы. А Animate API, direct manipulation, useNativeDriver? Удивительно, но на уровне платформ разницы тоже нет. Да, создание компонента прилетело из декларативного описания, но компонент-то нативный и анимация тоже. И еще вопрос на засыпку, кто сегодня не выдумывает колеса или не использует решения с декларативным описанием интерфейса, вместо drag and drop в среде разработки?
Если копнуть глубже, там где требуется нативный код, то да — надо писать исключительно для платформы, нативно. Когда мы говорим «глубже», это глубже, чем камера, файловая система, отпечатки пальцев, карты. Короче это не простой доступ к hardware, с которым ни у React Native ни у Flutter вопросов нет. Даже Phonegap/Cordova давно решили эти проблемы с нативными плагинами (с переменным успехом и стабильностью), но не решили проблемы с производительностью WebView.
Ни RN ни Flutter не считают прямой доступ к нативному API за bad practices там, где это действительно необходимо и дают все инструменты для этого, не ограничивая. Зато reusable-код штампованной бизнес-логики впечатляет настолько, что даже <Button /> и <ButtonIOS /> на каждом шагу не очень расстраивают. Даже OpenGL в React Native и нативной разработке — это одна библиотека и частота кадров будет зависеть только от того, как быстро работает логика в каждом фрейме (и вот только здесь-то JS в виртуалке может уступить нативному коду).
Приведите один пример из своего опыта, где «глубже» это действительно что-то за рамками простого доступа hardware, карт? Может быть, сложная обработка изображений за границами популярных фильтров? Про UI уже сказал выше, повторюсь — не сравнивайте, это одно и тоже.