Совсем недавно состоялся релиз 6-ой версии react-router. Вообще создатели react-router часто меняют подходы, используемые в библиотеке, но в этот раз они объединили лучшее, что было в прошлых версиях. В статье приведу краткий обзор того, что поменялось. Поиграть с новой версией можно тут. Switch -> Routes Относительные пути Element вместо Component / render Отказ от withRouter и новые хуки Вложенные роуты Индексные роуты useRoutes вместо react-router-config Вместо компонента Switch теперь появился компонент Routes. Но это не просто переименование — Routes более функционален. Основное отличие в том, что Routes не требует жесткого порядка роутов внутри. Switch обходил роуты в строгом порядке сверху вниз и при первом совпадении пути рендерил заданный компонент. Поэтому важно было определить порядок: например, выносить вниз наиболее общий роут. Рассмотрим пример: В таком случае по любом URL рендерился бы компонент Home. Чтобы этого избежать, пришлось бы поставить <Route path='/' component={Home}/> в конец Switch. В случае с Routes этого делать не нужно. Компонент «более умный» и сматчит наиболее подходящий роут: Это срабатывает даже с более сложными кейсами, например с именованными параметрами. Пример из документации: По урлу teams/new откроется не компонент Team, а NewTeamForm, хотя путь teams/:teamId тоже матчится с урлом teams/new. Следующее важное нововведение — относительные пути. Раньше в пропсе path у компонентов Route нужно было указывать полный путь, например: И в роутах внутри компонента Courses пришлось бы тоже указывать полные пути: Теперь вам достаточно указать относительный путь в пропсе path. Он будет автоматически добавлен к пути родительского роута. Например, компонент Courses теперь можно написать так: То же самое правило действует для компонентов Link, которые отвечают за ссылки. В пропсе “to” можно указать относительный путь, который сработает по той же схеме, что и “path” в Route. Например, если в компоненте Courses сделать <Link to=”123”>id=123</Link>, то ссылка будет вести на /courses/123. Это, пожалуй, одна из самых удобных фичей, которые появились в новом роутере. Раньше в компоненте Route был выбор: либо указать компонент для рендера, либо передать render-prop функцию. В первом случае код выглядит красиво: Но у него есть существенный недостаток. Вы не могли прокинуть дополнительные пропсы в компонент из родителя. Проблема решалась использованием render-функции: В новой версии роутера даже этого делать не придется. Оба этих пропса заменены на один — element. В него можно передать любой JSX-элемент. Пример выше в таком случае будет выглядеть так: Это намного более удобно, сокращает код и делает его визуально более понятным. react-router появился давно, еще когда функциональные компоненты не имели возможности привязаться к жизненному циклу компонентов. Тогда для большинства компонентов (кроме совсем «глупых») использовались классовые компоненты. Единственным способом подмешать какую-то логику / пропсы в них была композиция, а именно использовался паттерн HOC (Higher Order Component). В react-router был HOC withRouter, которым нужно было обернуть компонент, чтобы у него появились нужные для роутинга пропсы, например, объект истории, location, параметры и тд. С появлением хуков в функциональных компонентах смысл использования HOC’а, который добавляет лишнюю обертку над компонентом, пропал. React-router добавил поддержку хуков useHistory, useLocation, useParams, которые отвечали за получение объекта истории, локейшна и сматченных параметров. В 6 версии HOC withRouter вообще не упоминается, а все пропсы роутера рекомендуется получать через хуки useNavigate, useLocation, useParams. У этого изменения более глубокие корни. Чтобы понять мотивацию, придется вернуться аж к версии react-router v1. В первой версии была возможность указать вложенные роуты прямо в конфиге: Либо в качестве children’ов в компоненте Route: В примере выше в обоих случаях в компоненте App нужно рендерить children: Вложенные роуты позволяют перерендеривать только необходимую часть страницы при изменении урла. Например, оставлять шапку страницы с какими-нибудь табами, а перерисовывать только внутреннее содержимое. В более поздних версиях роутера эту возможность убрали, заменив на возможность вставить Route на любом уровне вложенности в компонентах. А теперь снова вернули, только в новом обличии. Теперь вы можете сделать ровно такой же «конфиг» роутов, но использовать компонент Outlet в родительском роуте. Пример из документации: Однако это не единственная возможность сделать вложенные роуты! Возможность использовать Routes на любом уровне вложенности остается: Обратите внимание на "*" в пропсе path роута /students/*. Звездочка означает, что данный роут будет матчиться с урлами вида /students/что-либо. При рендере компонента Students для урлов с параметров после /students/<тут> будет рендериться компонент Student. Основное отличие от того, что было раньше — звездочка. Кстати, пропс exact исчез. Благодаря звездочке в нем пропала необходимость. Получается, что звездочка в пути отражает, что роут может матчиться с вложенными роутами. Если же звездочки нет — то только при точном совпадении пути. Это одна из важных особенностей при переводе проекта на v6, как и исключение регулярных выражений из пути, и опциональных параметров. Примеры из документации: Валидные пути: Невалидные пути: Индексные роуты также вернулись к нам из v1-v3. В v4 индексные роуты были заменены на exact. Их назначение — отрендерить некоторый компонент по заданному пути в случае точного совпадения. Пример из документации: Компонент Activity будет отрендерен на месте <Outlet /> внутри компонента Layout. Таким образом, получается удобная композиция вложенного роута, который нужно отрендерить, если путь полностью соответствует родительскому (path = “/” в примере выше отрендерит Layout c Activity внутри). Как уже упоминалось выше, в роутере v1 существовала возможность задать конфиг роутера для всего приложения. Это было особенно удобно для серверного рендеринга, когда на сервере важно знать структуру роутов приложения. Затем эта возможность переместилась в отдельный пакет react-router-config. А теперь снова вернулась! Но уже в основной пакет. Пример из документации: Такая конфигурация позволяет декларативно указать структуру роутов приложения. Есть и другие изменения, но я постарался подсветить наиболее интересные — на мой взгляд — и рассмотреть их через призму истории развития библиотеки. Создатели react-router часто меняют парадигмы, требуя от разработчиков изучения новых подходов, но с каждым разом библиотека становится только удобнее и функциональнее. Другие статьи про frontend для начинающих: Как сделать свой текстовый редактор на React.js Как работают браузеры: навигация и получение данных, парсинг и выполнение JS, деревья спец возможностей и рендеринга Другие статьи про frontend для продвинутых: Как мы выбирали архитектуру микрофронтендов в ЛК для 260 000 сотрудников Пятёрочки Как мы сетапили монорепозиторий с SSR и SPA для Otus.ru Как собрать свою библиотеку для SSR на React  Фронтендер