Классификация компонентов на умные и глупые в React

аботая с React.js или React Native, вы быстро заметите «волшебство» и гибкость компонентов. Компоненты экономят нам много времени, разбивая пользовательский интерфейс на повторно используемый код, а архитектура компонентов делает наш код более легким для чтения и понимания.

Вывод организации компонентов на новый уровень

Чтобы развить эти идеи, мы можем разбить наши компоненты на две категории. Эти две категории имеют несколько названий с немного различающимися концепциями, но все они имеют одну и ту же основную идею. Первоначальная идея разделения компонентов была придумана Дэном Абрамовым, где он назвал их умными и глупыми, но позже пересмотрел их, назвав их контейнерными и презентационными компонентами.

Эта концепция была принята и расширена сообществом React. Помимо умных и тупых, а также контейнерных и презентационных, вы, возможно, слышали о них как о функциональных и классовых компонентах, толстых и худых, экранах и компонентах и ​​т. д. В этой статье мы будем называть их умными и тупыми компонентами.

Что делает компонент умным или глупым?

Умные компоненты — это компоненты уровня приложения, которые выполняют функции и управляют данными, в то время как простые компоненты сосредоточены исключительно на пользовательском интерфейсе.

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

Умные компоненты сосредоточены на том, как всё работает.

К общим характеристикам интеллектуальных компонентов относятся:

• Манипулирует данными. Интеллектуальные компоненты могут получать, фиксировать изменения и передавать данные приложений.
• Вызов Redux, методов жизненного цикла, API, библиотек и т. д. Эти компоненты не просто так называются умными! Они отвечают за вызов библиотек и функционала.
• Управление состоянием. Смарт-компоненты отвечают за управление состоянием и определение времени повторного рендеринга компонента.
• Редко включает стиль. Поскольку немые компоненты сосредоточены на стилях, это позволяет умным компонентам сосредоточиться на функциональности без беспорядка стилей.

Глупые компоненты фокусируются на том, как все выглядит.

Общие характеристики немых компонентов:

• Сосредоточены на пользовательском интерфейсе. Почти все основные компоненты пользовательского интерфейса следует считать немыми (анемичными) компонентами. Примеры включают загрузчики, модальные окна, кнопки, элементы ввода и т.д.
• Принимают свойства (props). Тупые компоненты принимают свойства, позволяющие им быть динамичными и повторно используемыми. Например, вы можете отправить заголовок кнопки в свойствах родительского компонента, чтобы она имела уникальное имя.
• Не имеют зависимостей уровня приложения. Кроме пакетов пользовательского интерфейса, таких как Reactstrap, тупые компоненты не требуют зависимостей.
• Редко включают состояние. Единственный случай, когда тупой компонент имеет состояние — это управление самим пользовательским интерфейсом, а не данными приложения. Некоторыми примерами того, где тупой компонент может иметь состояние, могут быть группы кнопок, вкладки, переключатели и другие элементы пользовательского интерфейса, которые не влияют на данные, а только на пользовательский интерфейс.

Давайте взглянем на наш пример формы входа из предыдущего примера. Почти каждый компонент может быть многоразовым тупым компонентом, включая контейнер, заголовок, поля ввода и кнопку.

Преимущества разделения компонентов

Возможность повторного использования

Хотя мы можем написать один и тот же компонент несколько раз в разных местах приложения, мы можем сэкономить много времени, создав повторно используемый компонент, который принимает свойства (props).

Подумайте о приложении, которое включает в себя регистрацию, вход, забытый пароль, настройки учетной записи и, к счастью, форму регистрации на мероприятие. Это много вкладов! Вместо того, чтобы создавать этот ввод для каждого требуемого экземпляра, мы можем создать многоразовый тупой компонент для импорта на каждый экран и отправлять свойства из родительского компонента, чтобы сделать каждый ввод динамическим.

Гибкость для легкого внесения изменений

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

Давайте на секунду задумаемся о нашем примере выше. Что, если бы мы захотели добавить или даже изменить цвет границы полей ввода для всего приложения. Если бы мы не использовали тупой компонент для нашего ввода нам может понадобиться изменить эту границу в каждом отдельном месте, где находится ввод. Так как мы сделали тупой компонент для ввода нам нужно только изменить границу в одном месте для всего приложения.

Читабельность кода

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

Обеспечивает согласованность и предотвращает дублирование

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

Упрощает решения пользовательского интерфейса

Поскольку все наши компоненты пользовательского интерфейса разделены на простые компоненты, мы можем легко вывести все компоненты пользовательского интерфейса на один экран, где ваш клиент, веб-дизайнер или графический дизайнер могут видеть все сразу.

Легко проверить

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

Когда начинать

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

Обычно, когда я начинаю проект, мне нравится создавать папки в своей srcпапке, чтобы упорядочивать компоненты еще до того, как я начну создавать первый компонент. Этот процесс требует от нас думать о функциональности и будущем этого компонента. Другие предлагают начать создавать исключительно глупые компоненты, пока не достигнете точки, когда вы будете передавать слишком много свойств.

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