React: разделение ответственности
Философия Реакта - блочность, разделение, дробление. Компоненты не должны содержать свалку из сетевого кода, логики его обработки, обработки ошибок, рендеринга... Все эти возможности нужно разносить в отдельные классы, компоненты или функции. Разделяя ответственность и максимально абстрагируя код от данных, мы добиваемся таких выгод, как удобство переиспользования и удержания в голове логики приложения.
Error boundaries тоже могут быть отделены от компонентов, занятых рендерингом. Для этого можно использовать props.children. В этом свойстве объекта props находится код, который написан между открывающим и закрывающим тегами компонента:
<Header>
<ChildComponent />
</Header>
Для обработки ошибок создаем компонент-обертку, которая возвращает своих "детей":
<ErrorBoundry>
<Header />
</ErrorBoundry>.
#React #паттерны #обработка_ошибок
Философия Реакта - блочность, разделение, дробление. Компоненты не должны содержать свалку из сетевого кода, логики его обработки, обработки ошибок, рендеринга... Все эти возможности нужно разносить в отдельные классы, компоненты или функции. Разделяя ответственность и максимально абстрагируя код от данных, мы добиваемся таких выгод, как удобство переиспользования и удержания в голове логики приложения.
Error boundaries тоже могут быть отделены от компонентов, занятых рендерингом. Для этого можно использовать props.children. В этом свойстве объекта props находится код, который написан между открывающим и закрывающим тегами компонента:
<Header>
<ChildComponent />
</Header>
Для обработки ошибок создаем компонент-обертку, которая возвращает своих "детей":
<ErrorBoundry>
<Header />
</ErrorBoundry>.
#React #паттерны #обработка_ошибок
Инкапусляция на практике
Прогаем на уровне интерфейсов, а не реализации.
Это значит, что детали реализации нужно оборачивать в абстракции и выстраивать взаимодействие между ними.
Например, для API чата напишем класс MessageObesrver.
- Придумаем, как класс будет взаимодействовать с приложением: что возвращают публичные методы, какие аргументы принимают.
- Выделим приватные поля и методы, где напишем реализацию с помощью, например, SocketIO.
- Опишем публичные методы, которые будут с ней работать. В них не должно быть ничего от конкретной реализации - они должны дергать приватные поля и методы.
С таким классом мы сможем легко заменить библиотеку или подправить код реализации, не меняя ничего в приложении. Класс оказывается чёрным ящиком с неизменным интерфейсом.
В SOLID это - буква "D": dependency inversion principle (принцип инверсии зависимостей).
#инкапсуляция #паттерны #SOLID
Прогаем на уровне интерфейсов, а не реализации.
Это значит, что детали реализации нужно оборачивать в абстракции и выстраивать взаимодействие между ними.
Например, для API чата напишем класс MessageObesrver.
- Придумаем, как класс будет взаимодействовать с приложением: что возвращают публичные методы, какие аргументы принимают.
- Выделим приватные поля и методы, где напишем реализацию с помощью, например, SocketIO.
- Опишем публичные методы, которые будут с ней работать. В них не должно быть ничего от конкретной реализации - они должны дергать приватные поля и методы.
С таким классом мы сможем легко заменить библиотеку или подправить код реализации, не меняя ничего в приложении. Класс оказывается чёрным ящиком с неизменным интерфейсом.
В SOLID это - буква "D": dependency inversion principle (принцип инверсии зависимостей).
#инкапсуляция #паттерны #SOLID
Open Close principe
Еще один принцип проектирования - отделение изменяемых частей приложения от неизменяемых. Неизменяемая часть не должная изменяться, будучи полностью абстрактной. При этом она должна быть открыта к использованию в максимальном количестве сценариев.
Например, есть задача сделать модальное окно.
Разделим его на две условные части:
- Контейнер с полупрозрачным оверлеем
- Область контента
Создадим для контейнера отдельный компонент, который ничего не будет знать о контенте. Постараемся предусмотреть возможную модификацию: например, компонент будет принимать объект пропов с настройками прозрачности оверлея, размеров и положения на экране. Оставим его опциональным.
Создадим компонент контента и пробросим в модальное окно.
С такой архитектурой компонент модального окна будет легко переиспользован в проекте.
#паттерны #SOLID
Еще один принцип проектирования - отделение изменяемых частей приложения от неизменяемых. Неизменяемая часть не должная изменяться, будучи полностью абстрактной. При этом она должна быть открыта к использованию в максимальном количестве сценариев.
Например, есть задача сделать модальное окно.
Разделим его на две условные части:
- Контейнер с полупрозрачным оверлеем
- Область контента
Создадим для контейнера отдельный компонент, который ничего не будет знать о контенте. Постараемся предусмотреть возможную модификацию: например, компонент будет принимать объект пропов с настройками прозрачности оверлея, размеров и положения на экране. Оставим его опциональным.
Создадим компонент контента и пробросим в модальное окно.
С такой архитектурой компонент модального окна будет легко переиспользован в проекте.
#паттерны #SOLID