React Native: структурируем проект и управляем статическими ресурсами
Для проекта, загруженного с помощью 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 :)