Полное руководство по React Router v6. Часть 1 - Основы React Router

год назад·3 мин. на чтение

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

Серия статей о React Router v6 состоит из 4 частей.
  1. Основы React Router (рассматривается в этой статье)
  2. Продвинутые определения маршрутов
  3. Управление навигацией
  4. Подробно о роутерах

Основы React Router

Прежде чем мы начнем углубляться в расширенные функции React Router, сначала поговорим об основах React Router. Чтобы использовать React Router, вам необходимо запустить npm i react-router-dom для установки React Router. Эта библиотека устанавливает DOM версию React Router. Если вы используете React Native, вам нужно будет установить react-router-native. За исключением этого небольшого отличия, библиотеки работают почти одинаково. В этой статье сосредоточимся на react-router-dom, но, как уже упоминалось, обе библиотеки почти идентичны. Чтобы использовать React Router, вам нужно сделать три вещи.
  1. Настроить роутер
  2. Прописать свои маршруты
  3. Управлять навигацией

Настройка роутера

Настройка роутера является самым простым шагом. Все, что вам нужно сделать, это импортировать конкретный роутер, который вам нужен (BrowserRouter для веба и NativeRouter для мобильных устройств) и обернуть все ваше приложение в этот роутер.
import React from "react"
import ReactDOM from "react-dom/client"
import App from "./App"
import { BrowserRouter } from "react-router-dom"

const root = ReactDOM.createRoot(document.getElementById("root"))
root.render(
  <React.StrictMode>
    <BrowserRouter>
      <App />
    </BrowserRouter>
  </React.StrictMode>
)
Как правило, вы импортируете свой маршрутизатор в файле index.js вашего приложения, и он будет оборачивать компонент App. Роутер работает так же, как контекст в React, и предоставляет всю необходимую информацию вашему приложению, чтобы вы могли выполнять маршрутизацию и использовать все пользовательские хуки из React Router.

Определение маршрутов

Следующим шагом в React Router является определение ваших маршрутов. Обычно это делается на верхнем уровне приложения, например в компоненте App, но это можно сделать в любом месте.
import { Route, Routes } from "react-router-dom"
import { Home } from "./Home"
import { BookList } from "./BookList"

export function App() {
  return (
    <Routes>
      <Route path="/" element={<Home />} />
      <Route path="/books" element={<BookList />} />
    </Routes>
  )
}
Определить маршруты так же просто, как определить компонент Route для каждого маршрута в приложении, а затем поместить все эти компоненты Route в один компонент Routes. Всякий раз, когда ваш URL-адрес изменяется, React Router будет просматривать маршруты, определенные в вашем компоненте Routes, и он будет отображать содержимое в пропсе element роута Route, который имеет path, соответствующий URL-адресу. В приведенном выше примере, если бы наш URL-адрес был /books, то отображался бы компонент BookList. Преимущество React Router заключается в том, что при переходе между страницами он обновляет только содержимое внутри вашего компонента Routes. Весь остальной контент на вашей странице останется прежним, что повысит производительность и удобство использования.

Управление навигацией

Последним шагом к React Router является обработка навигации. Обычно в приложении вы перемещаетесь с помощью тегов <a>, но React Router использует свой собственный кастомный компонент Link для обработки навигации. Link представляет собой просто оболочку вокруг тега <a>, которая помогает обеспечить правильную обработку всей маршрутизации и условного повторного рендеринга, чтобы вы могли использовать его так же, как обычный тег <a>.
import { Route, Routes, Link } from "react-router-dom"
import { Home } from "./Home"
import { BookList } from "./BookList"

export function App() {
  return (
    <>
      <nav>
        <ul>
          <li><Link to="/">Home</Link></li>
          <li><Link to="/books">Books</Link></li>
        </ul>
      </nav>

      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/books" element={<BookList />} />
      </Routes>
    </>
  )
}
В нашем примере мы добавили две ссылки на главную страницу и страницу книг. Вы также заметите, что мы использовали проп to для установки URL-адреса вместо пропса href, который вы привыкли использовать с тегом <a>. Это единственное различие между компонентом Link и тегом <a>, и это то, что вам нужно помнить, так как легко ошибочно случайно использовать проп href вместо to. Еще одна вещь, которую следует отметить в нашем новом коде, заключается в том, что <nav>, который мы создаем в верхней части нашей страницы, находится за пределами нашего компонента Routes, что означает, что при смене страниц этот раздел навигации не будет повторно рендериться, так при изменении URL-адреса изменится только содержимое компонента Routes.

Разделение ответственности в React. Как использовать контейнерные и презентационные компоненты.

год назад·6 мин. на чтение

Многие новички в React объединяют логику и представление в одном и том же компоненте. И они могут не знать, почему важно разделять эти две вещи.

В таком случае может обнаружиться, что нужно внести большие изменения в файл. Затем придется вносить много переделок, чтобы разделить логику и представление. Это происходит из-за того, что разработчик может не знать о разделении ответственности и таком шаблоне как презентационные и контейнерные компоненты (presentational and container components). В этой статье рассмотрим этот паттерн, чтобы смягчить эту проблему на ранних этапах жизненного цикла разработки проекта.

Что такое разделение ответственности?

Разделение ответственности — это концепция, которая широко используется в программировании. В нем говорится, что логика, выполняющая разные действия, не должна группироваться или объединяться вместе. Например, то, что мы обсуждали во вводной части, нарушает разделение задач, потому что мы поместили логику выборки данных и представления данных в один и тот же компонент.
Чтобы решить эту проблему и придерживаться разделения ответственности, мы должны разделить эти две части — то есть запрос данных и их представление в пользовательском интерфейсе — на два разных компонента. Шаблон контейнеры и презентационные компоненты (smart/dummy components) поможет нам решить эту проблему.

Что такое контейнерные и презентационные компоненты?

Контейнерные компоненты

Это компоненты, которые предоставляют, создают или хранят данные для дочерних компонентов. Единственная работа компонента-контейнера — обработка данных. Он не состоит из собственного пользовательского интерфейса. Скорее, он состоит из презентационных компонентов в качестве своих дочерних элементов, которые используют эти данные. Простым примером может быть компонент с именем FetchUserContainer, который состоит из некоторой логики, которая извлекает данные всех пользователей.

Презентационные компоненты

Это компоненты, основной обязанностью которых является представление данных в пользовательском интерфейсе. Они принимают данные из компонентов контейнера. Эти компоненты не имеют состояния, если только им не требуется собственное состояние для отображения пользовательского интерфейса. Они не изменяют данные, которые они получают. Примером этого может быть компонент UserList, который просто отображает всех пользователей.

Зачем нам нужны эти компоненты?

Чтобы понять это, возьмем простой пример. Мы хотим отобразить список сообщений, которые мы получаем из JSON placeholder API.
// DisplayPosts.tsx

import { useEffect, useState } from "react";

interface ISinglePost {
  userId: number;
  id: number;
  title: string;
  body: string;
}

/* Пример того как НЕ нужно объединять логику и отображение */
export default function DisplayPosts() {
  const [posts, setPosts] = useState<ISinglePost[] | null>(null);
  const [isLoading, setIsLoading] = useState<Boolean>(false);
  const [error, setError] = useState<unknown>();

  // Логика
  useEffect(() => {
    (async () => {
      try {
        setIsLoading(true);
        const resp = await fetch("https://jsonplaceholder.typicode.com/posts");
        const data = await resp.json();
        setPosts(data);
        setIsLoading(false);
      } catch (err) {
        setError(err);
        setIsLoading(false);
      }
    })();
  }, []);

  // Представление
  return isLoading ? (
    <span>Loading... </span>
  ) : posts ? (
    <ul>
      {posts.map((post: ISinglePost) => (
        <li key={`item-${post.id}`}>
          <span>{post.title}</span>
        </li>
      ))}
    </ul>
  ) : (
    <span>{JSON.stringify(error)}</span>
  );
}
Вот что делает этот компонент:
  • Он имеет 3 переменные состояния: posts, isLoading и error.
  • У нас есть хук useEffect, который состоит из бизнес-логики. Здесь мы извлекаем данные из jsonplaceholder API с помощью fetch.
  • Когда данные извлекаются, мы сохраняем их в переменной состояния posts, используя setPosts.
  • Мы также гарантируем, что переключаем значения isLoading и error во время соответствующих сценариев.
  • Мы поместили всю эту логику в асинхронную функцию.
  • Возвращаем посты в виде списка и отображаем их.
Проблема заключается в том, что логика получения данных и отображения данных находится в одном компоненте. Можно сказать, что компонент теперь тесно связан с логикой. Это именно то, чего мы не хотим.
Ниже приведены некоторые причины, по которым нам требуются контейнерные и презентационные компоненты:
  • Они помогают нам создавать слабосвязанные компоненты.
  • Они помогают нам поддерживать разделение ответственности.
  • Рефакторинг кода становится намного проще.
  • Код становится более организованным и удобным в сопровождении
  • Это значительно упрощает тестирование.

Пример компонента-представления и контейнера

Для примера будем использовать тот же пример, что и выше — получение данных из JSON placeholder API. Разберемся со структурой файлов. Нашим контейнерным компонентом будет PostContainer. У нас будет два презентационных компонента:
  • Posts: компонент с неупорядоченным списком.
  • SinglePost: компонент, отображающий элемент списка.
Мы собираемся хранить все вышеперечисленные компоненты в отдельной папке с именем components. Теперь, когда мы знаем, что куда помещать, давайте начнем с компонента-контейнера: PostContainer.

Компонент PostContainer

// components/PostContainer.tsx

import { useEffect, useState } from "react";
import { ISinglePost } from "../Definitions";
import Posts from "./Posts";

export default function PostContainer() {
  const [posts, setPosts] = useState<ISinglePost[] | null>(null);
  const [isLoading, setIsLoading] = useState<Boolean>(false);
  const [error, setError] = useState<unknown>();

  useEffect(() => {
    (async () => {
      try {
        setIsLoading(true);
        const resp = await fetch("https://jsonplaceholder.typicode.com/posts");
        const data = await resp.json();
        setPosts(data.filter((post: ISinglePost) => post.userId === 1));
        setIsLoading(false);
      } catch (err) {
        setError(err);
        setIsLoading(false);
      }
    })();
  }, []);

  return isLoading ? (
    <span>Loading... </span>
  ) : posts ? (
    <Posts posts={posts} />
  ) : (
    <span>{JSON.stringify(error)}</span>
  );
}
Файл с типами.
components/Definitions.ts

export interface SinglePost {
  userId: number;
  id: number;
  title: string;
  body: string;
}
Приведенный выше код просто содержит логику выборки данных. Эта логика присутствует в хуке useEffect. Этот компонент-контейнер передает эти данные презентационному компоненту Posts. Давайте взглянем на презентационный компонент Posts.

Компонент Posts

// components/Posts.tsx

import { ISinglePost } from "../Definitions";
import SinglePost from "./SinglePost";

export default function Posts(props: { posts: ISinglePost[] }) {
  return (
    <ul
      style={{
        display: "flex",
        flexDirection: "column",
        alignItems: "center"
      }}
    >
      {props.posts.map((post: ISinglePost) => (
        <SinglePost {...post} />
      ))}
    </ul>
  );
}
Как видите, это простой файл, состоящий из тега ul — неупорядоченного списка. Затем этот компонент отображает посты, которые передаются в качестве пропса. Мы передаем каждый объект поста в компонент SinglePost. Существует еще один презентационный компонент, который отображает элемент списка, это тег li. Он отображает заголовок и тело сообщения.

Компонент SinglePost

// components/SinglePost.tsx

import { ISinglePost } from "../Definitions";

export default function SinglePost(props: ISinglePost) {
  const { userId, id, title, body } = props;

  return (
    <li key={`item-${userId}-${id}`} style={{ width: 400 }}>
      <h4>
        <strong>{title}</strong>
      </h4>
      <span>{body}</span>
    </li>
  );
}
Эти презентационные компоненты просто отображают данные на экране. Вот и все. Они не делают ничего другого. Поскольку здесь они просто отображают данные, они также будут иметь собственные стили. Теперь, когда мы настроили компоненты, давайте посмотрим, что удалось достичь:
  • Концепция разделения ответственности в этом примере не нарушается.
  • Написание модульных тестов для каждого компонента становится проще.
  • Сопровождаемость и читабельность кода намного лучше. Таким образом, наша кодовая база стала намного более организованной.
Здесь мы добились того, чего хотели, но мы можем еще больше улучшить этот паттерн с помощью React хуков.

Как заменить контейнерные компоненты на React хуки

Начиная с React 16.8 стало намного проще создавать и разрабатывать компоненты с помощью функциональных компонентов и хуков. Здесь мы воспользуемся этими возможностями и заменим компонент-контейнер хуком.
// hooks/usePosts.ts

import { useEffect, useState } from "react";
import { ISinglePost } from "../Definitions";

export default function usePosts() {
  const [posts, setPosts] = useState<ISinglePost[] | null>(null);
  const [isLoading, setIsLoading] = useState<Boolean>(false);
  const [error, setError] = useState<unknown>();

  useEffect(() => {
    (async () => {
      try {
        setIsLoading(true);
        const resp = await fetch("https://jsonplaceholder.typicode.com/posts");
        const data = await resp.json();
        setPosts(data.filter((post: ISinglePost) => post.userId === 1));
        setIsLoading(false);
      } catch (err) {
        setError(err);
        setIsLoading(false);
      }
    })();
  }, []);

  return {
    isLoading,
    posts,
    error
  };
}
Что дает это улучшение:
  • Извлечена логика, которая присутствовала в компоненте PostContainer, в хук.
  • Этот хук вернет объект, содержащий значения isLoading, posts и error.
Теперь мы можем просто удалить компонент-контейнер PostContainer. Затем, вместо того, чтобы передавать данные контейнера презентационным компонентам в качестве пропса, мы можем напрямую использовать этот хук внутри презентационного компонента Posts. Внесем следующие изменения в компонент Posts.
// components/Posts.tsx

import { ISinglePost } from "../Definitions";
import usePosts from "../hooks/usePosts";
import SinglePost from "./SinglePost";

export default function Posts(props: { posts: ISinglePost[] }) {
  const { isLoading, posts, error } = usePosts();

  return (
    <ul
      style={{
        display: "flex",
        flexDirection: "column",
        alignItems: "center"
      }}
    >
      {isLoading ? (
        <span>Loading...</span>
      ) : posts ? (
        posts.map((post: ISinglePost) => <SinglePost {...post} />)
      ) : (
        <span>{JSON.stringify(error)}</span>
      )}
    </ul>
  );
}
Используя хуки, мы устранили дополнительный слой компонента, который присутствовал поверх этих презентационных компонентов. С хуками мы достигли тех же результатов, что и с шаблоном контейнерные/презентационные компоненты.

Итоги

Итак, в этой статье мы рассмотрели:
  • Разделение ответственности.
  • Контейнерные и презентационные компоненты
  • Зачем нам нужны эти компоненты
  • Как хуки могут заменить компоненты-контейнеры