Pull to refresh

Comments 13

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to leave a comment.

Articles