Руководство по проектированию компонентов React

предисловие

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

Но дизайн действительно просто опыт?

Очевидно, нет, потому что опыт — это итог прошлых проблем, а опыт не имеет стандартов или ограничений. Проекты, команды и предприятия, с которыми сталкивается каждый человек, формируют его собственный уникальный опыт НИОКР. Дизайн фактически основан на этом опыте. стандарты развития подведены непрерывным уточнением и обработкой.

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

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

текст

Краткая история развития front-end компонентов

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

По моему опыту, интерфейсные компоненты примерно прошли эти этапы.

В первые годы существования портала скриптовые компоненты на основе собственного JavaScript

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

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

Интерфейсные компоненты в то время соответствовали представлениям основной разработки о JavaScript в то время — игрушечном языке.

2013 год фактически стал концом таких компонентов, потому что появился jQuery.

С появлением jQuery удобство манипулирования DOM значительно улучшилось, а механизм подключаемых модулей, встроенный в jQuery, перенес интерфейсные компоненты в эпоху подключаемых модулей.

jQuery предоставляет подключаемые компоненты

В то время подключаемые модули jQuery могли значительно повысить эффективность клиентских исследований и разработок. Хотя AJAX был более популярен в то время, роль внешнего интерфейса по-прежнему была больше привязана к уровню визуального взаимодействия. Используемые плагины jQuery были интегрированы и доработаны.На мой взгляд, это был первый прототип поколения общих интерфейсных компонентов.

Содержит самые распространенные карусели, навигационные меню, советы и т. д.

В те дни способность писать карусели от руки была золотым стандартом для тестирования фронтенд-инженера.

Шедевр Angular 1.0

Молодым людям, которые присоединяются к индустрии спустя 15 лет, может быть трудно понять нашу одержимость Angular в то время.Можно сказать, что Angular в значительной степени заложил некоторые основные элементы текущей фронтенд-разработки.

включать

модульный
Одностраничная маршрутизация на основе внешнего интерфейса
ViewModel
управляемый данными

Конечно, самым важным моментом является то, что Angular привносит идею разработки фронтенд-компонентов, отличную от jQuery, и дизассемблирует фронтенд-компоненты на несколько разных типов через встроенную модульную систему.

компонент данных
Инструкции по работе с DOM
компонент с маршрутизацией

Жаль, что хорошие времена длились недолго, и всеохватывающий маршрут Angular окончательно не соответствовал потребностям развития времени.С быстрым подъемом React и Vue монополия превратилась в трехстороннее противостояние.

Виртуальный DOM и JSX

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

Ручное управление DOM неэффективно и сложно в обслуживании.
Разделение в дизайне интерфейсных компонентов, вызванное Angular.

Основанный на React, будь то тип данных или интерактивный тип, внешний вид компонентов унифицирован, все они являются стандартными компонентами React.

Хотя веб-компонент под руководством Google является хитом, в текущей ситуации он немного тупиковый. Тем не менее, я все еще склонен думать, что веб-интерфейсные компоненты — это будущая тенденция. является веб-компонентом, мы можем подождать и посмотреть.

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

Проблемы, существующие в дизайне текущих компонентов React

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

Давайте посмотрим на дизайн компонентов React под другим углом, например, задав вопрос, существует ли какой-либо дизайн для текущих компонентов React?

Когда мы разрабатываем с помощью React, как мы определяем компоненты?

Я предполагаю, что ответ совсем другой, потому что это становится опытом.

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

С точки зрения связи мы определяем компоненты как родительские и дочерние компоненты, а компонент может быть как родительским, так и дочерним компонентом. Итак, каковы стандарты для родительских и дочерних компонентов? Если это параллельная коммуникация, что она должна делать? называться?Брат компоненты?Вложенные, это называется внук, дед внук внук внук внук компонент?
- Кроме того, также не хватает стандартов в реализации компонентной связи, основанной на конвейерах событий — широковещательной, одноадресной, основанной на маршрутизации.
- Или через context/props?Или зацепить this из classComponent?
- Внедрить redux mobx или другую библиотеку управления состоянием?
- С крючком без крючка
С точки зрения среды React могут быть определены различные типы компонентов, такие как classComponent, functionComponent, HOC, контролируемые и неконтролируемые компоненты, а пользовательские хуки считаются компонентами? состояние Каковы стандарты использования?
Бизнес-определение, пользовательский центр, компоненты учетной записи, уведомления и компоненты, связанные с бизнесом для конкретной компании.
Визуальные определения, таблицы, формы, навигация, диалоги

Неопределенность из-за отсутствия стандартов проектирования привела к большим трудностям при проектировании компонентов React.Можно сказать, что из-за этих неопределенностей компоненты React или интерфейсные компоненты вообще не имеют дизайна.

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

Если сравнивать React и Vue, я думаю, что с этой точки зрения React и Vue не одно и то же. React — это UI-библиотека, которая не заботится о реальной разработке. во внешнее состояние можно сделать в этом эффективном рендеринге

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

Но Vue отличается. Vue больше похож на Angular. Это среда разработки, которая включает в себя все аспекты фронтенд-разработки, хотя и немного сложна.

Поэтому я не думаю, что они эквивалентны или сопоставимы.

С этим покончено, давайте вернемся к теме этой статьи, React Component Design.

Давайте попробуем убрать неопределенность в дизайне компонентов React.

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

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

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

визуальный
интерактивность
данные

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

характеристика
- условие
- Функция работы
Визуальное состояние и функции визуального манипулирования
Интерактивное состояние и функции интерактивного действия
Состояние данных и функции работы с данными

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

визуальное состояние
- Непосредственно используется для отображаемого текста/цифр...
- стили, для визуального улучшения
- Динамичный, присоединяйтесь к процессу рисования на основе стиля
Функции манипулирования визуальным состоянием, функции, которые преобразуют входные состояния в визуальные состояния, такие как преобразование
интерактивное состояние
- Флаги, описывающие интерактивные действия, например, открыть, закрыть...
- Опишите состояние между страницами, например запрос по URL-адресу
- Состояние, вызванное изменениями в операционной среде компонента, например onLoading в браузере.
Интерактивные функции управления состоянием, функции управления поведением, которые инициируют взаимодействие пользователя с компонентами, такими как контроллер.
состояние данных
- Данные от внешних входов, таких как интерфейсы
- локально кэшированные данные, localStorage, диск, файл
Функции работы с состоянием данных, функции управления, используемые для связи с внешними данными, такие как вызов API-сервисов.

В соответствии с этими стандартами рациональность некоторых конструкций может быть оценена как уместная при проектировании компонентов React.

Например

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

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

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

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

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

гит-адрес:GitHub.com/kin op112365…

На самом деле, мы практиковали и корректировали этот контент.На данный момент основная цель — сформировать реализуемый стандарт дизайна при разработке компонентов React и обеспечить поддержку R&D.

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

позже

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

Если вы сильно заинтересованы в этом и хотите участвовать в этом процессе, присоединяйтесь к нашей команде, вы можете связаться со мной через WeChat (sh112365362) или оставить сообщение 😁