В BlaBlaCar команда внешнего интерфейса в настоящее время создает систему дизайна для Интернета, рука об руку с командой UX.

Чтобы дать вам немного контекста, мы также работаем над одностраничным приложением, которое в ближайшем будущем заменит наш старый мобильный веб-сайт и настольный компьютер. Мы используем React как для нашего проекта SPA, так и для нашей библиотеки компонентов системы дизайна с именем kirk.

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

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

Разделение проблем и масштабируемость

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

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

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

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

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

Контекст

Мы начали работать над kirk до того, как проект SPA даже начался.

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

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

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

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

Разрешительный против ограничительного

Мы построили библиотеку по принципу открытого / закрытого:

Программные объекты (классы, модули, функции и т. Д.) Должны быть открыты для расширения, но закрыты для модификации.

Мы также стараемся быть ограничительными (закрытыми) в отношении kirk и разрешительными (открытыми / расширяемыми). Позвольте мне объяснить, мы не хотим, чтобы пользователи библиотеки были ограничены, на самом деле как раз наоборот. Наша конечная цель - дать пользователям возможность делать именно то, что они хотят, максимально простым способом.

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

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

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

Доступность

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

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

Ответная реакция

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

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

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

Адаптация разработчиков

Мы используем kirk для бортовых разработчиков, которые еще не работали с React.

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

npm start запустит сервер сборников рассказов.

В начале проекта мы потратили немало времени на создание помощника по генерации.

Когда мы запускаем npm run kirk, мы получаем:

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

Допустим, мы хотим создать компонент npm run kirk component
Задано два вопроса:

  • название компонента
  • тип компонента, который вы хотите (с двумя вариантами):
    Функциональный компонент или Компонент класса

И это создаст небольшую симпатичную папку с 4 файлами, которые вам нужны:

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

Сгенерированный компонент будет выглядеть так:

Модульные тесты

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

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

Давайте рассмотрим пример нашего компонента Textfield, который является компонентом, который мы используем для рендеринга _15 _, _ 16_.

В этом компоненте у нас есть два взаимодействия для тестирования. Первый заключается в том, что значок креста отображается, когда элемент ввода не пуст, и когда мы щелкаем по нему, он очищает значение. А второй проверит, что мы добавляем значок глаза для отображения пароля, который, по сути, является переключателем между <input type="text"> и <input type="password">.

CSS в JS

Да, вы можете подумать, что ящик пандоры открыт, но на самом деле я не собираюсь много говорить об этом. Сегодня мы используем styled-jsx. Выбирая библиотеку, мы хотели сохранить синтаксис как можно ближе к CSS.

Это сгенерированный файл:

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

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

Нам нужна библиотека, которую можно использовать в любом проекте javascript и которая работает «из коробки».

Будущее

Чтобы завершить эту статью, каковы следующие шаги для kirk?

На момент написания у нас есть 3 текущие темы:

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