Мы используем веб-компоненты на GitHub

Мыиспользуемвебкомпонентынаgithub

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

Мы широко используем веб-компоненты на GitHub. У нас есть более десятка веб-компонентов с открытым исходным кодом и еще десятки с закрытым исходным кодом.

Как мы сюда попали

Когда GitHub был запущен более десяти лет назад, у нас была скромная клиентская база кода, которая в основном использовала jQuery. Десять лет и почти 2014, 09, у нас была большая кодовая база внешнего интерфейса, которая начинала показывать проблемы роста. В конечном итоге мы отказались от jQuery ( по причинам, которые мы подробно описали в сообщении в блоге в то время ) и начали использовать новый технологии, которые могут лучше решить наши проблемы.

Мы начали баловаться новой технологией под названием Веб-компоненты , a набор встроенных браузерных технологий, которые позволяют разрабатывать настраиваемые элементы HTML, постепенно улучшенные с помощью JavaScript.

Мы решили использовать веб-компоненты, потому что наша кодовая база уже была структурирована в компонент -подобное поведение. Тем не менее, по мере роста монолита GitHub мы увидели необходимость в улучшении инкапсуляции до того, как интерфейс станет неуправляемым – и веб-компоненты будут соответствовать всем требованиям. Веб-компоненты предлагали лучшую переносимость и инкапсуляцию, чем наши существующие варианты поведения JavaScript. Мы были счастливы поэкспериментировать с веб-компонентами вместе с нашей существующей интерфейсной инфраструктурой, поскольку это не требует каких-либо предварительных затрат или «бай-инов» для конкретной платформы.

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

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

Улучшение того, как мы разрабатываем компоненты

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

Компонент просмотра

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

Катализатор

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

Catalyst черпал вдохновение из превосходного Библиотека стимулов и Google LitElement . Он разработан с учетом конкретных потребностей наших разработчиков. Наши внутренние исследования опыта разработчиков показали успех в обеспечении существенного улучшения в создании кода по сравнению с устаревшими шаблонами.

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

Оснастка

Мы предоставляем разработчикам набор конфигураций линтера с открытым исходным кодом. Для общих практик кода у нас есть eslint-plugin-github . У нас также есть eslint-plugin-custom-elements , который обеспечивает дополнительные проверки для создания веб-компонентов. Извлечение их в репозитории с открытым исходным кодом позволяет нам удалить код из монолита, но оставаться последовательным.

У нас также есть внутренние тесты, чтобы убедиться, что разработчики следуют лучшим практикам и гарантируют, что они не продолжают использовать устаревшие шаблоны и модели поведения. Один из наших тестов гарантирует, что устаревший шаблон «facebox» не добавлен в кодовую базу, и предлагает использовать элемент как альтернатива.

  class FaceboxDeprecationTest ?  s ["']? facebox |  REGEX_FOR_DATA_FACEBOX =% r | data-facebox  s =>?  S |  def test_limit_facebox actual_rel_facebox = grep (REGEX_FOR_FACEBOX_BINDING, параметры:% w [-In], пути:% w [app//*.erb]) actual_data_facebox = grep (REGEX_FOR_DATA_FACEBOX, параметры:% w [-In], пути:% w [app//*.erb]) count = actual_rel_facebox.count (" n") + actual_data_facebox.count (" n") assert_operator count,: <=, EXPECTED_NUMBER_OF_FACEBOXES, << - EOL Похоже, вы добавили лицевую панель.  Вместо этого используйте .  Если вы должны увеличить EXPECTED_NUMBER_OF_FACEBOXES в этом тесте, пожалуйста, / cc @ github / ui-frameworks-reviewers в своем запросе на вытягивание, так как мы можем помочь!  Спасибо.  EOL assert_equal EXPECTED_NUMBER_OF_FACEBOXES, count, << - EOL Похоже, вы удалили лицевую панель.  ТЫ ОБАЛДЕННЫЙ!  💖 💖 💖 💖 💖 Пожалуйста, уменьшите EXPECTED_NUMBER_OF_FACEBOXES в этом тесте и побалуйте себя чем-то особенным.  Ты заслуживаешь это.  EOL конец конец  < Test::Fast::TestCase  EXPECTED_NUMBER_OF_FACEBOXES = 44  # Find facebox triggers set with rel=facebox, in either HTML attributes or  # as part of hash assignment (for rails helpers)  REGEX_FOR_FACEBOX_BINDING = %r|rels*[=:]> 

Наш новый жизненный цикл веб-компонентов

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

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

Начните с Catalyst

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

Регистрация веб-компонента может повлечь за собой некоторые шаблонный шаблон, но мы упрощаем его с помощью соглашений об именах и добавлением Декораторы TypeScript . Действия в Catalyst упрощают прослушивание событий, чем управление глобальными прослушивателями событий. Мутирующий целей для существующего HTML лучше, чем отображение HTML-шаблонов в браузере.

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

Перед извлечением компонента Catalyst мы удаляем специфичные для Catalyst функции. и преобразовать его в простой веб-компонент. Зачем удалять библиотеку, которая, по утверждениям команды, упрощает написание веб-компонентов? Хотя Catalyst полезен для разработчиков, мы хотим, чтобы наши компоненты не имели зависимостей. Требование от разработчиков, не входящих в организацию GitHub, понимать Catalyst, прежде чем вносить код обратно в компонент, является дополнительным трением, которого мы не хотим вызывать.

Компоненты с открытым исходным кодом означают особые требования

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

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

Отличным примером компонента, прошедшего жизненный цикл с открытым исходным кодом, является элемент. Команда разработчиков продукта в GitHub недавно создала прототип пользовательского интерфейса на основе терминала, в котором текст выглядит так, как будто его кто-то набирает. В предыдущем проекте мы использовали отличный и надежный typed.js для анимации набора текста, и команда изначально обратилась к этой библиотеке. снова.

Части пользовательского интерфейса, которые уже были созданы командой, были легковесными, и наш инструментарий определил, что добавление напечатанный.js на страницу увеличит размер пакета в пять раз. Команда UI Systems спросила Команда разработчиков продукта рассмотрит другие варианты. Мы обнаружили, что функциональные возможности, необходимые для этого приложения, были достаточно ограничены, поэтому стоило попытаться создать его самостоятельно.

Команда разработчиков продукта написала первую версию нашего собственная анимация набора текста для нового пользовательского интерфейса. Использование Catalyst заняло менее суток и менее 831 строк кода. Понимая, что этот эффект могут использовать другие команды, мы решили провести его через этапы жизненного цикла. Мы реорганизовали компонент так, чтобы он не имел зависимостей, «выбросили» его из библиотеки Catalyst и открыли исходный код компонента как .

Полученные результаты

В целом, мы в восторге от изменений, которые мы внесли в интерфейс GitHub с момента нашего последнего поста. . Согласно проведенным нами внутренним опросам разработчиков, наши разработчики довольны Catalyst и ViewComponent!

Разработчикам нравится инкапсуляция ViewComponent, что упрощает тестирование Пользовательский интерфейс и повышение уверенности разработчиков. Разработчики считают, что Catalyst - это долгожданное изменение от «старого стиля» JavaScript без массового перехода к другой структуре или парадигме.

Что дальше?

Мы продолжаем выпускать более общие поведенческие веб-компоненты с открытым исходным кодом под названием «Элементы GitHub». У нас есть коллекция этих элементов на https://github.com/github/github-elements , которая синхронизируется с

наша страница на webcomponents.org .

Мы мы воодушевлены будущим веб-компонентов и продолжаем отслеживать предлагаемые изменения в спецификации HTML. Два предложения, которые нас больше всего волнуют в наши дни, - это Части шаблона и Декларативные предложения Shadow DOM . Эти предложения упростят инженерам доставку веб-компонентов и решат некоторые общие проблемы, которые у нас есть с текущим состоянием веб-компонентов. Мы реализовали минимальные жизнеспособные части частей шаблона в ponyfill , который сейчас используется в производстве сегодня, и мы очень хотим, чтобы он получил поддержку более широкого сообщества.

Специальная благодарность

Спасибо Кейту Сиркелю за то, что он положил начало этому посту, Бену Скофилду и Джоэлю Хоксли за его рецензирование, а также Нику Холдену за работу с нами по извлечению элемент.

Leave a comment

Your email address will not be published. Required fields are marked *