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
👉 не создавайте единый Контекст для всего, лучше создать несколько независимых контекстов с разными данными
#ссылки #паттерны #проект
Статья, посвященная организации файловой структуры (и не только) проекта: https://blog.openreplay.com/react-architecture-patterns-for-your-projects
Рекомендации:
👉 директория с исходниками называется src
👉 названия папок должны быть понятны всем членам команды, нет жестких правил, можно использовать слова-синонимы, если так проще
👉 для компонентов следует выделять отдельные папки внутри директории components
👉 кроме того, есть общий index.js файл в components, который импортирует все компоненты сразу
👉 для каждого компонента создаем отдельные файлы: для собственно кода, для стилей, для тестов и для Storybook
👉 для наименования файлов и папок хуков используйте префикс use
👉 размещайте каждый хук в отдельной папке в директории hooks вместе с файлом для тестирования
👉 по аналогии с компонентами стоит создать отдельный файл hooks/index.js, который будет импортировать все хуки проекта сразу
👉 следует использовать абсолютные импорты, для этого нужно правильно настроить сборку, указав алиас или корневую директорию
👉 отделяйте логику приложения от отображения, выносите ее в хуки по возможности
👉 константы и утилитарные методы стоит вынести в отдельную директорию utils
👉 не создавайте единый Контекст для всего, лучше создать несколько независимых контекстов с разными данными
#ссылки #паттерны #проект
Openreplay
React Architecture Patterns for Your Projects
Use these React patterns to structure your project and scale them as much as you need
👍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 могут работать в симбиозе, разделяя общее состояние. Например, компонент списка (
Но у
Реализовав этот паттерн мы сможем удобно оформлять список, выделяя каждый элемент в
#паттерны #ссылки
Статья (англ.): 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
, но при этом не придется заботиться о передаче состояния элементам, так как это происходит под капотом.#паттерны #ссылки
Openreplay
3 React Component Design Patterns You Should Know About
Top 3 design patterns used to create React.JS components that you should know about
👍10