Для меня это большой вопрос относительно веб-компонентов; Обещание веб-компонентов заключается в том, что они предназначены для использования в качестве универсальных повторно используемых компонентов, которые может взять и запустить любой желающий; в конечном итоге возможность создавать и переделывать веб-компоненты для создания собственных приложений и использования существующих приложений.
Однако возникает большой вопрос, как реализовать такое видение, как:
У нас есть идея приложения, мы создаем репозиторий для приложения, мы создаем веб-компоненты внутри репозитория приложения.
У нас есть идея приложения, мы создаем github org для приложения, мы создаем репо для каждого веб-компонента
Вариант 1, похоже, уменьшит наибольшую часть накладных расходов, но увеличивает степень фрагментации, уменьшает обнаруживаемость и препятствует привлечению новых участников (поскольку теперь они сталкиваются со всем вашим приложением, а не только с веб-компонентом).
Вариант 2, похоже, увеличит накладные расходы, но уменьшит степень фрагментации, улучшив при этом обнаруживаемость веб-компонентов и возможность для участников приступить к работе с вашим веб-компонентом, поскольку группа специалистов по сопровождению может поддерживать один и тот же веб-компонент вместе .
Тем не мение. Вариант 1, хотя и увеличивает фрагментацию, кажется, что он лучше учитывает эволюцию веб-компонентов с течением времени, тогда как в варианте 2 будет обнаружено множество устаревших компонентов в пользу более качественных компонентов, разработанных позже в процессе разработки.
Тем не мение. Однако этому, вероятно, противостоит тот факт, что отказ от поддержки, согласованный сообществом, лучше, чем фрагментация компании. Например. лучше иметь a, b и c, веб-компоненты, где c является последним. Чем иметь, company1-a, company2-a, company3-a, при этом все они поддерживаются.
Итак, как можно реализовать обещание веб-компонентов, находя при этом хороший баланс с их реализацией?
