React Native: структурируем проект и управляем статическими ресурсами
React и React Native - это всего лишь фрэймворки, они не диктуют, как структурировать проекты. Все зависит от ваших предпочтений и особенностей проекта. В статье мы рассмотрим, как структурировать проект и как управлять локальными assets.
Для проекта, загруженного с помощью react-native init, мы используем только базовую структуру.
Есть папка ios для проектов Xcode, папка Android для проектов Android и index.js и App.js для отправной точки React Native.
Как человек, который работал с native на Windows Phone, iOS и Android, я обнаружил, что структурирование проекта сводится к разделению файлов по типу (type) или функции (feature)
Группировка по типу
Так мы можем видеть тип каждого файла и легко запускать скрипт к определенному типу файла. Это общее правило для всех проектов, но оно не отвечает на вопрос «о чем проект?» Это новостное приложение? Это приложение для лояльности?
Организация файлов по типу удобна для машины, но не для человека. Мы работаем над фичами не один день, и искать файлы в нескольких каталогах - это лишние хлопоты.
Группировка по функциям
Более разумным решением является организация файлов по функциям. Файлы, объединенные одной функцией, должны быть размещены вместе. И тестовые файлы должны храниться вместе с исходными файлами.
Функция может быть связана с логином, подпиской или профилем пользователя. Функция может содержать вспомогательные, если они принадлежат одному и тому же функционалу. Если бы мы захотели переместить вспомогательную функцию, это было бы легко, так как все связанные файлы уже сгруппированы.
Моя типичная структура проекта, основанная на функциях, выглядит так:
Помимо традиционных файлов App.js и index.js и папок ios и android, я помещаю все исходные файлы в папку src. Внутри src у меня есть res для ресурсов, library для общих файлов, используемых во всех функциях, и screens для экранов.
Как можно меньше зависимостей
React Native основан на множестве зависимостей, я стараюсь быть в курсе всех обновлений. Для навигации я использую react-navigation.
Я не поклонник redux, так как он добавляет ненужную сложность проекту. Добавляйте зависимость только тогда, когда она вам действительно нужна, иначе вы просто создаете себе больше проблем.
Что мне нравится в React - это компоненты. В компоненте мы определяем вид, стиль и поведение. React имеет встроенный стиль - это похоже на использование JavaScript для определения сценария, HTML и CSS. Это соответствует функциональному подходу, к которому мы стремимся. Поэтому я не использую стилизованные компоненты. Стили - это объекты JavaScript, мы можем делиться ими в библиотеке.
src
Мне очень нравится Android, поэтому я называю src и res в соответствии с соглашениями о папках.
react-native init настраивает babel для нас. Но для типичного проекта JavaScript правильно организовывать файлы в папке src. В моем electron.js приложение IconGenerator, я поместил исходные файлы внутри папки src. Это не только помогает с точки зрения организации, но и помогает babel транспилировать всю папку сразу. Одна команда, и у меня есть файлы в src транспилированные dist в мгновение ока.
Screen
React основан на компонентах. Есть контейнер и презентационные компоненты, но мы можем создавать компоненты для создания более сложных компонентов. Это Page в Windows Phone, ViewController в iOS и Activity в Android.
index.js или нет?
Каждый screen считается точкой входа. Вы можете переименовать LoginScreen.js в index.js, используя функцию Node модуля:
Модули не обязательно должны быть файлами. Мы также можем создать папку find-me в разделе node_modules и разместить index.js файл там. Та же строка require('find-me') будет использовать index.js.
Вместо import LoginScreen from './screens/LoginScreen', мы можем просто сделать import LoginScreen from './screens'.
Использование index.js приводит к инкапсуляции и предоставляет публичный интерфейс для этой функции. Я предпочитаю явное имя для файла, следовательно, имя LoginScreen.js.
Navigator
React-navigation самый популярный выбор для обработки навигации в приложении React Native. Для такой функции, как onboarding, есть много экранов, управляемых навигацией стека, поэтому есть OnboardingNavigator.
Вы можете думать о Navigator как о чем-то, что группирует вспомогательные экраны или функции. Поскольку мы группируем по функциям, разумно разместить Navigator внутри папки с функциями. Обычно это выглядит так:
Library
Самая противоречивая часть при структурировании проекта. Если вам не нравится имя library, вы можете назвать utilities, common, citadel, как угодно.
Здесь мы размещаем общие утилиты и компоненты, которые используются многими функциями.
В React Native нам часто нужно реализовать кнопку с фоновым изображением на многих экранах. Вот простой пример, который остается внутри library/components/ImageButton.js. Папка components предназначена для повторно используемых компонентов, иногда называемых atomic components. В соответствии с соглашениями об именовании React первая буква должна быть прописной.
Если мы хотим разместить кнопку внизу, мы используем функцию utility для предотвращения дублирования кода. Вот так library /utils /moveToBottom.js:
Используйте package.json, чтобы избежать относительного пути
Где-то в src/screens/onboarding/term/Term.js мы можем импортировать данные, используя relative paths:
Это грозит ошибками, так как нужно вычислить, сколько .. мы должны поставить. И если мы перемещаем объект, все пути должны быть переписаны.
Поскольку библиотека предназначена для использования во многих местах, хорошо ссылаться на нее как на абсолютный путь. В JavaScript обычно существует 1000 библиотек для одной задачи. Быстрый поиск в Google показывает тонны библиотек для решения вопроса.
Решение состоит в том, чтобы превратить библиотеку в модуль, чтобы узел мог найти его. Добавление package.json в любую папку превращает его в модуль узла . Добавить package.json в папку библиотеки с простым содержимым:
Теперь в Term.js мы легко можем импортировать данные из библиотеки, потому что теперь это модуль:
res
Вы можете задаться вопросом, какие res/colors, res/strings, res/images и res/fonts приведены в примерах выше. Для front end проектов есть компоненты и стиль использования шрифтов, локализованных строк, цветов, изображений и стилей. JavaScript очень динамичный язык и легко использовать строгую тепизацию везде. У нас может быть куча #00B75D color во многих файлах или Fira как fontFamily во многих текстовых компонентах. Всё это трудно рефакторить.
res/colors
res/strings
res/fonts
res/images
Группировка цветов, изображений, шрифтов с палитрой
Дизайн приложения должен быть согласованным. Некоторые элементы должны быть одинаковыми, чтобы не запутать пользователя. Например, в тексте заголовка должен использоваться один цвет, шрифт и размер шрифта. Компонент Image должен использовать то же изображение. В React Native мы уже используем имена стилей с const styles = StyleSheet.create ({}),.
Пример, в котором определяются общие стили для заголовка и текста:
res/palette
Далее мы можем использовать их на экране.
Здесь мы используем оператор распространения объекта для слияния palette.heading и нашего объекта пользовательского стиля. Это означает, что мы используем стили из palette.heading, но также указываем дополнительные свойства.
Создание изображений
Вы можете увидеть в /src/res/images.js свойства для каждого изображения в папке src/res/images
Это утомительно делать вручную, и если есть изменения в соглашении об именах изображений, мы должны обновить данные. Вместо этого мы можем добавить скрипт для создания images.js на основе изображений, которые у нас есть. Добавьте файл в корень проекта /scripts/images.js:
Node удобен тем, что у нас есть доступ к модулю fs, который действительно хорош в обработке файлов. Здесь мы просто просматриваем изображения и обновляем соответственно /src/res/images.js.
Всякий раз, когда мы добавляем или меняем изображения, мы можем запускать:
И мы также можем объявить скрипт внутри нашего основного package.json
Теперь мы можем просто запустить npm run images и получить обновленный файл images.js.
В этой статье я рассказал и показал вам, как структурировать папки и файлы в проекте React Native. Также узнали, как управлять ресурсами и получать доступ к ним более безопасно.
Адаптированный перевод статьи How to structure your project and manage static resources in React Native от Digital Skynet :)