Комментарии 13
Вы написали свой фронтенд поверх SAP Hybris, который используется у вас в магазине?
Да, но живут отдельно и общаются по API. Встроенный фронт, сделанный внутри Hybris, отныне легаси.
Очень интересно, а что вы делали с CMS? Вам пришлось написать свои апи для получения компонентов, страниц и т.д? Или вы вообще отказались от cms на стороне бэка?
Или вы просто дополнили апи вашего мобильного приложения и используете его?
И почему не перешли на новый фронтенд от сапа, на спартакус?
Очень интересно, а что вы делали с CMS? Вам пришлось написать свои апи для получения компонентов, страниц и т.д
На базе уже имеющейся CMS сделали API, да
Или вы просто дополнили апи вашего мобильного приложения и используете его?
Нет, это новое
И почему не перешли на новый фронтенд от сапа, на спартакус?
Этот вопрос оставлю без ответа
Здравствуйте. Спасибо за статью.
Сейчас тоже пробуем микрофронт, но не бeз SSR (он нам не нужен на проекте).
А почему вы переехали с легаси на vue2 именно? Почему не 3 версии?
Может ли у вас отдельная команда (микрофронт) быть написан на другом фреймворке?
Хотелось бы больше информации о масштабах проекта и сложностях, что его пришлось на микрофронт разбивать. Сколько у вас в итоге получилось проектов? Сколько сейчас команд?
Как решается проблема шаринга либ между проектами? Юзеру приходится несколько раз загружать условно лодаш?
Можно подключить несколько разных микрофронтов на одну страницу?
Не совсем понял момент с подключением всех микрофронтов в один. Это происходит на этапе сборки проекта или ран тайм?
А вы пробовали module federation?
На момент начала разработки vue3 не был продакшн-реди, не была сформирована экосистема, а Nuxt 3 не существовало. Начинали разработку с пониманием, что придется переходить на Vue 3, и это нам еще предстоит
Нет, разве что если это будет отдельный проект (вне основного av.ru). Но это крайне не рекомендуется, хотим всё писать на плюс минус одинаковой архитектуре
Микрофронты сделаны для контроля роста проекта. В данный момент над проектом работает одна команда, но уже постепенно подключается вторая, которая делает совсем другие задачи, и это не предел. Решили сделать микрофронты, пока не поздно. Ну а также все причины в начале статьи, где "Проблематика" - они все в совокупности.
По проектам: пока что их всего два, хотя по правилам должно быть больше. Это связано с тем, что архитектура свежая, и мы не успели старый код перенести на эту архитектуру. После переноса будет шесть.Никак не решается, либы везде одни и те же. Лодаш не используем, в целом у нас сейчас нет никаких проблем с использованием библиотек, необходимость использовать разные не возникает.
Нет, вообще, в идеальном мире, одна страница = один микрофронт. Либо одна группа страниц = один микрофронт (например, спецпроект).
На этапе сборки проекта происходит, собственно, сборка всех подключенных фронтов, тогда же происходит сборка глобальных зависимостей проектов (inject-глобальные функции, SCSS). На Runtime подключается Vuex, в зависимости от текущего пути страницы, для экономии ОЗУ и улучшения производительности.
На начало разработки такое нужно не было, но в целом есть запрос от одного из разработчиков на похожее. Обдумываем, но пока не применяли.
Спасибо за интересные вопросы!
extendRoutes: (routes, resolve) => {
routes.push({
path: '/2.0/test',
//Именно вызов resolve подключает этот файл для build
component: resolve(__dirname, 'pages/index.vue'),
});
return routes;
},А если вам надо добавить вложенный маршрут(в рамках сервиса нужно выделить несколько модулей)? Находите нужный элемент в routes и делаете push в children?
scssVariables: [
{
//join всё также нельзя
src: __dirname + '/scss/microModuleVariables.scss',
strategy: 'push',
},
],scssVariables доступны глобально по всему приложению или только в рамках модуля в котором они подключаются?
Находите нужный элемент в routes и делаете push в children
Пока что с таким не сталкивались.
В худшем случае да, но как будто можно вместо Nested Routes просто задавать строкой нужный путь, в противном случае либо появятся созависимые модули, либо какая-то глобальная нерабочая конфигурация (если использовать router-view).
scssVariables доступны глобально по всему приложению
К сожалению, да, ведь эти файлы вставляются в prependData и поэтому являются глобальными. И поэтому же там не может быть CSS селекторов и тд, то есть только SCSS и ничего больше.
В худшем случае да, но как будто можно вместо Nested Routes просто задавать строкой нужный путь
Иногда бывает необходимо сделать именно несколько уровней вложенных маршрутов.
К сожалению, да, ведь эти файлы вставляются в prependData и поэтому являются глобальными. И поэтому же там не может быть CSS селекторов и тд, то есть только SCSS и ничего больше.
Я на проекте делал похожее разделение на модули, думал над таким вариантом добавления scss, но отказался из-за того что могут быть пересечения переменных между сервисами. Решил что лучше просто импортировать файл с глобальными scss переменными сервиса в нужный компонент.
Почему vue, а не react?
Я чуть не забыл одобрить и ответить на этот комментарий.
Причин несколько - прежде всего большая часть команды, помимо легаси, знала именно Vue, в основном потому, что он исторически используется в рамках одного из легаси проектов (но в минимальном количестве).
Вторая причина - мой личный, большой опыт работы на Vue. Сложили всё это и приняли решение. Почему именно я работаю на Vue - это уже слишком холиварно :)
Азбука вкуса, Nuxt и наш тернистый путь к микрофронтам