Когда я получил предложение о должности разработчика программного обеспечения для создания приложения на React Native, я не знал, чего ожидать.

С одной стороны, было здорово иметь возможность создать мобильное приложение для iOS и Android с использованием единой кодовой базы. С другой стороны, услышав, что такие компании, как Airbnb, протестировали платформу и в конечном итоге отказались от нее, я почувствовал, что впереди еще немало проблем.

Прошло несколько месяцев, и вот несколько уроков, которые я извлек на этом пути.

Выбор правильных библиотек

Одна из первых вещей, которые я узнал о React Native, - это то, что выбор сторонних библиотек часто ограничен. Как веб-разработчик на JavaScript, у меня был широкий выбор библиотек, которые я мог настраивать для различных проектов.

Библиотеки React Native сложнее создавать. Им требуется знание нативного кода iOS и Android для работы на разных платформах. Из-за этого не так много людей, разрабатывающих библиотеки для React Native.

После тщетных поисков на GitHub я выбрал большую часть своих библиотек приложений из репозитория React Native Community. Как правило, они лучше всего обслуживаются и почти гарантированно работают с последней версией React. Native Directory был еще одним полезным местом для быстрого поиска того, что доступно в React Native.

Даже в репозитории сообщества RN не все библиотеки работали «из коробки». Иногда мне нужно было разветвить репо и внести несколько собственных настроек. В других случаях мне нужно было перейти на версию, в которой исправлена ​​конкретная ошибка, обнаруженная в моем приложении. Контроль версий тем более важен, когда мало библиотек и мало сопровождающих.

Знакомство с Flexbox

Имея более 10 000 типов устройств только для Android, может быть сложно создать приложение, которое будет работать для всех размеров экрана. Мне нужно, чтобы мое приложение хорошо выглядело на таких маленьких устройствах, как iPhone SE, и таких больших, как Pixel 2XL.

Сначала я попытался стилизовать свое приложение с помощью встроенного класса Dimensions React Native, чтобы найти ширину и высоту каждого экрана. В конечном итоге это было слишком сложно поддерживать по мере роста приложения. Вместо этого Flexbox является ключом к возможности изящно решать стили для разных размеров экрана. Быстрое ознакомление с инструментом Flexbox Froggy - хороший способ быстро освоиться.

Flexbox не решил всех моих проблем со стилем. Я по-прежнему сталкивался с экранами нестандартных размеров, для которых требовались собственные стилистические решения, такие как SafeAreaView для iPhone серии X. Мне также нужно было использовать условные операторы для разных стилей iOS и Android на многих экранах. Но в целом это отличный инструмент для разработки приложений на React Native.

Выключите и снова включите

После того, как я установил новую стороннюю библиотеку и запустил react-native link, я часто сталкивался с ошибкой «undefined is not an object». React Native известен своими неописательными сообщениями об ошибках. Мне потребовалось время, чтобы понять, что это значит. Сначала я подумал, что с библиотекой что-то не так. Или что он не работал с установленной мной версией React Native.

Затем, глубоко в теме проблемы GitHub для одной конкретной библиотеки, я нашел этот комментарий, который, наконец, пролил свет на то, почему ни одна из моих библиотек не работает гладко.

Как и многие разработчики, я привык просто перезагружать свой проект во время работы react-native run-android или react-native run-ios. Горячая перезагрузка отлично подходит для экономии времени при внесении крошечных настроек стиля в приложение и проверке экранов. Однако это не помогает интегрировать новые библиотеки в приложение. Мои новые библиотеки не будут работать, пока я не закрою все свои симуляторы / эмуляторы, не отключу устройства и не перезапущу npm start, чтобы перезапустить сборщик Metro.

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

Работа без отладчика

Как веб-разработчик я практиковался в поиске ошибок в отладчике Google Chrome. В React Native прошло всего несколько недель, прежде чем я потерял способность отлаживать в Chrome.

Одним из ограничений моего приложения было то, что мне нужно было использовать Realm в качестве основной базы данных. Однако у Realm есть часто сообщаемая проблема, когда он уничтожает отладчик Chrome, делая его невозможным для использования. Мне нужно было найти другое решение.

React Native имеет встроенный отладчик, в котором вы можете записывать console.logs в терминал с помощью react-native log-android или react-native log-ios. Хотя это хорошо работает на Android, я столкнулся с проблемами при использовании этого отладчика для iOS. Я начал применять подход к разработке, ориентированный на Android, когда я создавал и тестировал все на Android, чтобы легко получить доступ к console.logs, а затем при необходимости вносил изменения в версию iOS. Я также вложил средства в создание более качественных сообщений об ошибках в своем приложении, что принесло пользу как моим пользователям, так и мне.

Я также экспериментировал с использованием XCode и Android Studio для отладки, но в конечном итоге обнаружил, что мой подход, ориентированный на Android, был самым простым решением с наименьшим количеством переключений экрана.

Ранний запуск производственных сборок

Опытные разработчики React Native рассказывали мне, что они редко сталкиваются с проблемами в производственном режиме, которые они еще не видели и не решали в процессе разработки. Это был не мой опыт. Когда я запускал свои производственные сборки на физических устройствах, я смог обнаружить несколько ошибок, которых не замечал раньше.

Одним из примеров была навигация. Сначала мне было сложно настроить навигацию в мобильном приложении, и мне нужно было внести несколько изменений в способ настройки моей библиотеки реагирования-навигации для доставки данных пользователю в нужное время. Использование физического устройства позволило мне смоделировать все способы, которыми пользователь может запускать мое приложение (то есть, когда они перейдут на новый экран, а не нажать кнопку «Назад»), и соответствующим образом настроить навигацию.

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

Заключение

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

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

Смогу ли я снова разрабатывать React Native? Абсолютно.