Comments 20
Хоть убейте не понимаю зачем?
Что мешает тупо написать натив?
Надежностью и не пахнет, собрано как-то из непонятно чего, как-то работает, ну и ладно + миллион узких мест.

Что мешает тупо написать натив?

Отсутствие знаний Java/Objective-c и наличие таковых с Js/React?
Да бросьте Вы, элементарная лень и нежелание выходить за пределы своего динамического «у меня и так работает» мирка. Сегодня приложения для Android пишут на Kotlin и ничего, я повторяю, ничего сложного в нем нет. Я вот только драйвера разрабатывал или еще какие низкоуровневые службы Windows и я написал нативное приложение для личного использования за два месяца (только на выходных им занимался). На iOS все используют Swift и он мало чего общего имеет с Objective-C. Я в iOS разработку глубоко не нырял, но девушка иногда с ней играется и все у нее легко и просто. React и JS нужны для web-разработки. Зачем подметать ломом?
Затем что можно получить приемлемый результат на обоих платформах за намного меньшее время, которое деньги. Плюс опыт с JS фронтом уменьшает время старта новых людей, что тоже деньги. Проекты без особых нативных требований отлично делаются на RN, проверено на практике.
С другой стороны, всегда есть риск, оказаться в «вакууме» когда готовых решений просто нет.

Вот это и мешает :)
Я ни в коем случае не против использования библиотек или чужих наработок, но у этой формулировки совсем другой посыл.
Codepush. Чет про него все молчат всегда, а это самая главная фича RN, после которой я окончательно зауважал RN.

Codepush работает под RN и Cordova. Почему Cordova не фонтан надеюсь не надо объяснять, так что RN.

Long live RN.
У меня вообще версия 0.57 не работает, все сделал по канону но выскакивает ошибка, гугл молчит.
Главный недостаток RN это то что он обновляется в раз пол года, такими темпами версия 1.0 будет в 2038 году.
Понимаю боль автора. Просто несколько заметок которые я писал для себя около года назад, чтобы не забыть (дают прочувствовать атмосферу):
=======

иногда если не билдится, можно попробовать почистить содержимое \android\.gradle
и после этого перезапустить react-native run-android пару раз.
========
Если не билдится release, прежде чем что-то менять, попробовать раз пять перезапустить процесс
=======
если cannot unzip… то надо сделать:
android\gradlew.bat clean
=========
Если при попытке задеплоить приложение на смартфон там вылезает Error: Requiring module «NativeModules» (а на эмуляторе всё ок) — причина неизвестна, но возможно как-то связана со служебным адресом в строке wsClient = new SubscriptionClient(`ws://10.0.2.2:3002/subscriptions`,…
Временное решение — забить на отладку и задеплоить release. С ним всё ок.
Кто-то советовал удалить node_modules и заново сделать npm install. Не пробовал.
=========
решение проблемы с «ERROR EPERM: operation not permitted, lstat… » после react-native run-android:
react-native run-android, as soon it opens the packager, kill it, wait for the BUILD SUCCESSFUL message to appear, then node node_modules/react-native/local-cli/cli.js start
=======
(это всё под Win7).

Ну и далее в таком духе (включая всякие тонкости, где можно и где нельзя вставлять в каких-то конфигах пробелы, можно или нельзя кавычки использовать и т.п.). Сильно напрягает, что многие проблемы плохо воспроизводятся и решаются кучей совершенно разных способов (судя по советам столкнувшихся с ними). При этом у кого-то срабатывают одни советы, у кого-то другие, а у кого-то никакие не срабатывают :)
Несмотря на всё это (можно постепенно привыкнуть) вещь действительно хорошая и, при определённых условиях, приложение с точки зрения пользователя ощущается как нативное.
Спасибо за статью. У Вас продублировалось «Поначалу было двоякое ощущение» и «Шифрование из коробки»
За статью — спасибо.
P.S.
Поначалу было двоякое ощущение, мол, никакой тебе ORM, реально нет sql, запись ведется только внутри callback. Непривычно и странно, особенно для веб-разработчика родом из PHP, выросшего на ActiveRecord и Doctrine.

Абзац продублировался.
Ubuntu 12.6


Это всё было в каком году?

С его помощью можно относительно быстро собрать прототип приложения, отработать структуру и юзабилити.


То есть потом придётся переписывать?

Решили запилить RN компонент (дающий 2/3 функционала) в xamarin проект в надежде сократить время разработки второй платформы. Сделали iOS, прострадали лишнюю неделю минимум на отлов багов и придумывания взаимодействия реакта и xamarin. Планировали отыграться на android, но в итоге потратили еще недели две на интеграцию и отлов багов в android, связанных со взаимодействием RN компонента и натива.
Вобщем, в целях саморазвития и вообще — интересно. С точки зрения бизнеса — крайне сомнительно. Как минимум, если компонент будет использоваться только в одном проекте.

Хорошо бы еще услышать лучшие практики/советы/инструменты по продуктивности в RN.

Например до меня не сразу дошло, что можно в live режиме менять UI(CSS) в React Native Debugger без ребилда приложения.

На днях была задача — как закачать на свой сервер выбранный из девайса файл. Еще решаем, пока нет представления как лучше это сделать. Посоветуй лучший вариант для этого если в курсе.

Сам работаю с RN уже как 2 месяца. В целом доволен.
В первой версии все бегало по сокетам на Meteor.JS Файлы закачивались средствами метеора.

Сейчас, когда приложение стало самостоятельным (без серверной части), есть только обертка на Google.Drive (react-native-google-drive-api-wrapper )

Но там все стандартно — обычный fetch

код внутри враппера:

fetch(
   `${uploadUrl}?uploadType=multipart`, {
       method: "POST",
       headers: GDrive._createHeaders(
           `multipart/related; boundary=${this.params.boundary}`,
           body.length
       ),
       body
   }
);


Косяк был только в одном месте — из файловой системы (react-native-fs) бинарный файл приходил только в base64. Как выяснилось, Google.Drive спокойно принимает этот формат. Но для его отправки на сервера просто нужно было указать `Content-Transfer-Encoding: base64\n\n`; в body запроса. Насколько помню, в компоненте react-native-google-drive-api-wrapper это учли и код поправили.
Присоединяюсь к флешмобу.

Делаю кросс-платформенное приложение-плеер на React Native. Сначала сделал работу со звуком на open-source компонентах. Всё работало. Даже информация о треке выводилась в систему через компонент, оборачивающий MPNowPlayingInfo и MediaSession Metadata.

Но плеер подразумевает работу в фоне большую часть времени. В iOS это решается через соответствующий флаг в Capabilities. В Android же единственный верный путь, насколько я понял, – это отдельная служба. Портирую сейчас логику на Java, используя код из тех самых open-source компонентов. Хорошо хоть UI уцелел.
Синхронное выполнение асинхронной функции

Пожалуйста, не говорите таких ужасных вещей :) Код, вызываемый с await — остается асинхронным, он неблокирующий, это принципиально важно

 const setupBackupFolders = async (init = false) => {
   // some stuff there...
   await RunSomeAsyncFuncInSyncMode(foo, bar)
   RunFuncAfter(bar)
 };
setupBackupFolders();
doBaz();


В этом случае doBaz может выполниться раньше, чем RunFuncAfter. И еще, если setupBackupFolders или RunSomeAsyncFuncInSyncMode бросит исключение (в виде reject), оно «потеряется», будет UnhandledPromiseRejection, код продолжит выполняться. Если это сделает синхронная функция doBaz, приложение упадет (если считать что нет обработчика в вызывающем коде).

И да, для метода класса React.Component это работает тоже. (в справке React, ReactNative об этом умалчивают, хотя это само собой подразумевается).


Само собой это подразумевается именно потому, что async/await следует воспринимать ни в коем случае не как «sync mode» для асинхронных функций, а лишь как синтаксический сахар над промисами, которые следует воспринимать как синтаксический сахар над коллбэками. Строго говоря это не совсем так, но лучше думать об async/await именно в таком ключе, ни в коем случае это не «синхронный способ выполнить асинхронный код».
монолитный и тяжелый moment, отлично заменяется на модульный date-fns.
Only those users with full accounts are able to leave comments. Log in, please.