Skip to main content

Я опубликовал приложение для iOS с ClojureScript и React Native

За последние несколько лет я сохранил в список Notes.app рестораны, бары и другие места, которые я хотел посетить. Это было "грязно", не привязано географически, и трудно было что-то добавить. Не найдя каких-либо удовлетворительных решений в других местах, я решил избавиться от собственного дискомфорта и создать приложение для десктопа. Outboard - это результат последних пяти месяцев хакинга стороннего проекта, встроенного в ClojureScript для React Native.

Я создал пару приложений перед использованием Objective-C и наслаждаюсь Swift как языком, так почему этот стек? Познакомившись с функционально-моделью React в интерпретации Re-frame, мне трудно сейчас подойти к реализации пользовательского интерфейса. Добавьте горячую перезагрузку и Clojure REPL, и ClojureScript на React Native был очевидным выбором. Ниже приведены плюсы и минусы, с которыми я столкнулся по пути.

Достоинства

Функциональное программирование на React

С риском перепродать это с самого начала, я просто больше не сталкиваюсь с ошибками на пересечении состояний и пользовательского интерфейса. Целый класс дефектов, с которыми я боролся за последнее десятилетие, плюс профессиональная разработка программного обеспечения практически исчез. Нет больше немного несинхронизированных экранов, больше нет ссылок на мертвые данные; все ушли. Вместо этого - это легкая, простая в использовании, не требующая особых усилий структура в Re-frame, которая делает манипулирование данными простым и понятным, когда вы вернетесь к старому коду в будущем. На мой взгляд, Re-frame - убийственное приложение философии Clojure на переднем крае.

REPL-ориентированная разработка

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

Синтаксис икоты

Вероятно, это скорее личный опыт, но мне проще разобраться в макете приложения с Flexbox и Hiccup, чем в XCode Interface Builder. Я никогда не находил систему ограничений Apple для управления устройствами разных размеров и разрешений интуитивно понятной, но Flexbox позволяет мне использовать (скудный) опыт веб-дизайна, который мне необходим для создания разумных адаптивных дизайнов приложений.

Наличие библиотеки

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

Все они являются родными для Javascript, но их легко интегрировать с ClojureScript.

Нативные модули

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

Недостатки

Хотя это было не все таким радужным.

Несоответствие инструмента

Безусловно, самой большой проблемой, с которой я столкнулся, была работа с глубоким стеком, где слои менялись друг из друга, иногда без предупреждения. Мне нравится использовать ClojureScript, но он представляет еще один уровень абстракции поверх шаткой основы NPM, Javascript и React Native, все из которых находятся в состоянии постоянного изменения.

Острые края React Native

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

Проблемы с упаковщиком

Одной из острых проблем, возникающих из-за несоответствия инструментов, является упаковщик React Native, Metro. ClojureScript использует совершенно другой компилятор и упаковщик в Google Closure, и их совместное использование неэффективно; посмотрите, например, эту проблему, документирующую проблемы нехватки памяти и времени, когда Metro медленно пытается упаковать уже упакованный файл ClojureScript. Даже без дополнительных сложностей с Closure, Metro может привести в бешенство работу - однажды я «решил» проблему с его кешем после часа следования десятков положенных решений из потока вопросов Github, упрощая переименование каталога, в котором жил проект.

Планы на будущее

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

Синхронизация

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

Альтернативные устройства

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

Заключение

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