Реагировать миксины. Они исчезают с ES6. Это плохо? Мне часто казалось, что React дает миксину слишком много функциональности и мощности. Хотя миксин принимает контекст компонента, с которым он связан, у него есть свои собственные методы жизненного цикла. Дать чему-то, что не имеет своего собственного контекста, возможность установить состояние в компоненте, к которому он прикреплен, мне кажется плохой идеей.
Миксины как посредники
Однако я использовал примеси React для управления состоянием моего приложения при работе с хранилищами в архитектуре Flux. Это популярная идея. Размещение кода с такой важной функциональностью, как управление состоянием, тем не менее, отдельного компонента, внутри чего-то столь же непрозрачного, как миксин React, не выглядит хорошей практикой. Критически важные функции должны быть легко найдены. Однако с учетом этих соображений полезно иметь один миксин, который действует как посредник между двумя секторами приложения. Хотя он имеет дело с состоянием приложения, он только один и действует как хороший механизм для отделения представления от хранилищ.
Помимо грандиозных возможностей и большого потенциала миксина React, они обеспечивают простое решение проблемы, которая возникла у меня с React с самого начала. Несмотря на то, что сам способ определения классов React, по-видимому, продвигает принцип «Не повторяйся» и «Разделение интересов», по-прежнему довольно легко объединить множество одинаковых функций в разных компонентах React.
В чистом JS, используемом в объектно-ориентированном стиле, вы можете абстрагировать эту общую функциональность в класс, от которого наследуется каждый объект. Однако React, похоже, не одобряет этот стиль программирования, приклеивая прототип объекта к конструктору. Класс ES5 React помещает свойства и методы за пределы спецификации класса React в прототипе компонента. Методы, которые определяет разработчик, технически являются частью прототипа.
Однако разработчику не рекомендуется разбирать компонент React и использовать отдельные функции (буквально) вне контекста. Во имя сохранения инкапсуляции каждого компонента пользовательского интерфейса также не используется наследование в классическом смысле, используемом с компонентами пользовательского интерфейса React. Это одно из мест, где я чувствую, что React утверждает композиционный подход к разработке и не поощряет объектно-ориентированное наследование прототипов. Но имеет ли смысл определять методы с одинаковой/похожей функциональностью для нескольких компонентов ради несвязанного модульного кода?
Миксины как служебные функции и демпферы компонентов
Говоря более конкретно, примеси React помогли мне абстрагироваться от широко используемых блоков кода, таких как запросы к базе данных, вызовы API и обработка/форматирование данных. Я использую их для создания служебных функций, которые не заботятся о состоянии приложения, а просто выполняют свою работу. Миксины React как «утилиты» предоставляют базовые услуги, которые могут понадобиться каждому компоненту в тот или иной момент. Я пишу их как блоки кода plug and play. Моя главная цель при создании одного из них заключалась в том, что для запуска требуется только, чтобы параметры его функций были полными и правильно типизированными.
Они — часть моего грандиозного плана сделать функциональность всего, что я пишу в React, очевидной. Все, что напрямую приведет к «просмотру» кода, будет помещено в компонент React. Все остальное, что связано с передачей данных вокруг клиента, взаимодействием с сервером и API, будет выполняться в выделенных миксинах. Код компонента React принимает состояние приложения и решает, когда показывать, какая кнопка и миксины получают и перемещают информацию.
На последнем хакатоне, который я посетил, я набросал миксины вместе с компонентами React для себя и моих товарищей по команде. Хотя непрозрачный фасад миксина скрывает его фактическое содержание, имя миксина служит псевдонимом для функции или набора функций, которые достигают определенной цели. Цель. Это очень полезно для рефакторинга, проектирования и создания приложения. Каждый из них представляет собой аккуратную сумку с функциональностью. Если будет выбран другой метод для достижения определенной цели, функции в примеси обеспечивают нормализующий интерфейс для новой реализации.
