не знаю зачем вам это надо, когда можно сделать легко самому, видимо вы хотите воровать или провоцировать дальше, но вот в этом компоненте используется 2 шаблона
эм, что вам мешает сделать пример с тегом template и importNode/clone? почему я должен бежать что-то делать для вашей прихоти, особенно если вы сам сделали неправильно
Таких специалистов давно послали нахер со своими мегапаттернами
нынешних любых фронтендщиков с мегаантипаттернами вообще шлют с такой скоростью, что работа официантом или кассиром выглядит образцом стабильности
Но самый прикол не в этом, а в том что как ты, блин, будешь использовать веб-компоненты в не-SPA? Типа, создашь огромный HTML, поместишь туда все шаблоны,
веб-компоненты никто не запрещает делать в spa, но с серверными технологиями шаблоны относящиеся к определенному роуту будут во вьюхах серверного шаблонизатора, а общие подключатся и переиспользоваться, настоящая чушь это писать целые приложения и системы со всей бизнес-логикой на жаваскрипте, такие приложения никогда не работают нормально, зато жрут кучу ресурсов и тормозят
Лично я считаю, что если у разработчиков есть выбор — это хорошо.
выбор без полноты информации это чаще всего ошибка и не выбор вовсе, популярные современные фреймворки изобилуют ошибками проектирования и вцелом часто имеют не очень хороший код
Мне почему-то кажется, что лет 6 назад вы шаблоны писали примерно так:
я писал как в svelte с {{ плейсхолдерами }} и {# циклами #}, сейчас я думаю что это все лишнее когда есть native templates и компонеты кастомных элементов
тут кто-то ругал custom elements за глобальное пространство имен, вот разве html imports не тот же настоящий глобал? как быть с потенциальными уязвимостями? вдруг кто-нить трояна в килотонны вермишели засунет? у схожего по смыслу iframe сейчас сделали очень много ограничений по безопасности в силу этой проблемы
На странице может быть сотни компонентов, зачем нам чтобы наш первичный HTML, который скачивает юзер весил тонну?
разные экраны отличаются путем в строке адреса, поэтому грузить вообще все сразу действительно нет необходимости
В вашем же случае, чтобы перенести весь компонент в другой проект, нужно будет скачать отдельно js, css и потом еще не забыл выбрать нужный template-тег
если у вас в одном компоненте все попиленно на подкомпоненты и вы еще например что-то в них там прокидываете то выходит прямое связывание и переносить вы их тоже будете кучкой. А правильное структурирование с разделением по типам позволяет делать различные оптимизации и операции над файлами для каждого типа, ну кроме того что так больше шансов получить правильную подстветку синтаксиса и автодополнения и прочие рефакторинги в среде разработки
Вы где были последние пару лет то? Те кому нравится Redux (я к таким не отношусь) пишут на нем, даже со Svelte
есть не значит что им пользуются, у них своих 5 погремушек «аналогов» с другими анти-патернами, например они там все файлы называют одинаково
А веб-компоненты типа не предполагают? Сколько не видел, что пишут люди, всегда разметка и стили внутри класса-компонента.
веб компоненты это еще и нейтив темплейы, которые позволяют не инлайнить вертску в джаваскрипте, то что некоторые все-таки инлайнят это влияние реакта и антипатерн конечно
Все эти «заморочи» решаются простой композицией компонентов.
не всегда, решается только в простых случаях, когда у вас все приложение как хеловорлд на бутстрапе. А часто бывает так, что побить на куски нецелесообразно, а логика отображения должна быть продвинутая и выходит портянка инлайн вертски в жс на экран или больше.
А давайте пример?
пример нескольких querySelector + document.importNode в одном классе вместо return() или import('Something.svelte') вы вообразить просто такое не можете?
Очень интересно, я вот пишу сейчас не особо большие проекты, но даже в тех проектах, которые мы пишем, я не могу себе представить,
spa это монолит писанный на не самых лучших на сегодня технологиях, огромные заделы разработки в npm присутствуют в виде кривеньких куцых велосипедах как максимум
А что делать с переносимостью компонентов?
гораздо лучше, потому что в фреймворке с инлайновыми шаблонами получается прямое связывание лейаута и выковырять кусок компонентами и перенести в другой модуль выходит сложнее
веб-компоненты позволяют использовать их и так и этак, поэтому они останутся жить, а фреймворки в которых это надо делать через нахлобучки уже теряют своих поклонников.
поиск аутентичных решений — это верное направление, тем более что многие их них уже показали свою эффективность.
как это показали? я видел только, что никто за фронтендщиками не хочет проекты продолжать а они все время переписываются на очередной казуальной погремушке
Эта одна из причин, почему Angular по-сути единственный современный all-in-one фреймворк.
каждый фреймворк из популярной тройки — велосипедный all-in-one, никто не использует редакс с вуе и т.п.
Еще раз, спека по HTML Imports никак не описывает каким именно образом должны писаться веб-компоненты, а отменили ее не из-за того, что вы пишете, а из-за ES6 модулей.
использование импортов предполагало размещение всего в одном файле как .vue или .svelte и полключение одной строкой, es6 модуль предполагает что вы с этим «бандлом» что-то сделаете все-таки явно, отрендерите или задефайните
у фреймворков с инлайновыми шаблонами часто есть заморочь со сложными или множественными лейаутами, от этого как и от верстки отгораживаются как могут, но проблема остается, а один вебкомпонент может рендерить как угодно сколько угодно разных шаблонов, как понадобится так и будет, не надо выдумывать никакие стейты
для не SPA это не проблема, что-бы все необходимые темплейты находились в одном хтмл, кроме того в фронтенд-фреймворках довольно модная тема — server side compilation, где по роутам создаются предкомпилированные бандлы, так что тут как с роутингом и инжекцией зависимостей все на совести разработчиков фреймворков
Вот Polymer курируется Гуглом, значит он популярный?
ангуляр популярный, а react курируется фейсбуком, разе что vue под китайцами и пхпшниками и это тоже сказывается
А разве не инженеры должны решать, что противоречит, а что нет?
конечно, есть шаблоны проектирования, но нынешние фронтендщики любят делать наоборот
А кто вам сказал, что ООП это хорошо? Сколько уже было трудов на эту тему. Это далеко не silver-bullet.
тем не менее возврат к процедурному коду, к которому прибегают в качестве альтернативы тоже не выход, очень быстро все превращается в помойку, которую не хочется даже читать, а не то что развивать или поддерживать
Отвратная валидации в html5
вполне достаточная что-бы решать задачи, а в ангуляре нельзя явно вызвать метод валидации, только сбиндить, в результате чего сложный валидатор сделать больно
Я вас спрашиваю как HTML Importsсвязаны с SFC?
они очень похожи, в основе одна и та же идея замешать все в одну кучу поперек инженерного принципа разделения ответственностей, поэтому хтмл импорты и забраковали
ну вот да и шарахать людей по *станам и все говнодельство от этого спроса на эмиграцию
официанты тоже всегда требуются
gitlab.techminded.net/finistmart/com.finistmart.showcase.portlet/blob/master/src/main/webapp/js/showcase-list.js
нынешних любых фронтендщиков с мегаантипаттернами вообще шлют с такой скоростью, что работа официантом или кассиром выглядит образцом стабильности
веб-компоненты никто не запрещает делать в spa, но с серверными технологиями шаблоны относящиеся к определенному роуту будут во вьюхах серверного шаблонизатора, а общие подключатся и переиспользоваться, настоящая чушь это писать целые приложения и системы со всей бизнес-логикой на жаваскрипте, такие приложения никогда не работают нормально, зато жрут кучу ресурсов и тормозят
выбор без полноты информации это чаще всего ошибка и не выбор вовсе, популярные современные фреймворки изобилуют ошибками проектирования и вцелом часто имеют не очень хороший код
я писал как в svelte с {{ плейсхолдерами }} и {# циклами #}, сейчас я думаю что это все лишнее когда есть native templates и компонеты кастомных элементов
разные экраны отличаются путем в строке адреса, поэтому грузить вообще все сразу действительно нет необходимости
если у вас в одном компоненте все попиленно на подкомпоненты и вы еще например что-то в них там прокидываете то выходит прямое связывание и переносить вы их тоже будете кучкой. А правильное структурирование с разделением по типам позволяет делать различные оптимизации и операции над файлами для каждого типа, ну кроме того что так больше шансов получить правильную подстветку синтаксиса и автодополнения и прочие рефакторинги в среде разработки
есть не значит что им пользуются, у них своих 5 погремушек «аналогов» с другими анти-патернами, например они там все файлы называют одинаково
веб компоненты это еще и нейтив темплейы, которые позволяют не инлайнить вертску в джаваскрипте, то что некоторые все-таки инлайнят это влияние реакта и антипатерн конечно
не всегда, решается только в простых случаях, когда у вас все приложение как хеловорлд на бутстрапе. А часто бывает так, что побить на куски нецелесообразно, а логика отображения должна быть продвинутая и выходит портянка инлайн вертски в жс на экран или больше.
пример нескольких querySelector + document.importNode в одном классе вместо return() или import('Something.svelte') вы вообразить просто такое не можете?
spa это монолит писанный на не самых лучших на сегодня технологиях, огромные заделы разработки в npm присутствуют в виде кривеньких куцых велосипедах как максимум
гораздо лучше, потому что в фреймворке с инлайновыми шаблонами получается прямое связывание лейаута и выковырять кусок компонентами и перенести в другой модуль выходит сложнее
веб-компоненты позволяют использовать их и так и этак, поэтому они останутся жить, а фреймворки в которых это надо делать через нахлобучки уже теряют своих поклонников.
как это показали? я видел только, что никто за фронтендщиками не хочет проекты продолжать а они все время переписываются на очередной казуальной погремушке
каждый фреймворк из популярной тройки — велосипедный all-in-one, никто не использует редакс с вуе и т.п.
использование импортов предполагало размещение всего в одном файле как .vue или .svelte и полключение одной строкой, es6 модуль предполагает что вы с этим «бандлом» что-то сделаете все-таки явно, отрендерите или задефайните
ангуляр популярный, а react курируется фейсбуком, разе что vue под китайцами и пхпшниками и это тоже сказывается
конечно, есть шаблоны проектирования, но нынешние фронтендщики любят делать наоборот
тем не менее возврат к процедурному коду, к которому прибегают в качестве альтернативы тоже не выход, очень быстро все превращается в помойку, которую не хочется даже читать, а не то что развивать или поддерживать
вполне достаточная что-бы решать задачи, а в ангуляре нельзя явно вызвать метод валидации, только сбиндить, в результате чего сложный валидатор сделать больно
они очень похожи, в основе одна и та же идея замешать все в одну кучу поперек инженерного принципа разделения ответственностей, поэтому хтмл импорты и забраковали