Библиотека фронтендера | Frontend, JS, JavaScript, React.js, Angular.js, Vue.js
21.9K subscribers
2.68K photos
181 videos
40 files
5.05K links
Все самое полезное для фронтенда в одном канале.

По рекламе: @proglib_adv

Учиться у нас: https://proglib.io/w/77178ed4

Для обратной связи: @proglibrary_feeedback_bot

РКН: https://gosuslugi.ru/snet/67a5b6884689c2151c820bb4
Download Telegram
Forwarded from React Junior
Архитектурные паттерны React для ваших проектов

Статья, посвященная организации файловой структуры (и не только) проекта: https://blog.openreplay.com/react-architecture-patterns-for-your-projects

Рекомендации:

👉 директория с исходниками называется src
👉 названия папок должны быть понятны всем членам команды, нет жестких правил, можно использовать слова-синонимы, если так проще
👉 для компонентов следует выделять отдельные папки внутри директории components
👉 кроме того, есть общий index.js файл в components, который импортирует все компоненты сразу
👉 для каждого компонента создаем отдельные файлы: для собственно кода, для стилей, для тестов и для Storybook
👉 для наименования файлов и папок хуков используйте префикс use
👉 размещайте каждый хук в отдельной папке в директории hooks вместе с файлом для тестирования
👉 по аналогии с компонентами стоит создать отдельный файл hooks/index.js, который будет импортировать все хуки проекта сразу
👉 следует использовать абсолютные импорты, для этого нужно правильно настроить сборку, указав алиас или корневую директорию
👉 отделяйте логику приложения от отображения, выносите ее в хуки по возможности
👉 константы и утилитарные методы стоит вынести в отдельную директорию utils
👉 не создавайте единый Контекст для всего, лучше создать несколько независимых контекстов с разными данными

#ссылки #паттерны #проект
👍12👎1
Forwarded from React Junior
3 паттерна для создания React-компонентов

Статья (англ.): https://blog.openreplay.com/3-react-component-design-patterns-you-should-know-about

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

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

Презентационные компоненты отвечают только за внешний вид. Они получают данные через пропсы, выводят их и никак не зависят от других компонентов. Очень часто презентационные компоненты не имеют состояния, но также могут отслеживать какое-то состояние, связанное с интерфейсом (например, текст в поле ввода). Примеры презентационных компонентов: список элементов, поле ввода.

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

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

Провайдер

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

Пример Провайдера в React - это контекст. Мы создаем объект контекста с нужными данными (например, цветовой темой приложения), оборачиваем все приложение в провайдер этого контекста и в нужных местах связываемся с ним с помощью хука useContext, или свойства contextType, или Context.Consumer.

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

Составные компоненты

Компоненты в React могут работать в симбиозе, разделяя общее состояние. Например, компонент списка (Menu) и компоненты отдельных элементов списка (MenuItem). Вынесение элементов в отдельные компоненты может быть удобно с точки зрения передачи пропсов и структуризации кода.

Но у Menu и MenuItem есть общее состояние - активный элемент, оно должно храниться в компоненте Menu, значит, его нужно передать во все вложенные компоненты MenuItem. Об этом должен позаботиться сам компонент списка (например, с помощью React Context), тогда мы получим составной компонент (compound component).

Реализовав этот паттерн мы сможем удобно оформлять список, выделяя каждый элемент в MenuItem, но при этом не придется заботиться о передаче состояния элементам, так как это происходит под капотом.

#паттерны #ссылки
👍10