React Native довольно новая технология которая с первого взгляда кажется серебряной пулей для многих начинающих разработчиков. В статье я хочу развеять этот миф и рассказать что же именно не так с React Native и почему стоит подождать прежде чем его использовать.И так по порядку, я Full-stack разработчик. Использую последний стандарт javascript на фронетнде и бэкенде. Опыта разработки мобильных приложений нет, но есть 5 лет опыта разработки высоконагруженных проектов на node.js, asp.net mvc. Опробовать React Native я решил при создании простого мобильного приложения — клиента LessPass для Android.
Немного о LessPass. Это приложение — менеджер паролей. Оно не сохраняет пароли, а каждый раз рассчитывает пароль с помощью хитрой хеш-функции, которая принимает на вход адрес сайта, ваш логин и мастер пароль. Таким образом, MVP версия приложения — это всего лишь один экран, с тремя полями ввода и одной кнопкой — сгенерировать пароль. Ну вот, вводные закончены, перейдем собственно к программированию.
Верстка главного экрана
Верстка в React Native похожа на то что сейчас есть в вебе. Из основных требований — знание flexbox т.к. на нем основан grid мобильного приложения. Для того чтобы использовать в своем приложение красивые компоненты необходимо поставить React Native Elements. Отличия от обычной браузерной верстки существуют, пусть не значительные, но они есть, например, иногда у элемента нет свойств которые ожидаешь у него увидеть. Нет привычных дивов и спанов. Часто приходится читать React Native Components Guide чтобы понять что от чего наследуется и какие фичи есть в конкретной платформе. Минусы небольшие, с ними можно мириться.
Пример верстки на React Native:
<View style={styles.inputView}>
<FormInput
inputStyle={styles.inputStyle}
placeholder={'Site'}
keyboardType={'url'}
underlineColorAndroid = 'transparent'
onChangeText={(value) => this.setState({...this.state, site: value})}
value={this.state.site}
/>
</View>Бизнес логика
Бизнес логика моего приложения состояла ровно из одной функции — подсчет пароля по заданным значениям (адрес сайта, логин и мастер пароль). Более того эта функция уже была реализована в node.js библиотеке lesspass. Я решил сделать привычный
npm install lesspass. Библиотека не заработала, т.к. для ее работы требуются базовые классы node.js такие, как Buffer и Stream. В голову сразу пришел browserify, который умеет делать браузерные версии библиотек требующих node.js. Но в React Native невозможно его использование. В итоге я переписал функцию использовав cryptojs для шифрования взамен cryptobrowserify из-за этого существенно упала производительность генерирования пароля (60 секунд против 100 мс). Ключевой момент в этой истории следующий — вы не можете использовать написанные миллионы библиотек в React Native. Да, существует вероятность что они заработают, но она мала, и не стоит на это рассчитывать. Что же делать если нужная библиотека не запускается? Попробовать найти библиотеку которая не использует node.js у себя внутри. Если же такой библиотеки нет или ее производительность вас не устраивает, то необходимо написать native компонент для платформы под которую вы разрабатываете. Написание native компонентов, по моему мнению, перечеркивает все плюсы React Native для программиста незнакомого с мобильной разработкой.
Отладка
Процесс отладки в React Native сделан великолепно. Многие Android разработчики мечтают о hot-reloading который уже есть в React Native. Все четко и понятно, отличий от обычной браузерной отладки javascript практически нет. Порадовало наличие perfomance tools.
Прочее
Общее ощущение от библиотек для React Native у меня отрицательное. За небольшим исключением, все они очень молодые и нестабильные. Установка любой из них подразумевает под собой правку Android Build файлов. Например, я так и не нашел адекватной библиотеки для задания splash-screen. Библиотека для создания share-menu не работает в последней версии React Native.
Итоги и выводы
По моему мнению, React Native не годится в текущем его состоянии для разработки мобильных приложений. Основной фактор — отсутствие качественных библиотек и детские болезни самого React Native. Если вам необходимо написать сложное и быстрое мобильное приложение используйте native инструменты платформы, если же приложение простое и не требует сложных взаимодействий с платформой — используйте Cordova. Именно Cordova и была выбрана как основная технология для мобильного приложения LessPass. Создание такого приложения заняло 30 минут, производительность приемлема.
> Исходный код моего приложения на React Native вы можете найти на GitHub
Спасибо за внимание, в комментариях поделитесь своим опытом разработки приложений на React Native со ссылками на готовые проекты.
Комментарии (32)
bjornd
20.01.2017 17:35+9Автор не обижайтесь, но получилось примерно следующая ситуация.
Так ли хорошо микроскоп?
Микроскоп довольно новая технология, которая с первого взгляда кажется серебряной пулей для многих начинающих забивателей гвоздей. И так по порядку, я — закручивальщик шурупов широкого профиля, опыта забивания гвоздей до этого не было. Опробовать микроскоп я решил для забивания гвоздя сотки в березу растущую у нас во дворе. Береза красивая, высокая и зеленая. На этом вступительная часть закончена, перейдем собственно к забиванию.
Подготовка у забиванию гвоздей микроскопом почти такая же как и при закручивании шурупов шуруповертом. Главное правильно покрутить управляющие элементы, крутятся они примерно так же, так что больших проблем нет, хотя есть нюансы. Логика забивания гвоздя заключалась в одном простом действии — нанесении одного сильного удара по гвоздю микроскопом. Пару раз я промахнулся и по гвоздю не попал, пару раз попал, но гвоздь погнулся, в итоге взял камень лежащий рядом и загнал гвоздь в дерево по самую шляпку.
По моему мнению, микроскоп не годится в текущем его состоянии для забивания гвоздей. Основные факторы — плохо лежит в руке и недостаточно тяжелый. По итогу если вам нужно закрутить шуруп используйте шуруповерт, если хотите срубить дерево то тут подойдет топор. С топором дерево удалось повалить за 30 минут.
sochix
20.01.2017 17:36Спасибо за комментарий. Расскажите, в каком проекте вы бы использовали React Native? Потому как я не увидел его ниши
bjornd
20.01.2017 17:49React Native позволяет создавать проекты которые обладают несколькими важными качествами. Во-первых на выходе получаются приложения которые выглядит и работают как нативные. Почему нативные приложения лучше объяснять думаю не стоит. При этом основную логику отображения и бизнес-логику дублировать не приходится как в схеме с независимой кодовой базой для каждой платформы. Критичные же для производительности или с точки зрения платформы вещи, как-то сложные вычисления, получения GPS-координат устройства или отображение splash screen'а, придется реализовать нативно для каждой платформы.
В вашем случае действительно не было никаких предпосылок использовать React Native. Писали вы только для Android, а большая часть функционала приложения состояла из сложных вычислений.sochix
20.01.2017 17:58+1Вы привели хорошие аргументы. Правильный ли я делаю вывод: выбирая React Native автоматически надо знать Android или iOS чтобы написать что чуть более сложное чем hello-world?
djlewap
21.01.2017 01:19+1Выбирая React Native, неплохо бы еще научиться искать RN специфичные пакеты, благо их в достатке.
Вам бы помог пакет react-native-crypto, который является клоном вами упомянутого crypto-browserify, но с поддержкой нативного рандома.
jMas
21.01.2017 01:50+1Думается, что нет серебрянной пули и не будет. На каждой платформе есть специфика, работая например с Cordova мы тоже писали нативные компоненты и биндинги для каждой платформы. Поэтому в серьезной разработке всегда прйдется владеть базовыми знанями программирования для каждой целевой ОС под которую будет приложение.
RN выбирают чтобы свести к минимуму дублирование кода для нескольких ОС, например сторы.
jo_asakura
21.01.2017 18:46+1Вот, к примеру, разработчики Facebook'а, Discord'а и WalmartLabs делятся своим мнением о React Native.
Главный плюс данной технологии в том, что React Native позволяет многим front-end разработчикам вылезти из своей привычной среды (браузеры, node.js и т.д.) и поучаствовать в разработки мобильных приложений, расширить границы своих знаний и узнать больше о том, как работают мобильные платформы, без необходимости нырять с головой в ObjectiveC/Swift/Java.
Что касательно самого фреймворка, то React Native справляется со своей задачей очень хорошо, если подойти к этому делу с умом, терпением и главное желанием добиться результата.
Sayonji
20.01.2017 20:26+2Говорите, что RN не очень хорош, а аргументы — что нельзя просто так взять либы с другой платформы и вставить их. А обычно, можно да. Сейчас откажусь от RN, пересяду на джаву/свифт и все браузерные либы заработают, да? С чего вы вообще взяли, что что-то должно просто так работать? Потому что в вебвью работает? Ну да, никто и не спорит, что если нужно портировать вебсайт на телефон, то кордовой это проще сделать.
И отдельно:Если же такой библиотеки нет или ее производительность вас не устраивает, то необходимо написать native компонент для платформы под которую вы разрабатываете.
Другое дело кордова, там-то всё очень производительно. Или нативные компоненты пишутся намного проще. Или вы не с кордовой сравниваете? А с чем тогда? Есть технология, для которой не выполняется утверждение выше?
И да, на андройде нет сплеш-скринов. На ios их тоже можно только статично вставить в проекте, прогать их нельзя вне зависимости от фреймворка.
Прошу прощения, но статья ни о чем.sochix
20.01.2017 22:56-1Я рассматривал React Native с точки зрения фронтенд программиста, который знает javascript но не знает мобильной разработки.
Сейчас откажусь от RN, пересяду на джаву/свифт и все браузерные либы заработают, да?
Для Джавы и Свифта и так есть библиотеки там бразуреные не нужны. Для RN очень мало собственных библиотек, а старые js библиотеки не работают
И да, на андройде нет сплеш-скринов.
Если их нет, то почему же есть бибилиотека для них? react-native-splash-screen
Прошу прощения, но статья ни о чем.
В статье поднимается вопрос о нише React Native.
Sayonji
20.01.2017 23:27+1Для Джавы и Свифта и так есть библиотеки там бразуреные не нужны. Для RN очень мало собственных библиотек, а старые js библиотеки не работают.
Во-первых, для RN библиотек не так уж мало. Несомненно, меньше чем для кордовы, но тем не менее не мало. Не так уж легко столкнуться с задачей, под которую нет библиотеки. Во-вторых, не работают только некоторые библиотеки. Например, важный moment.js работает без проблем.
Если их нет, то почему же есть бибилиотека для них? react-native-splash-screen
Я понял, вы имеете в виду вторичный сплеш, который показывается уже после загрузки приложения. Я думал, что вы про такой как на ios. Что ж, библиотека таки есть. Да, там нужно прописывать строки в нативный код, но это цена за то, что его можно менять. Не уверен, что в кордове можно взять и встроить нативный элемент в страницу. Что приводит в вопросу о нише: никто не сомневается, что вебвью-приложения выглядят так себе, но использовать js хочется — вот и ниша (это не упомяная о реализации компонентного подхода в реакте, который многим очень нравится). Если же цель сделать попроще, то действительно можно завернуть любой сайт в кордову за вечер.
Я рассматривал React Native с точки зрения фронтенд программиста, который знает javascript но не знает мобильной разработки.
Я как раз недавно был точно в такой же ситуации, и наоборот был поражен тем, насколько легко оказалось сделать приложение, не выглядящее как вебвью, совершенно не вникая в джаву, андроид и вообще ничего кроме js.
Artem_007
22.01.2017 20:31+1Вообще-то, на андроиде есть сплэш-скрин:
Вот
А по делу — РН не подходит ни для одного мало-мальски серьезного проекта.bohdan4ik
23.01.2017 18:23> А по делу — РН не подходит ни для одного мало-мальски серьезного проекта.
Скажите это этим ребятам
https://facebook.github.io/react-native/showcase.html
voidnugget
21.01.2017 01:57+2Опыта разработки мобильных приложений нет, но есть 5 лет опыта разработки высоконагруженных проектов на node.js, asp.net mvc.
- Опыт временем не меряют.
- Не бывает "высоконагруженных проектов" на node.js / asp.net, просто масштабируется простой процессора в разных вариациях. Без упоминания слов: "профилирование", "аффинитет" и "большие страницы" — не один проект нельзя назвать высоконагруженным.
- Ну да, конечно "автор ниасилил, реакт сырой, потому что… автор ниасилил". Ок, смысл в целом понятен.
Если нет опыта с нативной мобильной разработкой — нет смысла лениво надеятся что всё поедет с полпинка.
Все серьёзные конторы (SoundCloud, Facebook, AirBnB) давно пишут нативные компоненты под себя, и сами их же и поддерживают. А надеятся на посредственные поделки с гитхаба слишком наивно.
Как это весело наблюдать когда одни матерят Cordova и говорят ехать в сторону React-Native, другие матерят React-Native и призывают менять религию на Cordova… а конструктивности и конкретики в обоих случаях как-то вот совсем не наблюдается.
sidny_vicious
21.01.2017 02:37Уважаемый автор, уделите внимание именно работе с кодом и возможностями. Отсутствие библиотек или сложность их нахождения не делают платформу для разработки плохой.
Изначально стоит определить для каких целей ее использовать и смотреть насколько это удобно.
torrie
21.01.2017 07:46+1Ну сравнили — cordova(html5 in webview) и native! Не надо так -абсолютно разная отзывчивость, скорость и возможности.
crashX
21.01.2017 11:47Проблема React Native в том что он молод, это да. Как следствие — библиотеки не стабильны, документация скудна, встречаются досадные баги, из-за которых приходится изрядно костылировать. Шаг влево — просадка производительности, шаг вправо — краши без внятных стэктрейсов. И это нормально в данном случае, никто не даем вам никаких гарантий, пока проект находится в активной разработке.
В то же время на Реакте уже написано довольно много приложений, опенсорсных и не очень. Facebook использует в своем приложении собственный фреймворк весьма успешно. Есть неплохое комьюнити, определенный набор стабильных библиотек. Никто не запрещает вам писать собственные js библиотеки или обертки под нативные компоненты, это не сложно.
Занимаюсь разработкой на React Native около года (на ClojureScript). За это время успел поучаствовать в нескольких проектах, несколько из них вышли в продакшн. Могу с уверенностью сказать что фреймворк уже сейчас пригоден для написания серьезных приложений, достаточно вникнуть в тонкости использования и несколько раз споткнуться об подводные камни :)
Houston
21.01.2017 14:39Добрый день.
Я уже больше года разрабатываю Open Source React Native проект в качестве 20-процентного рабочего проекта.
Есть ли проблемы с React Native? Да, конечно. Но не совсем те, с которыми столкнулись Вы:
Из-за молодости фреймворка, с обновлениями часто выходят Breaking changes, и обновление версии react-native может занять целый день. В 2016 году обновления выходили раз в 2 недели, и простое поддержание актуальной версии занимало порядка 10-20% времени. К счастью, теперь они перешли на месячный релизный цикл, и этот процесс должен упроститься.
Сырость библиотек – тут вы правы, часто приходилось допиливать чужие библиотеки, фиксить баги и т.д. Такова цена Open Source, но этим он и силён. Из-за пункта 1, сторонние библиотеки часто ломаются с выходом новой версии RN.
Кроссплатформенность – мне удалось поддержать обе платформы на одной кодовой базе, но цена этому – отсутствие "Material Design" фич на андроиде. Да и в общем, на андроиде чаще что-то работало не так, как нужно, и это требует отдельных усилий – поддерживать обе платформы.
- Continuous Integration – довольно больших усилий стоила настройка этого процесса, потому что, по умолчанию, всё настроено на сборку на локальной машине разработчика. Помнится, даже ENV-параметры нельзя было прокинуть, не знаю как сейчас.
Пожалуй, это всё, что с ходу вспомнилось.
dmitry_dvm
22.01.2017 11:55Немного офтоп: Зачем этому приложению сервер? Что там хранится? На гитхабе расписывается серверная часть, потому и спрашиваю. Возможно, что-то не так понял.
Sayonji
22.01.2017 13:27Это вы про который гитхаб? В статье на много репозиториев есть ссылка.
dmitry_dvm
23.01.2017 18:16Про этот https://github.com/lesspass/lesspass/#self-host-your-lesspass-database
bobych_spb
22.01.2017 20:33+1Думаю автор статьи в первую очередь испытал сильное разочарование в слоганах которые часто сопровождают хвалебные статьи про RN. Кажется что еще чуть-чуть и любой верстальщик сможет кодить мобильные приложения.
Мне кажется что первая проблема RN это люди хватающиеся за мобильную разработку с нуля.Не знакомые с процессом нативной разработки. Если опыт нативной разработки имеется то и покопаться в коде компонента не страшно и часто намного понятнее что и где сломалось при переходе на новую версию.
staticlab
Извините, но живут же как-то фронтендщики со всеми этими миллионами библиотек. Далеко не все их них зависят от Node.js и нативных модулей. Не пробовали ли полифиллы для Buffer и Stream? Более того, это не повод критиковать React Native в противовес Cordova.
Разве мобильный splash-screen — это не просто показать один компонент, а через пару секунд другой?
sochix
Да, я как раз таки один из таких фронтендщиков. Полифиллы пробовал, не удалось прикрутить их к билд-системе React Native.
Я не говорю что React Native хуже/лучше Cordova, я лишь рассказал что к моему проекту лучше подошла Cordova
Чуть-чуть сложней. Т.к. в этот момент js еще не выполняется, то код отрисовки splash screen должен выполнить java машина. Если я не прав, поправьте.
NewMax
К слову о splash screen. Я сам начал изучать React-Native в декабре прошлого года и столкнулся со схожими проблемами.
Нужно было реализовать splash screen и первой мыслью был компонент, который показывается первым. Как показала практика, это сомнительное решение. После этого я нашел такой пакет, который решил эту проблему для меня.
sochix
Тоже использовал этот компонент. Завести его оказалось не просто
bjornd
splash-screen показывается системой во время загрузки и инициализации приложения, поэтому привычных компонент еще нет