Как добиться повторного использования React компонентов (Перевод)


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


    Что подразумевается под повторным использованием кода?


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


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


    Walmart состоит из нескольких брендов, включая Sam's Club, Asda, и региональных филиалов, таких как Walmart Canada и Walmart Brazil. Эти бренды имеют десятки приложений, созданных и поддерживаемых сотнями разработчиков.


    Поскольку каждый из этих брендов занимает свое место в Интернете, у каждого есть разработчики, работающие над компонентами, которые являются общими для всех брендов Walmart, например: карусель, Breadcrumbs, всплывающие окна, компоненты форм оплаты. Дублирование той же самой работы, которая сдалала другая команда — трата времени и денег, а также допускается возможность совершить те же ошибки разными командами. Устранение дублирования позволяет разработчикам быть более сфокусированными на проектах.


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


    Повторное использование React компонентов в @WalmartLabs


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


    Инструменты для повторного использования кода


    Первая задача связана с техническими средствами совместного использования кода. Компоненты должны версионироваться, легко устанавливаться и обновляться. Мы завели отдельную GitHub организацию, куда мы поместили все React компоненты. В настоящее время компоненты объединены в репозиториях на основе команд, которые их создали, но мы находимся в процессе перехода к более функциональному виду, например: репозиторий «Navigation», содержащий компоненты «Breadcrambs», «Tabs» и «Sidenav Links». Мы держим все компоненты во внутреннем npm реестре, что позволяет устанавливать определенные версии компонентов, гарантируя, что приложение внезапно не поломается при обновлении компонента.


    Поскольку код используется несколькими командами, нам необходимо соблюдать согласованную структуру в пакетах и стандарты для сотен компонентов. Поэтому мы пришли к созданию Electrode Archetypes для компонентов и приложений. Archetypes содержат eslint, babel и webpack конфигурационные файлы и являются основным местом, где мы управляем зависимостями с помощью Gulp задач и npm скриптов. Начинать разработку со застандартизированной структурой позволяет нам поддерживать высокие стандарты во всей компании, также это добавляет разработчикам уверенности в чужом коде и увеличивает шансы повторного использования кода. Также повышает уверенность налаженные Continious Integration и Continous Deployment процессы, которые запускают Eslint, тесты производительности и кроссбраузерные тесты, используя разные разрешения экрана. При создании пулл реквестов Continious Integration может публиковать бета-версии компонентов и запускать функциональные тесты всех приложений, использующих этот компонент. Это дает гарантии, что пулл реквест ничего не сломает.


    Meta команда


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


    Это было хорошое начало, но мы все же еще видели дополнительные возможности как улучшить повторное использование кода.


    Проблема обнаружения сотен компонентов


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


    Нашим ответом на эту задачу был Electrode Explorer, о котором я рассказывал в предыдущем посте. Explorer позволяет разработчикам просмотреть сотни компонентов, доступных в @WalmartLabs, читать их документацию и видеть, как они реально выглядят в браузере, и даже просмотреть предыдущие версии компонента и увидеть, как они менялись с течением времени. Поскольку Electrode Explorer предоставляет веб-интерфейс для всех компонентов React в организации, разработчикам не нужно запускать npm install для того, чтобы увидеть и повзаимодействовать с компонентом.


    Трудности полного избавления от дублирования


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


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


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


    Важность Continious Integartion и Continious Deployment (CI / CD)


    Мы столкнулись с одной серьезной проблемой, что пока одна команда будет работать над компонентом — это может навредить приложению другой команды. Если вы не заблокировали компонент на определенной версии в проекте, ваш CI / CD может сообщить о провалившихся тестах, потому что компонент был изменен в другой команде. Это очень неприятные ситуации, которые приводили многие команды к блокированию компонентов на определенных версиях, что не позволяет даже принимать новые патчи для компонента.


    Вот именно в этот момент CI / CD проявляет себя во всей красе. Когда компонент обновляется, автоматизация должна запускает тесты приложениях, которые использую ту же основную версию компонента. Тесты запускаются даже если приложение заблокировало компонент на определенной версии. CI / CD система создает пулл реквест на запрос обновления заблокированной версии до новой, если тесты прошли успешно. В случае провалов на тестах команды получают уведомления, и позже совместно разрешают проблему.


    Inner source философия


    Основополагающим фактором для многократного использования стало наше понимание философии open source / inner source, описанной Лораном Десегуром в предыдущей статье. WalmartLabs уже много лет активно использует и разработывает open source, чему свидетельствуют проекты, как Hapi, OneOps и Electrode. За пределами компании не так заметно, но мы очень привержены к модели inner source, которая, по сути, является закрытой реализацией open source. В inner source подходе ни одна команда или разработчик «не владеют» компонентом — все компоненты являются общими для всей организации. Это уменьшает возможные ошибки и позволяет разработчикам сосредоточится на улучшение существующих компонентов.


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


    Выводы


    Повторное использование — это не просто техническое решение, но и философский подход, который требует организационной приверженности и имеет долгосрочные последствия. В WalmartLabs мы видели преимущества, которые он может принести — сейчас мы переводим SamsClub.com на платформу Electrode, и наши разработчики повторно используют сотни компонентов от Walmart.com с настройками для Sam's Club.


    Расскажите вашу историю повторного использования — с какими проблемам вы столкнулись? Как вы их решали? Что хотели бы улучшить в дальнейшем?


    Оригинальный текст статьи

    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 13
      +4
      Хм… Прочитал… Как же добиться повторного использования компонентов React?
        0
        Точно прочитали? :)
        От себя скажу, что подход из статьи хорошо подходит, когда нужно поддерживать и разрабатывать несколько похожих проектов одновременно. У нас в компании стоит похожая задача, и подход Walmart хорошо решает множество вопросов. Так что, в идеале, новый проект с похожей структурой и компонентами требует меньше усилий на разворачивание, разработку и поддержку.

        На мой взгляд, компоненты можно четко разделить на базовые, которые могут использоваться в любом проекте, например — react-select, react-modal и т.д., и специфичные для определенного типа проектов, как, например, упомянутая форма оплаты. В рамках проектов walmart ее структура и бизнес логика не меняется, меняется внешний вид.

        Собственно, базовые компоненты имеет смысл open-source-ить, специфичные — inner-source-ить.

        Делать компоненты, которые можно повторно использовать — довольно затратное дело, должны быть очевидные причины для инвестирования усилий в это. Если проекты небольшие, разные, нет обязательств по их поддержке, то можно ограничиться лишь повторным использованием базовых компонентов. И это нормально.
          0
          Вот, у вас в одном абзаце (даже в одном предложении) комментария здравого больше, чем в оригинальном буллшите.

          А статью можно вообще в двух словах переписать: «Как же добиться повторного использования компонентов React? Просто надо повторно использовать компоненты React!»

          Возьмите любое обсуждение React, не важно с чего оно началось, но если пошло сравнение с другими средствами, всегда станет вопрос повторного использования компонентов. И вот тут success-story как нельзя лучше пригодилась бы, и я думаю, не на уровне open/inner, а на практическом примере, когда компонент перестаёт быть «базовым» и становится «специфичным».

            0
            По нашему опыту, самый частый случай inner source — компоненты завязанные на внутренние сервисы либо более сложные компоненты, часто состоящих из нескольких базовых компонентов и надстроек к ним.
            Из примеров, что первое на ум пришло: react обвертки для плееров, компонентов рекламы, нам конкретно пришлось сделать свой внутренний react-picture в виду способа хранения изображений. У walmart из примеров еще есть навигация, компоненты со страницы пользователя. Самому интересно было б услышать примеры от других людей.

            Повторно использовать какие-нибудь шаблоны или Higher order components пока не доводилось, так как не было пока случая, когда это целесообразно.

            0
            Делать компоненты, которые можно повторно использовать — довольно затратное дело

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

              0
              Речь идет о процессе разработки компонентов для повторного использования. Такие компоненты разрабатываются итеративно, так как все возможные варианты использования изначально неизвестны :) Часто компонент нужно изменить или нарушить backward compatibility для его использования в другом проекте. Современные фронтенд фреймворки ориентированы на компонентную разработку, каждый имеет свои плюсы и минусы. Но процесс обобщения компонентов не зависит от фреймворка.
                0

                Может приведёте пример такого итеративного изменения?

                  0
                  первое, что на ум пришло — open-source react компоненты.

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

                    Ну, это всё особенности Реакта, где компоненты имеют жёсткие конфиги.

                      0
                      какое имеет отношение реакт к нереализованным фичам в компоненте?
                        0

                        Такое, что в реакте эту фичу нужно реализовывать, а в более других фреймворках — нет.

                        0
                        почему такой негатив к реакту? :)
                          0

                          Я констатирую факт без какой-либо эмоциональной оценки.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое