Разметка React с JSX

Содержание туториала по React JSX — это расширение синтаксиса для JavaScript, позволяющее писать HTML-подобную разметку внутри файла JavaScript. Хотя есть и другие способы написания компонентов, большинство разработчиков React предпочитают лаконичность JSX, и большинство кодовых баз используют его.

JSX: добавление разметки в JavaScript

Интернет был построен на HTML, CSS и JavaScript. В течение многих лет веб-разработчики хранили контент в HTML, дизайн в CSS и логику в JavaScript — часто в отдельных файлах. Контент был размечен внутри HTML, а логика страницы жила отдельно в JavaScript. Но по мере того, как Интернет становился все более интерактивным, содержание все больше определялось логикой. JavaScript отвечал за HTML. Вот почему в React логика рендеринга и разметка живут в одном месте — в компонентах. Сохранение логики рендеринга кнопки и разметки вместе гарантирует их синхронизацию друг с другом при каждом редактировании. И наоборот, несвязанные детали, такие как разметка кнопки и разметка боковой панели, изолированы друг от друга, что делает более безопасным изменение любой из них по отдельности. Каждый компонент React — это функция JavaScript, которая может содержать некоторую разметку, которую React отображает в браузере. Компоненты React используют расширение синтаксиса под названием JSX для представления этой разметки. JSX очень похож на HTML, но немного строже и может отображать динамическую информацию. Лучший способ понять это — преобразовать некоторую разметку HTML в разметку JSX. JSX и React — это две разные вещи. Они часто используются вместе, но вы можете использовать их независимо друг от друга. JSX — это расширение синтаксиса, а React — это библиотека JavaScript.

Преобразование HTML в JSX

Предположим, что у вас есть некоторый (совершенно правильный) HTML:

<h1>Todos</h1>
<img src="https://example.com/userpic.jpg" alt="userpic" class="photo" />
<ul>
  <li>Learn JavaScript</li>
  <li>Learn HTML</li>
  <li>Learn CSS</li>
</ul>

И вы хотите поместить его в свой компонент:

export default function TodoList() {
  return (
    // ???
  )
}

Если вы скопируете и вставите его как есть, он не будет работать.

// App.js

export default function TodoList() {
  // Этот код не будет работать
  return (
    <h1>Todos</h1>
    <img src="https://example.com/userpic.jpg" alt="userpic" class="photo" />
    <ul>
      <li>Learn JavaScript</li>
      <li>Learn HTML</li>
      <li>Learn CSS</li>
    </ul>
  );
}

// App.js: Adjacent JSX elements must be wrapped in an enclosing tag. Did you want a JSX fragment <>...</>? (5:4)

// App.js: Смежные элементы JSX должны быть заключены в закрывающий тег. Вам нужен фрагмент JSX <>...</>? (5:4)

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

Правила JSX

1. Возвращать один корневой элемент

Чтобы вернуть несколько элементов из компонента, оберните их одним родительским тегом. Например, вы можете использовать <div>:

<div>
  <h1>Todos</h1>
  <img src="https://example.com/userpic.jpg" alt="userpic" class="photo" />
  <ul>
    ...
  </ul>
</div>

Если вы не хотите добавлять в разметку лишний <div>, вы можете вместо этого написать <> и </>:

<>
  <h1>Todos</h1>
  <img src="https://example.com/userpic.jpg" alt="userpic" class="photo" />
  <ul>
    ...
  </ul>
</>

Этот пустой тег называется фрагментом (Fragment). Фрагменты позволяют группировать элементы, не оставляя следов в HTML-дереве браузера.

Почему необходимо обернуть несколько тегов JSX?

JSX выглядит как HTML, но внутри он трансформируется в простые объекты JavaScript. Вы не можете вернуть два объекта из функции, не поместив их в массив. Это объясняет, почему вы также не можете вернуть два тега JSX, не завернув их в другой тег или фрагмент.

2. Закрывать все теги

JSX требует, чтобы теги были закрыты явно: самозакрывающиеся теги, такие как <img>, должны стать <img />, а теги-обертки, такие как <li>апельсины, должны быть записаны как <li>апельсины</li>.

3. Пишите все в camelCase

JSX превращается в JavaScript, а атрибуты, написанные в JSX, становятся ключами объектов JavaScript. В ваших собственных компонентах вам часто потребуется считывать эти атрибуты в переменные. Но JavaScript имеет ограничения на имена переменных. Например, их имена не могут содержать тире или быть зарезервированными словами, такими как class. Вот почему в React многие атрибуты HTML и SVG записываются в camelCase. Например, вместо stroke-width вы используете strokeWidth. Поскольку class является зарезервированным словом, в React вместо этого вы пишете className, названное в честь соответствующего DOM свойства:

<img src="https://example.com/userpic.jpg" alt="userpic" className="photo" />

Совет: используйте конвертер JSX

Преобразование всех этих атрибутов в существующую разметку может быть утомительным. Рекомендуется использовать конвертер для перевода существующих HTML и SVG в JSX. Конвертеры очень полезны на практике, но все же стоит понимать, что происходит, чтобы вы могли комфортно писать JSX самостоятельно. Вот окончательный результат:

export default function TodoList() {
  return (
    <>
      <h1>Todos</h1>
      <img
        src="https://example.com/userpic.jpg"
        alt="userpic"
        className="photo"
      />
      <ul>
        <li>Learn JavaScript</li>
        <li>Learn HTML</li>
        <li>Learn CSS</li>
      </ul>
    </>
  );
}

Резюме

Теперь вы знаете, почему существует JSX и как его использовать в компонентах:

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

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

Технологии

Поскольку эта статья будет носить характер мнения. Сделаем несколько предположений о том, какие технологии будут использоваться в проекте:

• Приложение - React (Hooks)
• Глобальное управление состоянием - Redux, Redux Toolkit
• Маршрутизация - React Router
• Стили - CSS, Sass, Styled Components
• Тестирование - Jest, React Testing Library

Нет четкого мнения по поводу стилей, идеальны ли Styled Components, CSS-модули или пользовательский набор для Sass, поэтому можно использовать любой подходящий вариант. Также предполагается, что тесты находятся рядом с кодом, а не в папке tests на верхнем уровне. Все, что здесь написано, может быть применимо, если вы используете обычный Redux, а не Redux Toolkit. Можно настроить ваш Redux как feature slices. Также будет удобно визуализировать созданные компоненты с помощью, например, Storybook. Также покажем, как проект будет выглядеть с этими файлами, если вы решите использовать его в своем проекте. Для примера будем использовать приложение “Библиотека”, который имеет страницу со списком книг, страницу со списком авторов и систему аутентификации.

Структура каталога

Структура каталогов верхнего уровня будет выглядеть следующим образом:

• assets - глобальные статические файлы, такие как изображения, svg, логотип компании и т.д.
• components - глобальные общие/повторно используемые компоненты, такие как макеты (обертки), компоненты форм, кнопки
• services - JavaScript модули
• store - глобальное хранилище Redux
• utils - утилиты, помощники, константы и т.п.
• views - можно также назвать pages, здесь будет содержаться большая часть приложения. Лучше сохранять привычные соглашения, где это возможно, поэтому src содержит все, index.js является точкой входа, а App.js устанавливает аутентификацию и маршрутизацию.

.
└── /src
    ├── /assets
    ├── /components
    ├── /services
    ├── /store
    ├── /utils
    ├── /views
    ├── index.js
    └── App.js

Также в проекте могут присутствовать некоторые дополнительные папки, которые у вас могут быть, такие как types, если это проект TypeScript, middlewares (промежуточное программное обеспечение), если необходимо, возможно, контекст для работы с Context API и т.д.

Псевдонимы (алиасы)

Полезно настроить систему на использование псевдонимов, чтобы все, что находится в папке компонентов, можно было импортировать как @components, изображения как @assets и т. д. Если у вас Webpack, это делается через конфигурацию resolve.

module.exports = {
  resolve: {
    extensions: ['js', 'ts'],
    alias: {
      '@': path.resolve(__dirname, 'src'),
      '@assets': path.resolve(__dirname, 'src/assets'),
      '@components': path.resolve(__dirname, 'src/components'),
      // ...etc
    },
  },
}

Это просто облегчает импорт из любого места в проекте и перемещение файлов без изменения импорта, и вы никогда не получите что-то вроде ../../../../../../../components/.

Компоненты

В папке components компоненты сгруппированы по типам - формы, таблицы, кнопки, макеты и т.д. Специфика зависит от конкретного приложения. В данном примере предполагается, что вы либо создаете собственную систему форм, либо создаете привязку к существующей системе форм (например, комбинируя Formik и Material UI). В этом случае вы создадите папку для каждого компонента (TextField, Select, Radio, Dropdown и т.д.), а внутри будет файл для самого компонента, стили, тесты и Storybook, если он используется.

• Component.js - собственно компонент React
• Component.styles.js - файл стилей для компонента
• Component.test.js - тесты
• Component.stories.js - файл Storybook.

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

.
└── /src
    └── /components
        ├── /forms
        │   ├── /TextField
        │   │   ├── TextField.js
        │   │   ├── TextField.styles.js
        │   │   ├── TextField.test.js
        │   │   └── TextField.stories.js
        │   ├── /Select
        │   │   ├── Select.js
        │   │   ├── Select.styles.js
        │   │   ├── Select.test.js
        │   │   └── Select.stories.js
        │   └── index.js
        ├── /routing
        │   └── /PrivateRoute
        │       ├── /PrivateRoute.js
        │       └── /PrivateRoute.test.js
        └── /layout
            └── /navigation
                └── /NavBar
                    ├── NavBar.js
                    ├── NavBar.styles.js
                    ├── NavBar.test.js
                    └── NavBar.stories.js

Обратите внимание, что в каталоге components/forms есть файл index.js. Часто справедливо советуют избегать использования файлов index.js, поскольку они не являются явными, но в данном случае это имеет смысл - в конечном итоге он будет индексом всех форм и будет выглядеть примерно так:

// src/components/forms/index.js

import { TextField } from './TextField/TextField'
import { Select } from './Select/Select'
import { Radio } from './Radio/Radio'

export { TextField, Select, Radio }

Затем, когда вам понадобится использовать один или несколько компонентов, вы можете легко импортировать их все сразу.

import { TextField, Select, Radio } from '@components/forms'

Иногда лучше использовать этот подход, чем создавать index.js внутри каждой папки внутри forms, так что теперь у вас есть только один index.js, который фактически индексирует всю директорию, в отличие от десяти файлов index.js только для того, чтобы упростить импорт для каждого отдельного файла.

Сервисы

Каталог services менее важен, чем компоненты, но если вы создаете простой модуль JavaScript, который используется остальной частью приложения, он может быть полезен. Обычный пример - модуль LocalStorage, который может выглядеть следующим образом:

.
└── /src
    └── /services
        ├── /LocalStorage
        │   ├── LocalStorage.service.js
        │   └── LocalStorage.test.js
        └── index.js

Пример сервиса:

// src/services/LocalStorage/LocalStorage.service.js
export const LocalStorage = {
  get(key) {},
  set(key, value) {},
  remove(key) {},
  clear() {},
}

import { LocalStorage } from '@services'

LocalStorage.get('foo')

Хранилище (стор, store)

Глобальное хранилище данных будет содержаться в директории store - в данном случае Redux. Каждая функциональность будет иметь свою папку, в которой будет содержаться слайс Redux Toolkit, а также экшены и тесты. Эта настройка также может быть использована с обычным Redux, вы просто создадите файл .reducers.js и .actions.js вместо slice. Если вы используете саги, это может быть .saga.js вместо .actions.js для действий Redux Thunk.

.
└── /src
    ├── /store
    │   ├── /authentication
    │   │   ├── /authentication.slice.js
    │   │   ├── /authentication.actions.js
    │   │   └── /authentication.test.js
    │   ├── /authors
    │   │   ├── /authors.slice.js
    │   │   ├── /authors.actions.js
    │   │   └── /authors.test.js
    │   └── /books
    │       ├── /books.slice.js
    │       ├── /books.actions.js
    │       └── /books.test.js
    ├── rootReducer.js
    └── index.js

Вы также можете добавить что-то вроде ui секции стора для обработки модальных окон, всплывающих уведомлений, переключения боковой панели и других глобальных состояний пользовательского интерфейса, что, лучше, чем иметь const [isOpen, setIsOpen] = useState(false) повсюду. В rootReducer вы импортируете все свои фрагменты и объединяете их с помощью combineReducers, а в index.js настраиваете магазин.

Утилиты (Utils)

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

.
└── src
    └── /utils
        ├── /constants
        │   └── countries.constants.js
        └── /helpers
            ├── validation.helpers.js
            ├── currency.helpers.js
            └── array.helpers.js

Опять же, папка utils может содержать все, что вы захотите, и что, по вашему мнению, имеет смысл держать на глобальном уровне. Если вам не нравятся "многоуровневые" имена файлов, вы можете просто назвать его validation.js. Однако, это облегчает навигацию по именам файлов при поиске в IDE.

Views

Здесь находится основная часть вашего приложения: в каталоге views. Любая страница в вашем приложении - это "представление" (view). В этом небольшом примере представления довольно хорошо согласуются со стором Redux, но не обязательно, что стор и представления будут полностью совпадать, поэтому они разделены. Кроме того, книги могут тянуть за собой авторов, и так далее. Все, что находится внутри представления, является сущностью, которая, скорее всего, будет использоваться только в этом конкретном представлении - BookForm, который будет использоваться только на маршруте /books, и AuthorBlurb, который будет использоваться только на маршруте /authors. Это могут быть специфические формы, модальные окна, кнопки, любые компоненты, которые не будут глобальными. Преимущество хранения всего в домене вместо объединения всех страниц в компоненты/страницы заключается в том, что это позволяет легко взглянуть на структуру приложения и узнать, сколько в нем представлений верхнего уровня, и понять, где находится все, что используется только этим представлением. Если есть вложенные маршруты, вы всегда можете добавить папку вложенных представлений в основной маршрут.

.
└── /src
    └── /views
        ├── /Authors
        │   ├── /AuthorsPage
        │   │   ├── AuthorsPage.js
        │   │   └── AuthorsPage.test.js
        │   └── /AuthorBlurb
        │       ├── /AuthorBlurb.js
        │       └── /AuthorBlurb.test.js
        ├── /Books
        │   ├── /BooksPage
        │   │   ├── BooksPage.js
        │   │   └── BooksPage.test.js
        │   └── /BookForm
        │       ├── /BookForm.js
        │       └── /BookForm.test.js
        └── /Login
            ├── LoginPage
            │   ├── LoginPage.styles.js
            │   ├── LoginPage.js
            │   └── LoginPage.test.js
            └── LoginForm
                ├── LoginForm.js
                └── LoginForm.test.js

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

Итоги

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