В Auth0 мы хотим, чтобы наши клиенты успешно использовали наши решения для аутентификации. Команда инфраструктуры успеха клиентов создает ориентированные на клиентов и внутренние инструменты, которые помогают нам достичь этой цели. React - одна из технологий, которая позволила им делать быстрые итерации в разработке пользовательского интерфейса.
Эта команда создает множество различных проектов, таких как программное обеспечение, на котором работает наш Центр поддержки Auth0, и другие внутренние инструменты, обеспечивающие рабочие процессы внутренней поддержки. Помимо React, они разрабатывают свои проекты с использованием Node.js, hapi.js и Redux. Это команда, в которой много JavaScript, и ее движет быстрое создание качественных функций.
Хотели бы вы стать частью такой команды? В настоящее время мы нанимаем инженеров, чтобы они присоединились к команде инфраструктуры успеха клиентов!
Гильермо Родас - один из инженеров группы инфраструктуры успеха клиентов. Недавно он возглавил проект, известный как Компоненты центра поддержки, который решил проблему, связанную с наличием дубликатов компонентов React на нашем сайте, ориентированном на клиентов, и на сайте внутренних инструментов.
В этом сообщении блога, используя идеи Гильермо, мы собираемся изучить, как команда Account Center использует React and Storybook для оптимизации разработки пользовательского интерфейса и продвижения согласованного брендинга путем создания библиотеки компонентов, которую можно использовать в разных проектах.
Не повторяйся (СУХОЙ)
Центр поддержки Auth0, ориентированный на клиентов сайт, и внутренний сайт Customer Success Tools имеют аналогичные элементы в своих интерфейсах. Например, несмотря на различный бизнес-контекст в каждом интерфейсе, функция Использование квоты в обоих интерфейсах использует одну и ту же структуру для передачи данных пользователю.
Проблема, с которой мы столкнулись, заключалась в том, что эта структура реализовывалась как компонент React отдельно для каждого интерфейса вместо совместного использования реализации. Команда разработчиков дублировала компоненты для решения той же проблемы. Такой подход по своей сути создавал проблемы для разработчиков, поскольку Использование квоты было лишь одной из немногих других функций, которые обладали перекрывающимися интерфейсными архитектурами на наших сайтах.
Наличие дублированного кода - не лучший вариант. Одна версия кода может быть более актуальной, чем другая версия, создавая нечто похожее на состояние гонки вокруг управления версиями кода. Если обнаружена ошибка, ее нужно будет исправить в каждом месте, где используется код, надеясь, что разработчик их все запомнит. Непоследовательный процесс исправления ошибок может умножить количество ошибок и нанести ущерб кодовой базе.
Если вы видите закономерности в своем коде, это« признак того, что он подходит для СУШКИ . Иногда это означает отстранение от экрана до тех пор, пока вы не перестанете читать текст, и буквально искать шаблоны ». (Донавон Уэст, по связям с разработчиками American Express)
Решением этой проблемы с дублированием кода было сделать код СУХИМ (не повторяйся). Нам нужно было написать презентационный компонент один раз, а затем заставить каждую функцию / интерфейс реализовать его из единственного источника правды: библиотеки компонентов.
Как пояснил Марк Перкинс из Clearleft в своем содержательном посте О построении библиотек компонентов, библиотека компонентов - это эффективный и надежный формат для доставки документированного кода и шаблонов проектирования разработчикам и клиентам. React поддается проектированию библиотеки компонентов, поскольку он включает в себя процесс мышления и построения компонентным образом, как это сформулировал Марк.
« React поддается проектированию библиотеки компонентов, поскольку он включает в себя процесс мышления и построения в «компонентной манере, как придумал @allmarkedup из @clearleft »»
"Источник"
Интеграция библиотеки компонентов
Реализация концепции библиотеки компонентов в рамках нашего рабочего процесса была архитектурным решением, которое потребовало от нас дальнейшей разработки стратегии процесса разработки компонентов и функций.
Например, при создании компонента мы начали задавать следующие вопросы:
- Как классифицировать компонент в библиотеке? Должны ли мы вообще иметь категории?
- Как представить прототип компонента? Следует ли использовать пустую страницу с фиктивными данными?
- Должны ли быть представлены разные состояния компонента на его прототипе?
Было критически важно иметь возможность ответить на эти вопросы визуально и организованно, чтобы помочь нам четко повторить процесс разработки функций. Этот процесс обычно состоит из:
- Создание MVP (минимально жизнеспособный продукт) или POC (подтверждение концепции).
- Получение отзывов о MVP / POC.
- Интеграция обратной связи посредством итераций разработки.
Посредством этого процесса мы постоянно показываем, как пользовательский интерфейс представляет данные через свои компоненты, и определяем состояния компонента на основе данных, которые он может представить. Нам нужен был инструмент, который позволил бы нам:
- Создавайте наши компоненты независимо от интеграции каких-либо конкретных функций.
- Просмотрите наши компоненты и их различные состояния.
- Давайте разберем каждый компонент по семействам для облегчения поиска.
- Разместите наши компоненты в центральном месте, чтобы создать концепцию библиотеки.
С React мы уже могли определять компоненты. Нам нужно было что-то для предварительного просмотра, классификации и размещения. К счастью, мы смогли выполнить все эти требования с помощью одного-единственного инструмента: Storybook.
"Источник"
Сборник рассказов: пусть ваши компоненты рассказывают историю
Storybook - это среда разработки UI для UI-компонентов. Он действует как доска, на которой мы можем размещать наши компоненты и визуализировать их в различных состояниях и взаимодействовать с ними, как если бы они находились в реальном приложении. Все это делается изолированно, поскольку Storybook работает вне нашего приложения. Storybook имеет собственную настройку Webpack, которая очень похожа на настройку из create-react-app, но может быть настроена в соответствии с нашими потребностями. Платформа также поставляется со встроенным сервером разработки, который помогает нам предварительно просматривать наши компоненты локально.
Как мы описали, у нас уже был рабочий проект, когда мы решили использовать Storybook для создания библиотеки компонентов. Однако из-за его независимой архитектуры добавление Storybook к нашему существующему проекту не создавало никаких проблем или изменений в нашей существующей кодовой базе.
Мы добавили его, как любой другой npm пакет, а затем импортировали наши существующие компоненты в его платформу. Однако это потребовало от нас по-другому думать о создании, обслуживании и поддержке наших компонентов, продвигающихся вперед - интегративный процесс, который мы называем «разработка на основе сборников рассказов».
С помощью Storybook мы смогли создавать наши компоненты React постепенно изолированно, не беспокоясь о том, чтобы окончательная версия компонента или среда были готовы с самого начала. Он стал для нас инструментом постановки и планирования.
Документирование и проверка болевых точек
У нашей группы инфраструктуры успеха клиентов была вторая проблема: документирование и тестирование всех различных сценариев каждой функции проекта. В наших проектах у нас есть тесты с высоким уровнем покрытия, которые проходят через конвейер непрерывной интеграции, настроенный в Heroku.
По словам Гильермо:
У нас есть сильные тесты вместе с непрерывной интеграцией, потому что мы хотим хорошо провести выходные, не беспокоясь о сбоях наших производственных сборок. Самая распространенная фраза в «запросе на слияние (PR): Пожалуйста, добавьте тесты.
Помимо тестирования, мы придаем большое значение документированию кода. Это наше наследие для всех, кто будет работать с нашей кодовой базой в будущем. К счастью, наличие библиотеки компонентов, такой как Storybook, позволяет нам документировать компоненты визуально и декларативно. Storybook предоставляет разработчику всю информацию, необходимую для понимания структуры и состояния компонента.
Тестировать сложно. Для большинства разработчиков тестирование - это печальная история. Что ж, больше нет! Благодаря современным и мощным инструментам наша история тестирования стала счастливой.
В React есть разные аспекты тестирования пользовательского интерфейса. Мы классифицируем их следующим образом вместе с их инструментарием:
Storybook интегрируется с Jest Snapshot через надстройку под названием StoryShots. StoryShots добавляет автоматическое тестирование снимков Jest в нашу базу кода, используя наши существующие истории из сборника рассказов в качестве входных данных для тестирования снимков Jest.
Когда наш конвейер Heroku CI настроен, каждый раз, когда кто-то делает PR с новым компонентом для нашей Storybook, запускается это автоматическое тестирование и создается визуальный предварительный просмотр нашего приложения. Это позволяет нам выполнять структурное и стилевое тестирование намного быстрее.
Обмен нашими инженерными знаниями
Мы рады подробно рассказать, как выглядит наш процесс разработки и как он положительно повлиял на наш опыт разработчиков в создании, тестировании и документировании пользовательских интерфейсов. Сотрудничая напрямую с Гильермо, мы собираемся изучить, как использовать Storybook с React, наш подход к разработке на основе Storybook, оптимизацию, которую мы сделали для тестирования компонентов React, и рождение команды Design Systems, которая эффективно объединяет дизайн и разработку.
Следите за обновлениями, чтобы узнать больше об этой серии React на Auth0! Вы можете оставаться на связи, подписавшись на @ auth0 в Твиттере, подписавшись на нашу рассылку новостей или время от времени проверяя этот блог. Мы надеемся, что вам понравится предстоящий контент.
О Auth0
Auth0, мировой лидер в области идентификации как услуги (IDaaS), предоставляет тысячам корпоративных клиентов универсальную платформу идентификации для их веб-приложений, мобильных устройств, Интернета вещей и внутренних приложений. Его расширяемая платформа легко аутентифицирует и защищает более 1,5 млрд логинов в месяц, что делает ее любимой разработчиками и доверием глобальных предприятий. Штаб-квартира компании в США в Белвью, штат Вашингтон, а также дополнительные офисы в Буэнос-Айресе, Лондоне, Токио и Сиднее обслуживают клиентов из более чем 70 стран.
Для получения дополнительной информации посетите https://auth0.com или подпишитесь на @ auth0 в Twitter.
Первоначально опубликовано на auth0.com.
