Что должно быть включено во внутреннюю библиотеку компонентов
20 октября 2022 г.При работе с внутренними библиотеками компонентов бесчисленное множество разработчиков не хотят принимать решительные решения, беспокоясь об общем влиянии их выбора. Это опасение небезосновательно, потому что внутренние библиотеки компонентов обычно используются и поддерживаются несколькими командами, которые имеют большую автономию в отношении стилей кодирования и могут иметь различные мнения относительно области применения и стандартов. Эти команды могут даже различаться по размеру и состоять из широкого круга членов с разной квалификацией, поэтому создание того, что может использовать младший разработчик, может полностью отличаться от кодовой базы, предназначенной для опытных пожилых людей. При таком несоответствии вполне естественно, что на вопрос, какие компоненты следует включить в нашу внутреннюю библиотеку компонентов, сложно ответить.
Как человек, который был там, я знаю, что библиотеки компонентов не подходят для всех проектов. Требуется время и усилия, чтобы создать кодовую базу, которую разработчики могут использовать для создания невероятных продуктов для своих конечных пользователей. Работая с различными командами, мне удалось получить важную информацию о создании библиотек компонентов. Несмотря на то, что может быть множество факторов, которые необходимо учитывать, я хочу поделиться некоторыми советами о том, как я подхожу к этой проблеме. Надеюсь, это поможет вам решить, какие компоненты включить во внутреннюю библиотеку компонентов.
Обратите внимание на свой дизайн (систему)
Одна из первых вещей, которую я делаю, работая над реализацией внутренней библиотеки компонентов, — это обращаюсь к команде дизайнеров и прошу их показать все свои проекты. Если у компании уже есть спецификация дизайн-системы, я выделю для себя свою работу, и даже если дизайн-системы нет, я подробно рассмотрю дизайн продукта.
Дизайн — это то, что я проверяю в первую очередь, чтобы получить больше ясности при определении реализации компонента. Наблюдение за всеми элементами пользовательского интерфейса и их поведением в одном месте позволяет мне заметить, какие из них могут быть одним компонентом с точки зрения кода, и помогает мне решить, имеет ли смысл предоставлять такой компонент для всех для использования через компонент. библиотека.
Это также может помочь взглянуть на используемую номенклатуру — наличие одного и того же языка между отделами дизайна и разработки помогает при работе с несоответствиями дизайна и кода, которые обычно возникают независимо от того, насколько хороши обе команды. Сохранение согласованности номенклатуры может помочь предотвратить дублирование шаблонов пользовательского интерфейса в коде (например, наличие и таблетки, и тега).
Если вы создаете внутреннюю библиотеку компонентов вашей компании впервые, создать список компонентов, которые будут включены, будет намного проще, если вы используете имеющиеся в вашем распоряжении файлы проекта.
В качестве альтернативы, если вы работаете над функцией и планируете реализовать новый компонент как часть внутренней библиотеки компонентов, просмотр файлов дизайна поможет вам определить, существует ли уже элемент пользовательского интерфейса, аналогичный тому, что вы создаете. полностью устраняя необходимость в новом компоненте.
Проверить существующие библиотеки компонентов
Прежде чем переходить к коду, имеет смысл проверить другие существующие библиотеки компонентов, особенно если ваша команда знакома с конкретной сторонней библиотекой компонентов. Вы делаете это по двум причинам: чтобы проверить, какие компоненты существуют в их кодовой базе, и изучить их API.
https://giphy.com/gifs /bill-murray-space-jam-feel-free-to-use-14jQC2AONxNBHq?embedable=true
Просмотр существующих библиотек компонентов упрощает определение компонентов, которые вы, возможно, захотите добавить в свое внутреннее решение. Вы можете перекрестно сравнить файлы дизайна и список компонентов, которые вы хотите внедрить, со сторонней библиотекой компонентов. Это может помочь вам определить любые функциональные пробелы, которые могут возникнуть из-за отсутствия элементов пользовательского интерфейса. Это также помогает классифицировать визуально похожие компоненты внутренней библиотеки в один.
Подробное изучение API поможет вам решить, как предоставить определенную функциональность в вашей кодовой базе. Проверка API может быть рекомендована, чтобы свести к минимуму пробелы в обучении вашей команды или установить определенные стандарты.
Имейте в виду, что цель этого совета — не слепо следовать вариантам реализации сторонних разработчиков, а учиться на их выводах.
При необходимости используйте сторонние компоненты
Даже если вы создаете внутреннюю библиотеку компонентов, это не означает, что вам нужно реализовать каждый компонент и каждое поведение с нуля. Если в вашем случае подходит большинство сторонних компонентов, используйте то, что можете, и сосредоточьте свои усилия на реализации на тех, которые не так просто стилизовать или которые имеют другое поведение.
Хорошими примерами являются интерактивные таблицы или средства выбора даты. Эти компоненты довольно сложны для реализации, поэтому, если ключевые функции вашего продукта не вращаются вокруг них, имеет смысл ввести зависимость, которая хорошо их реализует (например, Airbnb Datepicker 😀).
Чтобы ограничить влияние зависимости на ваш код, внедрите оболочку вокруг компонента, скрывающую эту зависимость от потребителей вашей внутренней библиотеки компонентов. Оболочка гарантирует, что API этого компонента согласуется с теми, которые ваша команда создала сама, и упростит переключение между различными сторонними реализациями, если вам это понадобится.
Использовать существующие шаблоны проектирования и руководства по виджетам
Веб-пользователи ожидают, что компоненты, которые выглядят определенным образом, будут вести себя определенным образом. Например, нажатие на <select> должно предоставить пользователю список параметров, а при пролистывании галереи должно отображаться следующее изображение.
Компоненты, которые вы реализуете, должны охватывать конкретные варианты использования клавиатуры и сенсорной панели и быть доступными для всех. Этот процесс становится более простым, если следовать руководству, в котором собраны все сведения и приведены примеры кода, которые можно протестировать.
Помимо того, что это руководство позволит вам быть более подробным, оно также может показать вам, какие компоненты являются хорошо известными и часто встречающимися шаблонами или виджетами, которые, возможно, следует включить во внутренние библиотеки компонентов.
Мне больше всего нравится читать Руководство по авторскому праву ARIA. Если дизайн содержит внешний вид, эквивалентный виджету, указанному в руководстве, я обычно рекомендую включить такой компонент во внутреннюю библиотеку компонентов.
Не думайте о внутренней библиотеке компонентов как об общей папке
Убедитесь, что вы и все члены вашей команды понимаете, что внутренняя библиотека компонентов не является общей папкой. Основная идея библиотеки компонентов заключается не в сокращении дублирования кода (хотя это и приятный побочный эффект), а в предоставлении разработчикам многократно используемых шаблонов пользовательского интерфейса.
https://giphy.com/gifs/theoffice-the -office-tv-frame-toby-vyTnNTrs3wqQ0UIvwE?embedable=true
Обычно то, что происходит во время разработки в отношении общей папки: люди, работающие над проектом, замечают схожую структуру кода или поведение разных компонентов, после чего извлекают их в одно место, что делает код более доступным для использования другими. Этот тип извлечения может и, вероятно, произойдет с библиотеками компонентов, но не позволяйте правилу трех (из дублирование кода) влияют на выбор компонентов. При рассмотрении вопроса о том, включать компонент во внутреннюю библиотеку компонентов или нет, следует сосредоточиться на том, может ли кто-то его использовать, а не использовал ли кто-то (достаточно раз).< /p>
Например, допустим, у вас есть галерея в проекте электронной коммерции. Эту галерею можно использовать только для демонстрации продукта, когда команда разработчиков получает спецификацию дизайна. Однако это не должно быть дискриминационным фактором для исключения его из внутренней библиотеки компонентов. Галерея, по своей сути, является компонентом для отображения нескольких изображений - шаблон, достаточно общий для многократного использования, и поэтому, я бы сказал, что он должен быть частью внутренней библиотеки компонентов, независимо от того, сколько раз он используется. используется во всем дизайне. Сосредоточьтесь на назначении компонента, а не на какая команда будет его использовать или сколько раз он будет использоваться.
Заключение
Каждая библиотека компонентов уникальна, как и каждая команда. Лучшие внутренние библиотеки компонентов — это те, которые подходят разработчикам, использующим их для создания продуктов. При принятии решения о содержимом вашей внутренней библиотеки компонентов обязательно интегрируйте свой опыт в этой области, а также знания команд, использующих ее.
Если вы сомневаетесь, проверьте существующие библиотеки компонентов, но не следуйте слепо их коду. Используйте его в качестве руководства, а не как правило.
Никто лучше вас не знает вашу кодовую базу и членов команды. ❤️
Также опубликовано здесь
Оригинал