Холивары про разработку приложений на React Native не угасают. Невозможность запилить плавную навигацию, отсутствие дебагинг-тулов — эти проблемы уже не проблемы, а потому обсасывание таких тем перестало быть актуальным. Сейчас фокус сместился на супер-кастомные штуки. О них и поговорим.
Кейс будет полезен тем, кто:
- Мечется между «Долго и нативно» и «Быстро и с React Native»;
- Ограничен в бюджете и хочет сделать что-то уникальное;
- Имеет технический бэкграунд. Для понимания трудностей, которые могут возникнуть по ходу работы.
Отмечу сразу, что проект, о котором пойдет речь — это история двухлетней давности. Доступных библиотек для разработки на React Native тогда было в разы меньше, а потому и задача казалась куда более сложной. Впрочем, читать от этого будет только интереснее!
Ну а теперь поехали.
Кто клиент
У заказчика была компания, предоставляющая датчики для отслеживания жизненных показателей растений в теплицах и уже существующее веб-приложение.
Логика работы веб-приложения: на каждой грядке есть датчик, отслеживающий состояние саженцев. Датчики общаются с сервером и передают данные о текущем положении дел.
Например, о наличии вредоносных насекомых или необходимости сделать полив
Управляющий теплицей вытаскивает информацию из веб-приложения и назначает полевых работников, которые смогут устранить неполадки и обеспечат растениям надлежащий уход.
Задачи для нас
1) Сделать мобильный прототип на React Native: с отображением теплицы и возможностью зумировать каждую грядку с одного экрана. Не было уверенности в том, что создание интерфейса такого ультра-зума возможно без привлечения нативщиков (было бы долго и дорого), поэтому прототип стал первостепенной задачей.
2) Сделать так, чтобы проект был совместим с Expo. У заказчика было несколько пользователей, а значит, мы могли протестить готовый прототип на живой аудитории. Возможности Expo позволяли это сделать быстро и без заморочек с загрузкой в App Store и Google Play.
Ограничивающее условие
Expo поддерживает популярные пакеты и апдейтится не так часто, как это было необходимо для разработки на React Native (тогда еще молодого). Его использование означало, что за бортом останется достаточно большое количество «еще не раскрученных» узкоспециализированных библиотек. Возможность сделать eject для нас не работала — при таком раскладе терялись бы все плюсы Expo. Короче, прикрутить то, что хочется, было нельзя, а число доступных либ было сильно ограничено.
За пару-тройку часов я накидал прототип для iOS, основанный на двух ScrollView (горизонтальном и вертикальном) с возможностью зума. Создал около 300 элементов, имитирующие участки теплиц. Все отлично работало. У заказчика было несколько претендентов на разработку, ему очень понравился наш прототип и он выбрал нас. После дал доступ к исходным данным.
Проблемы в момент подключения к серверу
И вот тут началось самое интересное. То, что не казалось проблемой на этапе прототипирования, перестало выглядеть столь радужно после получения входных данных.
При подключении к бэкенду стало понятно, что количество участков в одной теплице может измеряться, не сотнями (в прототипе мы отобразили именно такое количество), а тысячами.
При этом они все должны были быть интерактивными на любом размере зума
Реальность стала еще более суровой, когда мы узнали, что некоторые участки теплиц являются «детьми» более старших сущностей, которые наполняют их данными.
Сам бэкенд тоже оставлял много вопросов. Гигантские JSON объекты с часто дублирующимися данными, тяжелейшие запросы (бэкендер клиента рассказывал, что при определенных условиях мог вернуться JSON в размере около 2 Гб).
Первый прототип с реальными данными. Как понимаете, дизайнера мы тут не привлекали 🙂
Не уронить перформанс при отображении большого количество данных — это стало главным приоритетом. Это была скорее проблема грамотной структуры React-приложения и мемоизации данных. Т.к. при неправильной архитектуре мог бы начаться ререндеринг более 10к элементов. Умножьте все это на железо телефонов, которое в разы слабее по сравнению с компьютерами.
Веб-приложение клиента работало с существенными лагами на MacBook Pro, что уж говорить о популярном на тот момент iPhone SE. Было необходимо исключить любой ненужный ререндеринг.
Задача была выполнена: в основном, за счет грамотной мемоизации данных и использования определенных проверок на shouldComponentUpdate. Тут я сохранял данные и, если приходили те же самые, просто не менял их (чтобы Реакт не думал, что пришли новые). Ну и плюс проверял у старших компонентов на то, поменялось ли что-либо в них или нет, чтобы не перерендерировать всех потомков.
На все про все мы заложили полтора месяца — чтобы влезть в заранее оговоренные сроки, все это нужно было провернуть в турбо-режиме.
Разработка на React Native: В игру вступает его величество Android
Разработка на React Native шла так: сперва мы сделали прототип для iOS, а после собрали Android-билд. И вот тут вылезла новая порция проблем.
Изначальное решение использовать два элемента React Native ScrollView для зума просто не работает на андроиде. Свойство zoomScale попросту существует только для iOS. Необходимо было как можно скорее придумать что-то, что помогло бы решить эту проблему.
Сперва были разработаны пару прототипов с использованием скейлинга CSS (приближение и удаление за счет стилей). В плане перфоманса прототип был хорош, но не подошел из-за того что при приближении текст не изменялся нативно и превращался в размытые пиксели.
Затем был вариант с использованием D3.js (низкоуровневая тема для графиков). Однако на большом количестве данных менять координаты гигантскому количеству элементов, перерисовывая их… последние iPhone вывозили такое с трудом, андроиды же просто сходили с ума. Встал вопрос о привлечении Java-специалиста для написания нативного модуля и обертки React Native для подобного функционала. Жесткие дедлайны при всем при этом, разумеется, никто не отменял.
Что в итоге
Случилось то, что характерно для молодых технологий (разработка на React Native не исключение) — появилась новая библиотека, которая позволяла справиться со всеми ограничениями. Она была найдена каким-то чудом. Библиотека с крайне дурацким названием, парой недель жизни и 2-мя звездами на Гитхабе. Реализовав зум на Aндроиде, оставалось сделать лишь несколько дополнительных улучшений производительности, обусловленных слабым железом на андроиде.
Вот как мы тестировали ее в эмуляторе. После установки на реальный девайс все летало:
Качество сильно хромает 🙁 Единственное, что сохранилось как наглядный пример
Конечно, я испытал гордость за то, что мы успели в дедлайн. Это при достаточно жестких требованиях, прилетающих запросах и постоянных код-ревью со стороны клиента. Готовое приложение работало прекрасно даже на бюджетных андроидах, используя мемоизацию данных. Избежав ненужного ререндеринга на большом количестве элементов, мы сделали наше приложение очень быстрым, а по сравнению с веб-приложением оно просто летало, что показывало нас как высококлассных специалистов в разработке на React Native и React.
Было ли это везением? Определенно (ну и плюс отличные скилы поиска:D). Да, найденная либа помогла разработать необходимую функциональность. Сидеть ночами, чтобы уложиться в дедлайн, не пришлось. Мы бы при любом раскладе придумали способ, как закрыть эту задачу, тут же здорово подфартило. Вишенкой на торте стал тот факт, что мы помогли сэкономить бюджет заказчика — необходимость в найме нативщика просто отпала.
Что стало с проектом: Из-за проблем на бэке клиент решил уволить бэкендера сосредоточиться на его починке. Проект с мобильной версией ушел «на паузу».
Как говорил ранее, с тех пор прошло довольно много времени. Разработка на React Native существенно прокачалась, а решений, которые не покрывают библиотеки React Native, стало в разы меньше. Да, какие-то ограничения и сложности для реализации определенной функциональности силами самого React Native остались. Однако и при таком раскладе этот фреймворк сохраняет позиции мощной технологии, идеально подходящей для быстрого создания кроссплатформенных мобильных приложений.
Всем крепкого здоровья и крутых проектов!
