Части сайта в виде компонентов - как реализовать?

Был такой JSR-168, но не особо взлетел. Угадаешь, почему?

Погугли «микрофронтенд».

Ну… Микросервисы! :)

Ты можешь сделать сколько угодно блоков, и в каждый с помощью JS (щас меня проклянет Croco) тянуть нужное содержимое из своего адреса. Ну, оно примерно так щас и работает уже много где, все эти веб-приложения и прочее ненужно.

Но оно не обменивается.

Внутри страницы да. Но можно ведь заставить обмениваться сами микросервисы…

Дикий комбайн получается на самом деле. Зло какое-то.

Да

чтобы он состоял из абсолютно независимых блоков

Айфрейм

И существует ли способ красивого, возможно стандартизованного, обмена событиями и сообщениями между такими компонентами?

Нет. В браузере лочат любые попытки. Проще через бакэнд делать.

Oauth вполне себе работает при помощи POST запросов. Это на тему «лочат любые попытки».

Но да, этот обмен не стандартизированный и некрасивый.

А вообще…

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

Но рухнет такой колхоз тоже достаточно быстро, когда в одном из компонентов поменяешь что-то, а освновное приложение не будет об этом знать.

З.Ы. Я не специалист по вротенду и уж тем более по JS с фреймворками, поэтому могу сейчас нести бред :) Мой опыт закончился на Vue 2 и паре простых автоматизаций на странице на нем.

iframe наверное.

Самый классический способ: фреймы. Абсолютно независимые страницы, которые могут быть даже на разных доменах. Между фреймами можно передавать сообщения: https://javascriptbit.com/transfer-data-between-parent-window-and-iframe-postmessage-api/

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

Есть ещё технология Custom Elements. Но там нужно, чтобы подрядчики завернули свои модули в кастомные элементы.

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

Кажется, батенька, это не техническая проблема, а чисто менеджерская.

при помощи POST запросов

Так это про

Проще через бакэнд делать.

Я про клиентскую часть, типа из айфрейма в айфрейм.

А, ты имеешь в виду прямо в браузере из фрейма во фрейм, без обращения к домену фрейма? Ну да.

Я про клиентскую часть, типа из айфрейма в айфрейм.

https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API

Кажется, батенька, это не техническая проблема, а чисто менеджерская

Согласен, но увы

https://javascriptbit.com/transfer-data-between-parent-window-and-iframe-postmessage-api/

Это почитаю, спасибо

Кажется, батенька, это не техническая проблема, а чисто менеджерская

Все три раза в начале всё всегда шло отлично, функционал просто пёр, за работу платилось, общая задача была очень четко разделена на кусочки функциональности

общая задача была очень четко разделена на кусочки функциональности

А кто отвечал за проектирование и реализацию интеграции этих кусочков?

Один человек в нанятой команде. Это любительский проект, последний раз работали реально профи, но в качестве хобби. Это типа-стартап, на энтузиазме и честном слове

Если бы всё было по жесткому договору, то было бы очень дорого

И как же эти «реально профи» работали, что не смогли собрать всё вместе?

… И существует ли способ красивого, возможно стандартизованного, обмена событиями и сообщениями между такими компонентами?

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

Какое же это «файловое хранилище», если это тупо ключ-значение?

Айфрейм

Ещё есть такая сумрачная штука как SSI

Standard Settlement Instructions?

Server Side Includes

По-моему ты переусложняешь. Почему не воспользоваться обычными кастомными эвентами для организации шины? https://developer.mozilla.org/en-US/docs/Web/Events/Creating_and_triggering_events А морду рисовать на клиенте, на каком-нибудь реакте

Да ну, фигня какая-то.

twig подойдет?

Какое же это «файловое хранилище», если это тупо ключ-значение?

Тогда назовём это так: хранилище данных в виде файла подкачки интернет-обозревателя на вычислительном устройстве пользователя. Если удалять прочитанные данные, то пяти мегабайт текстовых сообщений для «общения» окон между собой вполне должно хватить.

Потому что решать Проблему XY — старинное занятие на программерских форумах.

Существует ли способ организовать сайт так, чтобы он состоял из абсолютно независимых блоков, присутствующих в одном окне? Например, окошко с картами, окошко с настройками

что бы ( и на чем бы) ты там ни писал, советую начинать со спецификации

API first

приложение бьем на страницы
страницы на виджеты

каждый виджет работает с данными(формальное описание)
реагируя на события(список) меняет свои состояния(список)

данные берем откуда?
как синхронизируем с локальными данными приложения?

…

и вот когда ты все это опишешь останется только запрограммировать

а это уже говно вопрос

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

Может тебе нужны острова https://docs.astro.build/ru/concepts/islands/

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

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

Да большинство фронтэнд фреймворков позволяют организовать вот так вот как ты написал компоненты. Но если

на разных языках и фреймворках

Если это SPA то обычно можно без проблем втулить в html компоненты на разных фреймворках, нужно только организовать взаимодействие между ними) Если не SPA, то уже написали про фреймы.

У битриксов есть понятия инфоблок и компонент, по-сути второе является частью первого. Инфоблоки сами по себе можно сказать независимы.

При чём тут Битрикс? Это же сущности и абстракции самого Битрикса.

Я просто безуспешно пытаюсь создать сайт

Мде…

Сейчас абстракции предлагают большинство фреймворков. Даже Angular зопилил вот такое говно решение.

Java Portals это умеют, например Liferay или российский ТЕЗИС

Portlets 1.0(JSR-168) был местами неудобным, поэтому, а также в силу корпоративной жадности коммерческие производители (IBM, Oracle, SAP, RedHat) налепили своих нахлобучек что-бы там был RAD как в делфи, но на вендорлочных изобретениях. Portlets 3.0 получился уже хорошим и поэтому говноделы объявили микросервисную революцию, что-бы все приложения состояли из хардкода и лисапедов чуть более чем полностью. Ну и я бы не сказал, что не взлетел, просто оно в том сегменте, который всегда под NDA. И если сравнивать порталы с цмсками и mvc фреймворками, время жизни каждого из которых варьируется от 1 до 3х лет в среднем, портальные приложения обладают некоторой большей стабильностью, т.е. качеством. Хотя на вебе построенном вокруг работорговли этого добиться наверное нереально, т.к. корпорациям, не говоря уже о шарагах, надо все время набирать новых телепузиков в айтишники и потом выгонять через пару лет, т.е. на проектах всегда будут царить временщические загоны.

Спасибо за все ваши комментарии! Нужно будет всё это прочитать, и сравнить варианты

Angular умер. Главное не гуглить кто этот Джессика… Не надо его предлагать, да и вообще он для фанатов тупого скрипта и C#

Нечего сравнивать. Бери Vue 3 и vuetify. Vue 3 - это реально единственный выбор. Единственная ему альтернатива - это убогий React, который не поддерживает двусторонее связывание (это когда есть, например, input и есть модель, ты изменяешь модель и изменяется значение в инпуте и наоборот). Проси ChatGPT либо китайский DeepSeek тебе сгенерировать проект, а дальше просто дописывай

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

И ты бы не открывал по поводу «тупого скрипта» и тем более шарпа.

Если раз-два и в прод - делай хоть на jquery, не запрещаю. А если это комплексное что-то, то никакие Vue, или React не спасают, тем более чистый JS. Всё течёт сквозь пальцы и любое изменение/дополнение - боль и страдания, обмазывание на каждый чих тестами и всё равно - говно на выходе. Помолчим о бэке…

Но и у тебя есть доля правды, не отрицаю, если это чих-пых, конечно излишне тыкать фреймворк. Известный мне лично кривой проект на Vue - клавиатурный программатор. Тоже пацаны клюнули на двойное связывание, да вот внедрить новый функционал не могут, так и живёт одной функциональностью, как некая beta.

Тоже пацаны клюнули на двойное связывание, да вот внедрить новый функционал не могут, так и живёт одной функциональностью, как некая beta.

Может им просто лень?

Если обычный html выхлоп, просто разные view для генерации из шаблона. Можно вынести их в отдельные классы. Если SPA, то везде уже есть компоненты. В vue, например, они уже по-дефолту как надо разложены, когда новый проект создаёшь.

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

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

Тогда уж Nuxt, чтобы была возможность SSR. Иначе сайты будут без SEO.

Можно рендерить шаблоны на сервере, как обычно. Блоки разделить по разным view, вынесенным в отдельные классы. Это всегда так и делают в нормальных проектах. Из простых примеров — можно посмотреть на шаблоны hugo.

А для реактивности использовать htmx. В результате по уму написанный фронт можно хоть в links смотреть и SPA для больших браузеров тоже присутствует. Croco сыт и овцы целы.

А ты новость ту не видел? — Забудь про мифическое SEO у Google полуручная модерация… И, кстати, неправда Google индексирует сайты на JS, мало того он зачем-то отправляет формы той же авторизации, те пытается зачем-то вызвать ошибку и индексирует ответ

Блоки разделить по разным view, вынесенным в отдельные классы. Это всегда так и делают в нормальных проектах. Из простых примеров — можно посмотреть на шаблоны hugo.

Это ты AngularJS описал. Он единственный MVC, поэтому его не любят. C# подход. Но там тоже своеобразный MVC, где V тупо шаблоны. Vue - MVVM, а React - уродец, который и фреймворком не является, он просто либа

А для реактивности использовать htmx.

В JS давно нативные веб-компоненты есть, но они неудобные, а htmx — это какая-то ерунда, если честно. Бесперспективно.

Какую новость? Нет, не видел. Про обработку SPA в курсе. Но кроме гугла есть ещё поисковики — как минимум яндекс. А ещё SPA может не работать в простых браузерах. И preview в мессенджерах не будет работать, потому что там примитивный парсинг html. Тут уже зависит от ЦА, но в любом случае, чем больше поддерживаемых браузеров — тем лучше.

Preview - это скриншот страницы безмозглым хромом. Так как раз JS выполняется.

Тут уже зависит от ЦА, но в любом случае, чем больше поддерживаемых браузеров — тем лучше.

Их осталось 2,5 — Chromium, Safari и полумертвый FireFox.