Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Хм… Прочитал… Как же добиться повторного использования компонентов React?
Точно прочитали? :)
От себя скажу, что подход из статьи хорошо подходит, когда нужно поддерживать и разрабатывать несколько похожих проектов одновременно. У нас в компании стоит похожая задача, и подход Walmart хорошо решает множество вопросов. Так что, в идеале, новый проект с похожей структурой и компонентами требует меньше усилий на разворачивание, разработку и поддержку.
На мой взгляд, компоненты можно четко разделить на базовые, которые могут использоваться в любом проекте, например — react-select, react-modal и т.д., и специфичные для определенного типа проектов, как, например, упомянутая форма оплаты. В рамках проектов walmart ее структура и бизнес логика не меняется, меняется внешний вид.
Собственно, базовые компоненты имеет смысл open-source-ить, специфичные — inner-source-ить.
Делать компоненты, которые можно повторно использовать — довольно затратное дело, должны быть очевидные причины для инвестирования усилий в это. Если проекты небольшие, разные, нет обязательств по их поддержке, то можно ограничиться лишь повторным использованием базовых компонентов. И это нормально.
От себя скажу, что подход из статьи хорошо подходит, когда нужно поддерживать и разрабатывать несколько похожих проектов одновременно. У нас в компании стоит похожая задача, и подход Walmart хорошо решает множество вопросов. Так что, в идеале, новый проект с похожей структурой и компонентами требует меньше усилий на разворачивание, разработку и поддержку.
На мой взгляд, компоненты можно четко разделить на базовые, которые могут использоваться в любом проекте, например — react-select, react-modal и т.д., и специфичные для определенного типа проектов, как, например, упомянутая форма оплаты. В рамках проектов walmart ее структура и бизнес логика не меняется, меняется внешний вид.
Собственно, базовые компоненты имеет смысл open-source-ить, специфичные — inner-source-ить.
Делать компоненты, которые можно повторно использовать — довольно затратное дело, должны быть очевидные причины для инвестирования усилий в это. Если проекты небольшие, разные, нет обязательств по их поддержке, то можно ограничиться лишь повторным использованием базовых компонентов. И это нормально.
Вот, у вас в одном абзаце (даже в одном предложении) комментария здравого больше, чем в оригинальном буллшите.
А статью можно вообще в двух словах переписать: «Как же добиться повторного использования компонентов React? Просто надо повторно использовать компоненты React!»
Возьмите любое обсуждение React, не важно с чего оно началось, но если пошло сравнение с другими средствами, всегда станет вопрос повторного использования компонентов. И вот тут success-story как нельзя лучше пригодилась бы, и я думаю, не на уровне open/inner, а на практическом примере, когда компонент перестаёт быть «базовым» и становится «специфичным».
А статью можно вообще в двух словах переписать: «Как же добиться повторного использования компонентов React? Просто надо повторно использовать компоненты React!»
Возьмите любое обсуждение React, не важно с чего оно началось, но если пошло сравнение с другими средствами, всегда станет вопрос повторного использования компонентов. И вот тут success-story как нельзя лучше пригодилась бы, и я думаю, не на уровне open/inner, а на практическом примере, когда компонент перестаёт быть «базовым» и становится «специфичным».
По нашему опыту, самый частый случай inner source — компоненты завязанные на внутренние сервисы либо более сложные компоненты, часто состоящих из нескольких базовых компонентов и надстроек к ним.
Из примеров, что первое на ум пришло: react обвертки для плееров, компонентов рекламы, нам конкретно пришлось сделать свой внутренний react-picture в виду способа хранения изображений. У walmart из примеров еще есть навигация, компоненты со страницы пользователя. Самому интересно было б услышать примеры от других людей.
Повторно использовать какие-нибудь шаблоны или Higher order components пока не доводилось, так как не было пока случая, когда это целесообразно.
Из примеров, что первое на ум пришло: react обвертки для плееров, компонентов рекламы, нам конкретно пришлось сделать свой внутренний react-picture в виду способа хранения изображений. У walmart из примеров еще есть навигация, компоненты со страницы пользователя. Самому интересно было б услышать примеры от других людей.
Повторно использовать какие-нибудь шаблоны или Higher order components пока не доводилось, так как не было пока случая, когда это целесообразно.
Делать компоненты, которые можно повторно использовать — довольно затратное дело
Плох тот фреймворк, где компоненты по умолчанию не переиспользуемы, а нужно прилагать дополнительные существенные усилия, чтобы использовать их можно было и в других местах.
Речь идет о процессе разработки компонентов для повторного использования. Такие компоненты разрабатываются итеративно, так как все возможные варианты использования изначально неизвестны :) Часто компонент нужно изменить или нарушить backward compatibility для его использования в другом проекте. Современные фронтенд фреймворки ориентированы на компонентную разработку, каждый имеет свои плюсы и минусы. Но процесс обобщения компонентов не зависит от фреймворка.
Может приведёте пример такого итеративного изменения?
первое, что на ум пришло — open-source react компоненты.
Конкретный пример из проектов. Создавали компонент для авторизации. Изначально он получился более ориентированным под задачи первого проекта. Для следующего проекта требовалась та же форма, но с некоторыми дополнениями или что-то было лишнее. В результате, компонент стал более абстрактным от изначального варианта, появилась дополнительная конфигурация, компонент был вынесен в отдельный репозиторий.
Конкретный пример из проектов. Создавали компонент для авторизации. Изначально он получился более ориентированным под задачи первого проекта. Для следующего проекта требовалась та же форма, но с некоторыми дополнениями или что-то было лишнее. В результате, компонент стал более абстрактным от изначального варианта, появилась дополнительная конфигурация, компонент был вынесен в отдельный репозиторий.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как добиться повторного использования React компонентов (Перевод)