А я потом и ингредиенты спросил. Он сказал что купить в очередной главе, где и как и зачем. Концепт с ошибками есть, а дальше если есть желание углубить и обобщить всегда можно.

Это не важно... мне интересно было попробовать вариант из статьи и он работает

П.с. это амфито

В дип сике с третьей попытки получилось узнать формулу мет...на )))

В октябре напишу, что думаю о том реальная информация здесь или нет.

Интересно ) попробую модуль. У меня пожалуй все написанно для веб компонентов, что требуется мне, кроме реактивности адекватной.

Но если компонент сам генерирует HTML внутри Shadow DOM (например, сложная структура со вложенными элементами), то этот HTML не будет в SSR. Тег компонента будет, содержимое Shadow DOM — нет. Это нормальное поведение для Web Components, и обычно это не проблема, потому что контент всё равно рендерится на клиенте.

Давно уже декларативный shadow dom есть.

можно на сервере все отрисовать и на клиент отдать. У меня ssr свелся к одному атрибуду, который отключает на клиенте формирование темплейта, если он на сервере построен уже.

А если я дату публикации буду генерировать до появлкния чата ? Или я буду контент старых статей заменять на ии ? Этот алгоритм сработает ?

У меня написаны подобные спецификации. Только я от них пока отказался. Слишком большой объем для чата получается. Сделал одну спецификацию небольшую, которой пользуюсь.

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

 с использрованием declarative shadow dom нет возможности создать динамически или склонировать тк shadow dom в данном случае привязывается при загрузке страницы. 

Вы правы и как вы написали так и есть. Я исхожу из того просто, что

• Контент должен максимально быстро появляться, по этому откладывать появление теневого дерева нет. Чем раньше тем лучше

• В дальнейшем не должно быть проблем в рендером шаблона на стороне сервера. Декларативный подход позволяет на сервере формировать шаблон. Тогда на стороне клиента можно дата атрибутом отключить формирование темплейта, оставив только гидрацию шаблона. Здесь без declarative shadow dom не обойтись просто.

• Шаблон компонента рендерится полностью только один раз в идеале. Дальше либо части темплейта обновляются либо значения в полях. По этому динамические части так же остаются как и раньше, только они уже работают с темплейтом, а не выполняют какие то действия до того, как atache не сработал.

    let eventListeners = [];

    const addEventListener = (element, event, handler) => {
        element.addEventListener(event, handler);
        eventListeners.push({ element, event, handler });
    };

    const removeAllEventListeners = () => {
        eventListeners.forEach(({ element, event, handler }) => {
            element.removeEventListener(event, handler);
        });
        eventListeners = [];
    };


   const compareBtn = shadow.querySelector('#compare-now');
        if (compareBtn) {
               addEventListener(compareBtn, 'click', async () => {
               console.log('Compare Now clicked');
               await context.compareNow();
               exportBtn.disabled = false
           });
        }


   removeAllEventListeners();

Я так обычно последнее время делаю. вроде работает

connectedCallback() { this.shadowRoot.addEventListener('click', e => { const { target } = e const controlEl = target.closest('[data-control]') if (!controlEl) { return } const { control } = controlEl.dataset if (control === 'next') { this.#handleNext() } else if (control === 'prev') { this.#handlePrev() } else { console.error('Invalid control value') } }) }

А уничтожение где стоит ? по идее в disconectedCallback должно быть

загрузка html (нет хука, который бы срабатывал, когда темплейт загружен) серверный рендеринг с деклоративным шадов домом,
Вообще сделать компонент с navigation api, это в любом случае понадобится если компоненты использовать

Я это использовал еще до появления всех этих ваших новомодных vue, svelte и т.д.

Очередной некропост о технологии пятнадцатилетней давности

Раньше 2017 года не могли. Тогда уже vue и react были.

Я как только он появился начал на них писать и это один из агрументов был, что никто не сможет написать, что я это 15 лет уже использую. ))) Раньше меня вы могли начать писать, только если вы являетесь разработчиком этих стандартов.

Сочетание этих технологий стало стандартом к 2018 году. 
Да и тогда это фреймворк полимер был, поддержка очень плохая была.

Стандарту 8 лет максимум

Про декларатиынй shadow dom ещё бы написали. Очень важная и определяющая возможность, для самой больной темы серверного рендеринга. С декларативным shadow dom это стало значительно проще.

Спасибо за модель. я пожалуй модуль сделаю с этими поворотами

А где нибудь на репозитории можно найти программу ?

p.s. На скриншоте модули написаны на чистом JS с использованием ИИ. И подход примерно похож на то, что описано в статье. Я сейчас думаю, как ускорить процесс можно.

спокойно писать на чистом JS.

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

Даже 2 модуля как на скриншоте, становятся очень плохо поддерживаемыми, если просто попросить ИИ что то сделать. А нормально приложение таких модулей содержит 20-80 штук

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

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

Да и забывать о FOUC (Flash Of Unstyled Content) не стоит. Когда страница грузится в первый раз - это не так раздражает, когда это постоянно происходит при перемещениях по страницам одного сайта. Реализовать роутинг в этом случае кажется более простым решением.

Как избежать мелькания нестилизованного контента

До появления Declarative Shadow DOM одним из распространенных методов предотвращения FOUC было применение правила стиля display:none к пользовательским элементам, которые еще не были загружены, поскольку у них не был прикреплен и заполнен их теневой корень. Таким образом, контент не отображается до тех пор, пока он не будет «готов»:

<style>
  x-foo:not(:defined) > * {
    display: none;
  }
</style>

C декларативным теневой DOM

<style>
  x-foo:not(:defined) > template[shadowrootmode] ~ *  {
    display: none;
  }
</style>

На практике ещё если не использовать серверный рендеринг, надо ждать, когда компоненты загрузятся и надо ещё первое отображение обрабатывать, пока роутинг не появится