Будущее,  Новости,  Ожидание vs Реальность,  Разработка

Эволюция шаблонов проектирования в React

Как эволюционировали шаблоны React в проектировании

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

Я начал работать с React около 3 лет назад. В то время не было устоявшихся практик, изучая которые и следуя которым можно было бы улучшить качество своих разработок.

Сообществу потребовалось около двух лет, чтобы выработать несколько идей. Мы перешли от React.createClassдо ES6 classи чистых функциональных компонентов, отказались от миксин и упростили API

Теперь, когда сообщество больше, чем когда-либо, мы наблюдаем эволюцию нескольких интересных шаблонов проектирования.

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

Итак, начнем!

Условное выполнение (conditional rendering)

Я видел следующий сценарий во многих проектах.

Когда люди думают о React и JSX , они все еще думают о HTML и JavaScript .

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

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

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

Если conditionесть false, второй операнд оператора &&не определяется. Если true— возвращается второй операнд, то есть JSX код .

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

Следует рассматривать JSX как отрицательную часть кода! В конце концов, это просто JavaScript .

Отправка свойств вниз по дереву (passing down props)

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

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

Хорошим способом обойти это, использовать деструктуризацию свойств вместе с оператором распаковки JSX, как вы можете увидеть здесь:

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

Деструктуризация свойств (destructuring props)

Приложение со временем меняется. То же самое происходит с вашими компонентами. Компонент написан несколько лет назад использует состояние, но в текущих условиях он может быть превращен в компонент без состояния. Нередко бывает и обратная ситуация.

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

Этот шаблон облегчает трансформацию компонента. Также вы ограничиваете использования thisвнутри компонента.

Шаблон «Поставщик» (provider pattern)

Мы рассматривали пример где свойства направлялись через другой компонент. А если вам придется направить их в 15 компонентов?

В подобной ситуации полезно будет воспользоваться React Context . Не самая рекомендуемая функция React, но она выполняет свою работу.

Недавно объявили , что в Context появляется новый API, который реализует шаблон поставщика из коробки.

Если вы используете такие библиотеки, как React Redux или Apollo , вы, возможно, знакомы с этим шаблоном.

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

Компонент верхнего уровня — провайдер (provider) — записывает определенные значения в контекст. Детские компоненты, называемые потребителями (consumers), примут эти значения из контекста.

Текущий синтаксис контекста является несколько странным, но будущая версия реализует именно этот шаблон.

Компоненты высшего порядка (high order components)

Обсудим многократное использование кода. Вместе с отказом от фабричной функции React.createElement(), команда React отказалась от миксин . Они были в определенной степени стандартным способом композиции компонентов через композицию простых объектов

Компоненты высшего порядка (HOC) — назначении, чтобы заполнить необходимость в многократном использовании поведения компонентов.

HOC — функция, которая принимает входной компонент и возвращает расширенную / модифицированную версию этого компонента. То что мы называем HOC имеет много имен, я предпочитаю воспринимать его как декораторы .

Если вы используете Redux, вы узнаете функцию connectкак HOC, которая берет компонент и добавляет к нему кучу свойств.

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

Если вам нравится функциональное программирование, вам понравится работать с компонентами высшего порядка. Recompose — замечательный пакет дает вам много таких утилит: withPropswithContextlifecycleи тому подобное.

Посмотрим на очень полезный пример многократного использования функционала.

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

Это пример сквозного функционала реализованного в одном месте для многократного использования во всем приложении.

Однако у компонентов более высокого порядка есть свои недостатки. Каждый HOC создаст дополнительный компонент в структуре React DOM / vDOM. Это, при увеличении приложения, может привести к потенциальным проблемам с производительностью.

Рендеринг свойств (render props)

Несмотря на то что HOC и Render props являются взаимозаменяемыми, Я не могу отдать абсолютное преимущество одному из них. Оба шаблоны используются для улучшения многократного использования и чистоты кода.

Идея заключается в том, что вы передаете контроль над вашей функцией рендеринга другом компонента, который затем передает вам контроль через свойство функции.

Некоторые люди предпочитают использовать для этого динамические свойства , некоторые просто используют this.props.children.

Это все довольно смущает, но посмотрим на простой пример.

Здесь, в качестве свойства, используем children. Мы передаем в компонент <ScrollPosition>функцию, принимает параметр position.

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

В библиотеке React-Motion можно найти много примеров использования этого шаблона.

0 голосов (0 баллов в среднем)
1+
Поделиться

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *