Комментарии 15
Отличная статья, спасибо!
Используйте npm-пакеты, это практически стандарт в современном фронтенде, все к нему привыкли.
Вот этим https://www.npmjs.com/package/es5-ext пакетом, случайно, не пользуетесь? На всякий случай, посмотрите сюда: https://github.com/medikoo/es5-ext/commit/28de285ed433b45113f01e4ce7c74e9a356b2af2
P.S. Поиском в google нашел упоминание пакета лишь тут: https://habr.com/ru/company/vk/blog/340922/comments/
Этим пакетом не пользуемся.
Но вообще никто не застрахован что в транзитивных зависимостях окажется что-то вредоносное. Вот недавний пример: https://github.com/vuejs/vue-cli/issues/7054
Поэтому у нас правило - использовать package-lock, и обновлять зависимости только в рамках отдельной задачей с последующим тестированием что все нормально.
Вы тестировали эти виджеты с PWA?
Есть ли "подводные камни"?
Как я понимаю, PWA в минимальном варианте - это просто веб-старица на которой есть manifest.json и какой-либо сервис-воркер. И никаких проблем в работе с такими виджетами там нет.
При кешировании ресурсов через сервис-воркер для работы в оффлайн-режиме - тоже не должно быть сложностей, просто нужно учесть кеширование скриптов виджетов, также как и любых других ресурсов.
Динамические импорты ESM? Module federation? Врапперы из CustomElements? Git сабмодули? Есть куча способов решить вопрос куда более изящно.
А как помогут решить проблему git-сабмодули? Ведь чтобы обновить виджет - хост-проекту придется катить релиз.
Врапперы из CustomElements - такой тоже был вариант, но у нас пишут на react, поэтому используем react-комопонеты, а не custom-элементы, концептуально разницы между ними не вижу.
А module federation как раз сейчас пробуем и возможно в будущем перейдем на него, данная архитектура сложилась еще до его появления.
Классная статья! Спасибо, что делитесь знаниями и решениями.
Радует качество статьи и ее наполненность. Интересно было почитать!
P.S. превьюшка подкупает
А какие сложности могут возникнуть (и как с ними работать), когда кешируешь ресурсы для оффлайнов? что можно сделать, чтобы избежать?
Мы пока стандарты для сервис-воркеров не внедрили, поэтому про проблемы и как их решать не скажу.
Могу сказать только, что в основном для создания сервис-воркеров используем Workbox (https://developers.google.com/web/tools/workbox)
ReactDOMServer.renderToString(<LoginFormSSR />) // на сервере
А как быть, если внутри LoginFormSSR есть данные, которые достаются по API с сервера при инициализации компонента и которые надо бы поисковикам "скармливать"? Представим, что у нас виджет не LoginFormSSR, а какой-нибудь LatestArticlesList, в котором ссылки на последние 10 статей сайта. Ведь renderToString, как я понимаю, не будет дожидаться, пока в LoginFormSSR отработает запрос к API?
И сразу второй вопрос: как именно вы реализовываете обмен данными между виджетами?
В таком случае просто обычно на бекенде обычным способом запрашиваются данные из базы данных, или какого-то api и передаются пропсами в react-компоненты. А на клиенте эти данные вставлены в виде json, которые парсится и кладется например в redux-state.
В случае с redux лучше прямо в доке посмотреть: https://redux.js.org/usage/server-rendering
Понял, спасибо. Ещё скажите, пожалуйста, как вы организовали обмен данными между разными виджетами на странице, если у вас такое есть?
В целом мы стараемся делать виджеты независимым, чтобы им обмениваться данными с другими часто было не нужно. Когда это необходимо - этим управляет хост-приложение. Например пользователь авторизовался в виджете формы авторизации, после этого сработала коллбек-функция переданная пропсами в react-компонент-виджета. Хост-приложение в этой функции получает данные авторизовавшевося пользпользователя, сохраняет их себе и передает в другие виджеты.
Как мы в Домклике делаем виджеты на React