Как передать компонент в качестве пропса в React
2 года назад·4 мин. на чтение
Существует множество способов передать компонент в качестве пропса
Существует множество способов передать компонент в качестве пропса, например, специальный проп
Все верно, но что произойдет, если мы будем иметь дело с компонентом
children
, и паттерн render prop. О них вы можете узнать в видео “Паттерн Render Props в ReactJS”.
В случае с render props мы передаем функцию, которая возвращает компонент. В этой статье рассмотрим как передать просто компонент в качестве пропса.
В этой статье мы увидим простую технику, которая позволяет писать удобные настраиваемые компоненты с помощью простых API, просто используя основные строительные блоки React - компоненты.
Опытный React разработчик использует эту технику естественным образом, но новичку сложно понять этот механизм.
Переизбыток пропсов
Иногда в компонент приходится передавать огромное количество пропсов для того чтобы настроить более мелкие вложенные компоненты, из которых состоит ваш компонент. Возникает переизбыток пропсов. Давайте посмотрим на это на примере. Предположим, есть компонентAlert
с Button
внутри.
Что вы можете сделать, чтобы настроить внутреннийconst Button = ({ onClick, children }) => <button onClick={onClick}>{children}</button>; const Alert = ({ children, onAccept }) => ( <div className="alert"> <div className="alert-header"> <h1>Alert!</h1> </div> <div className="alert-content">{children}</div> <div className="alert-footer"> <Button onClick={onAccept}>Ok</Button> </div> </div> ); <Alert onAccept={() => {}}>Attention!</Alert>
Button
? Если вы новичок в React вы, вероятно, думаете, что правильный способ - это передать проп.
const Alert = ({ children, acceptMessage = "Ok", onAccept }) => ( <div className="alert"> <div className="alert-header"> <h1>Alert!</h1> </div> <div className="alert-content">{children}</div> <div className="alert-footer"> <Button onClick={onAccept}>{acceptMessage}</Button> </div> </div> ); <Alert acceptMessage="Understood!" onAccept={() => {}}> Attention! </Alert>
Confirm
с двумя кнопками? Вам нужно дублировать пропсы и иметь некоторые префиксы, чтобы избежать конфликтов имен пропсов.
Как вы можете себе представить, это будет только ухудшаться по мере роста вашего компонента. Это то, что я имел в виду под переизбытком пропсов.const Confirm = ({ children, acceptMessage = "Ok", rejectMessage = "Cancel", onAccept, onReject }) => ( <div className="confirm"> <div className="confirm-header"> <h1>Confirm</h1> </div> <div className="confirm-content">{children}</div> <div className="confirm-footer"> <Button onClick={onAccept}>{acceptMessage}</Button> <Button onClick={onReject}>{rejectMessage}</Button> </div> </div> ); <Confirm acceptMessage="Yep" rejectMessage="Nope" onAccept={() => {}} onReject={() => {}}> You sure? </Confirm>
Улучшение. Вложенные пропсы
Один из способов немного привести код в порядок — вложить пропсы: по одному пропсу для каждого внутреннего компонента с необходимыми ключами.Это исправляет конфликты, но все становится сложнее. Что произойдет, если я захочу переопределить только один вложенный проп? Чтобы сделать это, нам нужно вручную объединить пропсы со значениями по умолчанию. И что произойдет, еслиconst Confirm = ({ children, onAccept, onReject, acceptButton = { message: "Ok", className: "accept-btn", }, rejectButton = { message: "Cancel", className: "cancel-btn", }, }) => ( <div className="confirm"> <div className="confirm-header"> <h1>Confirm</h1> </div> <div className="confirm-content">{children}</div> <div className="confirm-footer"> <Button className={acceptButton.className} onClick={onAccept}> {acceptButton.message} </Button> <Button className={rejectButton.className} onClick={onReject}> {rejectButton.message} </Button> </div> </div> ); <Confirm acceptButton={{ message: "Yep", className: "accept-btn" }} rejectButton={{ message: "Nope", className: "reject-btn" }} onAccept={() => {}} onReject={() => {}} > You sure? </Confirm>
Button
также содержит Icon
? Следует ли использовать пару новых пропсов (acceptButtonIcon
, rejectButtonIcon
)? Должны ли вы вкладывать их в существующие пропсы (acceptButton.icon
)? Типы или prop types будет очень сложно читать.
Другой подход. Render props
Render props это один из способов сделать ваши компоненты действительно настраиваемыми, вместо того, чтобы добавлять массу пропсов. Давайте попробуем. Напишем три разные версии компонентаConfirm
, который принимает рендер пропсы.
Версия 1. По одному рендер пропсу для каждой кнопки
В первой версии в компонентеConfirm
добавим по одному рендер пропсу для каждой кнопки:
const Confirm = ({ children, onAccept, onReject, renderAcceptButton = onAccept => ( <Button className="accept-btn" onClick={onAccept}> OK </Button> ), renderRejectButton = onReject => ( <Button className="reject-btn" onClick={onReject}> Cancel </Button> ), }) => ( <div className="confirm"> <div className="confirm-header"> <h1>Confirm</h1> </div> <div className="confirm-content">{children}</div> <div className="confirm-footer"> {renderAcceptButton(onAccept)} {renderRejectButton(onReject)} </div> </div> ); <Confirm renderAcceptButton={onAccept => ( <Button className="accept-btn" onClick={onAccept}> Yep </Button> )} renderRejectButton={onReject => ( <Button className="cancel-btn" onClick={onReject}> Nope </Button> )} > You sure? </Confirm>
Версия 2. Один рендер проп для всех кнопок
Вторая версия - это один рендер проп для всех кнопок.const Confirm = ({ children, onAccept, onReject, renderButtons = (onAccept, onReject) => ( <> <Button className="accept-btn" onClick={onAccept}> OK </Button> <Button className="reject-btn" onClick={onReject}> Cancel </Button> </> ), }) => ( <div className="confirm"> <div className="confirm-header"> <h1>Confirm</h1> </div> <div className="confirm-content">{children}</div> <div className="confirm-footer">{renderButtons(onAccept, onReject)}</div> </div> ); <Confirm renderButtons={(onAccept, onReject) => ( <> <Button className="accept-btn" onClick={onAccept}> Yep </Button> <Button className="cancel-btn" onClick={onReject}> Nope </Button> </> )} > You sure? </Confirm>
Версия 3. Один рендер проп для всех подкомпонентов
И, наконец, рендер проп для всего компонента:Последний вариант своего рода крайность. Рендер пропсы настолько мощный, насколько это возможно, но он также имеет свои нюансы. Они позволяют изменить способ рендеринга компонента, но повторно использовать «значения по умолчанию» непросто. Это зависит от того, что визуализирует ваш рендер проп. В предыдущих примерах мы видели три варианта, каждый из которых обеспечивает большую гибкость, но меньшую возможность повторного использования «значений по умолчанию». Однако этот подход может показаться излишним, когда мы просто хотим настроить текст кнопокconst Confirm = ({ children, onAccept, onReject, render = (onAccept, onReject, children) => ( <div className="confirm"> <div className="confirm-header"> <h1>Confirm</h1> </div> <div className="confirm-content">{children}</div> <div className="confirm-footer"> <Button className="accept-btn" onClick={onAccept}> OK </Button> <Button className="reject-btn" onClick={onReject}> Cancel </Button> </div> </div> ), }) => render(onAccept, onReject, children); <Confirm render={() => { // компонент, который появится внутри `Confirm` }} > You sure? </Confirm>
Alert
/Confirm
.
Просто передать компонент
Этот API гораздо более естественен. Это один из тех случаев, когдаconst Confirm = ({ children, onAccept, onReject, acceptButton = <Button>Ok</Button>, rejectButton = <Button>Cancel</Button>, }) => ( <div className="confirm"> <div className="confirm-header"> <h1>Confirm</h1> </div> <div className="confirm-content">{children}</div> <div className="confirm-footer"> {React.cloneElement(acceptButton, { className: "accept-btn", onClick: onAccept })} {React.cloneElement(rejectButton, { className: "reject-btn", onClick: onReject })} </div> </div> ); <Confirm acceptButton={<Button>Yep</Button>} rejectButton={<Button>Nope</Button>} onAccept={() => {}} onReject={() => {}} > You sure? </Confirm>
cloneElement
является правильным инструментом.
Если вам интересно, почему мы всегда передаем обработчики, когда в некоторых случаях имеет смысл просто использовать их напрямую, вы правы. В данном случае это не обязательно.
<Confirm acceptButton={<Button onAccept={() => {}}>Yep</Button>} rejectButton={<Button onReject={() => {}}>Nope</Button>} > You sure? </Confirm>
Структура React приложения
2 года назад·6 мин. на чтение
Как структурировать React приложение и как организовать React приложение.
Не существует единого мнения о том, как правильно организовать React-приложение. React дает вам много свободы, но вместе с этой свободой приходит ответственность за выбор собственной архитектуры. Часто бывает так, что тот, кто создает приложение в самом начале, сваливает почти все в папку
Обратите внимание, что в каталоге
components
. Но есть способ получше. Нужно подходить к организации своих приложений обдуманно, чтобы их было легко использовать, понимать и расширять.
В этой статье рассмотрим вариант структуры Реакт приложения, который интуитивно понятен и может масштабироваться с ростом React приложения. Основная концепция, заключается в том, чтобы сделать архитектуру ориентированной на функциональность, а не на типы. Организовать только общие компоненты на глобальном уровне и собрать в один модуль все остальные связанные сущности вместе.
Технологии
Поскольку эта статья будет носить характер мнения. Сделаем несколько предположений о том, какие технологии будут использоваться в проекте:- Приложение - React (Hooks)
- Глобальное управление состоянием - Redux, Redux Toolkit
- Маршрутизация - React Router
- Стили - CSS, Sass, Styled Components
- Тестирование - Jest, React Testing Library
tests
на верхнем уровне.
Все, что здесь написано, может быть применимо, если вы используете обычный Redux, а не Redux Toolkit. Можно настроить ваш Redux как feature slices.
Также будет удобно визуализировать созданные компоненты с помощью, например, Storybook. Также покажем, как проект будет выглядеть с этими файлами, если вы решите использовать его в своем проекте.
Для примера будем использовать приложение “Библиотека”, который имеет страницу со списком книг, страницу со списком авторов и систему аутентификации.
Структура каталога
Структура каталогов верхнего уровня будет выглядеть следующим образом:assets
- глобальные статические файлы, такие как изображения, svg, логотип компании и т.д.components
- глобальные общие/повторно используемые компоненты, такие как макеты (обертки), компоненты форм, кнопкиservices
- JavaScript модулиstore
- глобальное хранилище Reduxutils
- утилиты, помощники, константы и т.п.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
- собственно компонент ReactComponent.styles.js
- файл стилей для компонентаComponent.test.js
- тестыComponent.stories.js
- файл 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