Так ли хорош React Native?20.01.2017 22:18

React Native 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: 

          
     this.setState({...this.state, site: value})}
        value={this.state.site}
        />

Бизнес логика


Бизнес логика моего приложения состояла ровно из одной функции — подсчет пароля по заданным значениям (адрес сайта, логин и мастер пароль). Более того эта функция уже была реализована в 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 со ссылками на готовые проекты.

Комментарии (9)

  • 20 января 2017 в 17:33

    –1

    ↑

    ↓

    Библиотека не заработала, т.к. для ее работы требуются базовые классы node.js такие, как Buffer и Stream.
    вы не можете использовать написанные миллионы библиотек в React Native

    Извините, но живут же как-то фронтендщики со всеми этими миллионами библиотек. Далеко не все их них зависят от Node.js и нативных модулей. Не пробовали ли полифиллы для Buffer и Stream? Более того, это не повод критиковать React Native в противовес Cordova.


    я так и не нашел адекватной библиотеки для задания splash-screen

    Разве мобильный splash-screen — это не просто показать один компонент, а через пару секунд другой?

    • 20 января 2017 в 17:41

      0

      ↑

      ↓

      Извините, но живут же как-то фронтендщики со всеми этими миллионами библиотек. Далеко не все их них зависят от Node.js и нативных модулей. Не пробовали ли полифиллы для Buffer и Stream?

      Да, я как раз таки один из таких фронтендщиков. Полифиллы пробовал, не удалось прикрутить их к билд-системе React Native.


      Более того, это не повод критиковать React Native в противовес Cordova.

      Я не говорю что React Native хуже/лучше Cordova, я лишь рассказал что к моему проекту лучше подошла Cordova


      Разве мобильный splash-screen — это не просто показать один компонент, а через пару секунд другой?

      Чуть-чуть сложней. Т.к. в этот момент js еще не выполняется, то код отрисовки splash screen должен выполнить java машина. Если я не прав, поправьте.

    • 20 января 2017 в 17:57

      +1

      ↑

      ↓

      splash-screen показывается системой во время загрузки и инициализации приложения, поэтому привычных компонент еще нет

  • 20 января 2017 в 17:35

    +1

    ↑

    ↓

    Автор не обижайтесь, но получилось примерно следующая ситуация.

    Так ли хорошо микроскоп?

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

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

    По моему мнению, микроскоп не годится в текущем его состоянии для забивания гвоздей. Основные факторы — плохо лежит в руке и недостаточно тяжелый. По итогу если вам нужно закрутить шуруп используйте шуруповерт, если хотите срубить дерево то тут подойдет топор. С топором дерево удалось повалить за 30 минут.

    • 20 января 2017 в 17:36

      0

      ↑

      ↓

      Спасибо за комментарий. Расскажите, в каком проекте вы бы использовали React Native? Потому как я не увидел его ниши

      • 20 января 2017 в 17:49

        0

        ↑

        ↓

        React Native позволяет создавать проекты которые обладают несколькими важными качествами. Во-первых на выходе получаются приложения которые выглядит и работают как нативные. Почему нативные приложения лучше объяснять думаю не стоит. При этом основную логику отображения и бизнес-логику дублировать не приходится как в схеме с независимой кодовой базой для каждой платформы. Критичные же для производительности или с точки зрения платформы вещи, как-то сложные вычисления, получения GPS-координат устройства или отображение splash screen’а, придется реализовать нативно для каждой платформы.

        В вашем случае действительно не было никаких предпосылок использовать React Native. Писали вы только для Android, а большая часть функционала приложения состояла из сложных вычислений.

        • 20 января 2017 в 17:58

          0

          ↑

          ↓

          Вы привели хорошие аргументы. Правильный ли я делаю вывод: выбирая React Native автоматически надо знать Android или iOS чтобы написать что чуть более сложное чем hello-world?

          • 20 января 2017 в 18:03

            0

            ↑

            ↓

            Да, но и для Cordova это тоже верно.

  • 20 января 2017 в 20:26 (комментарий был изменён)

    0

    ↑

    ↓

    Говорите, что RN не очень хорош, а аргументы — что нельзя просто так взять либы с другой платформы и вставить их. А обычно, можно да. Сейчас откажусь от RN, пересяду на джаву/свифт и все браузерные либы заработают, да? С чего вы вообще взяли, что что-то должно просто так работать? Потому что в вебвью работает? Ну да, никто и не спорит, что если нужно портировать вебсайт на телефон, то кордовой это проще сделать.

    И отдельно:

    Если же такой библиотеки нет или ее производительность вас не устраивает, то необходимо написать native компонент для платформы под которую вы разрабатываете.

    Другое дело кордова, там-то всё очень производительно. Или нативные компоненты пишутся намного проще. Или вы не с кордовой сравниваете? А с чем тогда? Есть технология, для которой не выполняется утверждение выше?

    И да, на андройде нет сплеш-скринов. На ios их тоже можно только статично вставить в проекте, прогать их нельзя вне зависимости от фреймворка.

    Прошу прощения, но статья ни о чем.

© Habrahabr.ru