Комментарии 17
Скоро при заходе на сайт в браузере будут развёртываться несколько docker-образов :)
Портлеты восстали из мертвых
Каким образом эта хрень каждый раз попадает в лучшее за сутки?
И веб превратиться в базар изобретателей велосипедов…
Пару лет назад делал приложение типа CRM-ки. Визуально была боковушка-сайдбар с кучей менюшек, и центральная контентная часть.
Бекенд на symfony. Сверстал базовый шаблон с сайдбаром в серверном шаблонизаторе. Т.е. меню генерировалось на сервере. Каждый пункт меню — это ссылка, которая вела на отдельный серверный роут.
При этом контентная часть была пустым дивом, в который уже грузилось мини-SPA приложение (react) в соответствии с текущим серверным роутом (пунктом меню).
Т. е. на каждый серверный роут был отдельный twig-овский шаблон (унаследованный от базового) со своим отдельным подключёнными js- и css- бандлами, актуальными для данного пункта меню (роута).
При достаточно функционально огромном приложении — получился довольно лёгковесный фронт, максимум 1,1мб на роут (там где графики всякие).
Можно ли назвать такой подход «микрофронтендами»? хотя такого выражения тогда ещё вроде не было..))
Бекенд на symfony. Сверстал базовый шаблон с сайдбаром в серверном шаблонизаторе. Т.е. меню генерировалось на сервере. Каждый пункт меню — это ссылка, которая вела на отдельный серверный роут.
При этом контентная часть была пустым дивом, в который уже грузилось мини-SPA приложение (react) в соответствии с текущим серверным роутом (пунктом меню).
Т. е. на каждый серверный роут был отдельный twig-овский шаблон (унаследованный от базового) со своим отдельным подключёнными js- и css- бандлами, актуальными для данного пункта меню (роута).
При достаточно функционально огромном приложении — получился довольно лёгковесный фронт, максимум 1,1мб на роут (там где графики всякие).
Заголовок спойлера
Можно было ещё вынести общие части (react и др.) в отдельный чанк и подключить его в базовом шаблоне. Чтобы браузер закешировал общий бандл и при переходе между пунктами меню выкачивал только нужное.
Можно ли назвать такой подход «микрофронтендами»? хотя такого выражения тогда ещё вроде не было..))
При этом контентная часть была пустым дивом, в который уже грузилось мини-SPA приложение (react) в соответствии с текущим серверным роутом (пунктом меню).
Круто. Я так понимаю, без iframe все это сделано? А можно при этом как-то осуществить взаимодействие ядро <-> миниприложение1 <-> миниприложение2? И нельзя ли пример кода глянуть, хотя бы схематично, как в div грузится SPA приложение?
А что сложного-то?
export function InitModule(rootDiv) {
ReactDOM.render(<App/>, rootDiv);
return () => ReactDOM.unmountComponentAtNode(rootDiv);
}
Тут самое сложное — придумать как загрузить React и ReactDOM один раз, а не копировать в бандл для каждой страницы.
А можно при этом как-то осуществить взаимодействие ядро <-> миниприложение1 <-> миниприложение2?
Да без проблем, просто ядро и всю связь с ним придётся писать как вот тут: https://habr.com/ru/post/491684/
Самое сложное в этой схеме (как и вообще в микрофронтедах) — придумать что именно должно находиться в ядре.
А что сложного-то?
Ну, я бэкенд разрабатываю, так что это для меня «не свои сани». А можно загрузить в div динамически? Т.е. у нас есть SPA, посылаем запрос на сервер, сервер возвращает набор неких URL — допустим, три штуки — содержимое этих URL грузим в три div, которые внутри нашего SPA. Можно это каким-то образом осуществить?
У нас сейчас для этого используется набор iframe, все работает почти так, как надо, но есть ряд неприятных моментов.
Я так понимаю, без iframe все это сделано?
Да
А можно при этом как-то осуществить взаимодействие ядро <-> миниприложение1 <-> миниприложение2?
В моём случае «ядро» (наверное, лучше называть обвязка) — это был только сайдбар с щепоткой нативного js, который отвечал за скрытие/раскрытие пунктов меню, и за кнопку-гамбургер на мобилках.
Тут главное чтоб функционал этих мини-spa которые живут на разных серверных роутах сильно не пересекался. Максимум редирект с одного spa в другое.
Но впринципе, я когда это всё делал, то подозревал что рано или поздно может понадобится взаимодействие между spa в бандле и внешней обвязкой. Условно при каком-то событии внутри spa раскрыть и подсветить какой-то пункт меню в сайдбаре. Я тогда закладывал, что буду делать это через кастомные события. Типа spa диспатчит какое-то кастомное событие, а сайдбар слушал бы и реагировал. Или наоборот, в сайдбаре допустим какой-то чекбокс включается (диспатчим своё событие), а в spa реагируем на него. Вобщем по модели «издатель-подписчик». Но до такого явно не доходило, т.к. у аналитиков и дизайнеров я был главный и их полёт фантазий мог приструнить..)
И нельзя ли пример кода глянуть, хотя бы схематично, как в div грузится SPA приложение?
Как-то так было.
Серверный шаблон:
{% extends 'base-layout.html.twig' %}
{% block title %}
Traffic controller
{% endblock %}
{% block stylesheets %}
{{ parent() }}
<link rel="stylesheet" href="{{ asset('css/traffic-controller/index.min.css') }}">
{% endblock %}
{% block content %}
<div class="app__content" id="root">
<span>загрузка ...</span>
</div>
{% endblock %}
{% block javascripts %}
{{ parent() }}
<script>
window.__INITIAL_STATE__ = {
// какие-то уже готовые начальные поля для данного spa
// полученные при серверном(!) рендеренге этого шаблона
user: {{ user }}
};
</script>
<script src="{{ asset('js/traffic-controller/index.min.js') }}"></script>
{% endblock %}
Соответствующий индексный js:
import React from 'react';
import ReactDOM from 'react-dom';
import App from 'js/traffic-controller/parts/App.jsx';
const rootNode = document.getElementById('root');
ReactDOM.render(<App />, rootNode);
У нас в компании микроофронтенд — это каждая страница, которая SPA, по факту большой репорт с кучей инфы. Делается, для того, что бы можно было независимо деплоить в связке с микросервисами.
Кто использует микрофронтенды?
IKEA
Microsoft
SAP
Spotify
Ну то есть используют — огромные компании, с кучей народа, которым проще распилить ещё и фронтенд на микросервисы, чем договориться между собой что, как и когда запускать и тестировать, но при этом решение подается как нечно новое, универсальное, и на что надо посмотреть. И хотя в подавляющем большинстве контор этот подход нафиг ненужен, теперь на собеседованиях будут спрашивать ещё и микрофронтенды. Класс.
Сталкивался с Open Components. Если сравнивать с (монолитом) на React, то разработка на этих компонентах — где каждый грузится асинхронно и имеет свое собственное (скрытое) состояние — на порядок сложнее связки React/Redux.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Состояние дел в сфере микрофронтендов