какой вопрос, таков ответ. Зачем тогда спрашиваете про shadow dom, если знаете ответ. Если говорить про особенности shadow dom, как я говорил, он изолирует каждый компонент.
Не получится переиспользовать глобальные стили.
Есть проблемы с тестированием.
Проблемы с SEO.
Дополнительные затраты на хранение изолированного состояния.
В прошлый раз когда я хотел eslint-plugin-import на актуальную версию eslint применить, у меня версия не подходила. но вроде в package.json они уже поддерживают eslint 9. Я это к тому, что в последней версии идет переосмысление использования eslint, они с него выкидывают вещи отвечающие за форматирование, чтобы как раз убыстрить выполнение.
У меня так работодатель один ходил постоянно к сотрудникам, которые выставляли свой профиль в поиске работы и спрашивал, почему ищешь работу? Т.е. хотели быть уверены, что человек не ливнет. И если надо, то заранее открыть позицию новую.
Я менторю джуна одного, - девушку, она не имеет высшего образования в айти, но оно в принципе и не нужно. Она проходила курсы с посещением офиса в питере, отдала за 4месяца этого интенсива около 300тыс года 2 назад. Ей помогали приврать в резюме, но это не помогло.
Потом около года была в подвешенном состоянии, делала что-то на фрилансе, менторилась у разных программистов.
В итоге по знакомству удалось ей устроится на работу, из той же школы выпускник пригласил к себе. Ощущаются пробелы в базе, потому что теорию это все хорошо, но без подкрепления все забывается как страшный сон.
Поэтому сейчас с ней работаю над тем, чтобы она больше проявляла инициативу, изучала теорию уже с учетом негативного опыта на работе. Ибо только когда мы сталкиваемся с проблемами, мы можем понять где мы слабы.
"разложить на под-папочки" можно по разному: монолит, многослойная, fsd, ddd, модульная.
Не нужно путать монорепу с микрофронтами, монорепа это про другое. Суть микрофронтов в том, что они размещаются на разных адресах и общение между ними только по сети.
nx.dev это ведь инструмент для работы c монорепозиторием, а микрофронты это webpack module federation.
если у вас разные будут версии библиотек в микрофронтах, то могут быть проблемы с shared модулями, мы их указываем, чтобы в целом у нас единая система была. На nx.dev том же пишут, что нужно стараться использовать одну экосистему, не нужно angular, vue и react мешать. Это же и справедливо к актуальности библиотек используемых микрофронтами.
А что касается монорепозитория, есть аналоги решения приведенного в статье - lerna и т.д.
Плюсы использования монорепозитория можете найти в интернете. И он никак не связан с монолитом, за исключение того, что у нас в монорепе общие зависимости для всех микрофронтов. Там очень много плюсов. Но бывают случае, когда бизнес приходит и говорит, что наши микрофронты делают разные компании под nda и доступа у них к коду друг друга нет. Но тогда придется согласовывать этапы встраивания микрофронтов между друг другом, возможно согласовывать стек и версии библиотек.
Да и если в интренете посмотреть, то компании чаще выбирают монорепозитории, чем микрорепозитории. Просто потому что это предсказуемо и управляемо. Меньше потенциальных багов.
Разобрались с проблемой, оказывается в package.json поле name повторялось у двух микрофронтов, поэтому webpack думал что мы один и тот же проект пытаемся загрузить и он брал из кэша.
В идеале микрофронты не должны общаться друг с другом, иначе это нарушает основные преимущества микрофронтенд архитектуры. Если хотите данные показать на разных микрофронтах, обращайтесь к их бекендам, либо они могут к одному обращаться, это не нарушает принципы микрофронтендов.
Либо использовать события для взаимодействия между микрофронтендами чтобы подать сигнал что данные изменились и пора их обновить.
Отвечая на второй вопрос, я уже упомянул, что мы можем общие переиспользуемые вещи выносить на уровень libs, эта концепция взята из nx.dev, можно почитать здесь.
Иначе если у вас будут микрофронты иметь прямую связь между друг другом, то если упадет один микрофронтенд, то может отвалиться часть функционала в другом, что не очень хорошо.
не хотите схлеснуться в легендарной битве, где один будет на tailwindcss, другом на scss писать код. Оценим качество работы, сам код и время сколько ушло, как такая идея?
я ленивый программист, если можно сэкономить время разработки и деньги заказчика, я это сделаю, принимая во внимание еще сам продукт.
Я привык использовать готовые библиотеки, а не писать их с нуля. Зачем для каждого мелкого - среднего проекта делать свой ui кит? Если можно позаимствовать готовые, покрытые тестами и без нарушения семантики и стандартного поведения компонентов.
А на счет классов, вам никто не мешает использовать директиву @apply
Плюс еще подобные системы задают скелет для дизайн системы и в процессе сборки неиспользуемые классы из tailwind не добавляются.
Использование готовых утилитарных вещей экономит время. У вас могут быть готовые наработки на scss, которые вы можете из проекта в проект переносить, но не у всех они есть.
Взять тот же mui, мне очень удобно использовать на компонентах props, которыми я могу указывать отступы, цвет и т.д., разработчики позаботились о кастомизации; хотя это может быть спорно, т.к. гибкости там не так много.
Удобно не удобно, но все же есть вакансии где требуется знание tailwindcss, наблюдается его популярность при создании верстки с нуля. Чтобы каждый раз не создавать css. Если у тебя лэндинги, где не нужна поддержка, это будет идеальное решение для быстрого клепания.
какой вопрос, таков ответ. Зачем тогда спрашиваете про shadow dom, если знаете ответ. Если говорить про особенности shadow dom, как я говорил, он изолирует каждый компонент.
Не получится переиспользовать глобальные стили.
Есть проблемы с тестированием.
Проблемы с SEO.
Дополнительные затраты на хранение изолированного состояния.
Проблема с дебагингом кода.
Shadow dom это больше про изоляцию компонентов.
Почитай про Web Components, shadow dom является его частью.
В прошлый раз когда я хотел eslint-plugin-import на актуальную версию eslint применить, у меня версия не подходила. но вроде в package.json они уже поддерживают eslint 9. Я это к тому, что в последней версии идет переосмысление использования eslint, они с него выкидывают вещи отвечающие за форматирование, чтобы как раз убыстрить выполнение.
У меня так работодатель один ходил постоянно к сотрудникам, которые выставляли свой профиль в поиске работы и спрашивал, почему ищешь работу? Т.е. хотели быть уверены, что человек не ливнет. И если надо, то заранее открыть позицию новую.
я есть тут https://career.habr.com/rkutliakhmetov
Я менторю джуна одного, - девушку, она не имеет высшего образования в айти, но оно в принципе и не нужно. Она проходила курсы с посещением офиса в питере, отдала за 4месяца этого интенсива около 300тыс года 2 назад. Ей помогали приврать в резюме, но это не помогло.
Потом около года была в подвешенном состоянии, делала что-то на фрилансе, менторилась у разных программистов.
В итоге по знакомству удалось ей устроится на работу, из той же школы выпускник пригласил к себе. Ощущаются пробелы в базе, потому что теорию это все хорошо, но без подкрепления все забывается как страшный сон.
Поэтому сейчас с ней работаю над тем, чтобы она больше проявляла инициативу, изучала теорию уже с учетом негативного опыта на работе. Ибо только когда мы сталкиваемся с проблемами, мы можем понять где мы слабы.
В примере DFS используется рекурсия, что не очень хорошо, лучше стараться переписывать на стек.
module federation не имеет тех минусов, что есть у shadow dom. И опять вы приводите не корректное сравнение. Они решают разного рода задачи.
"разложить на под-папочки" можно по разному: монолит, многослойная, fsd, ddd, модульная.
Не нужно путать монорепу с микрофронтами, монорепа это про другое. Суть микрофронтов в том, что они размещаются на разных адресах и общение между ними только по сети.
nx.dev это ведь инструмент для работы c монорепозиторием, а микрофронты это webpack module federation.
если у вас разные будут версии библиотек в микрофронтах, то могут быть проблемы с shared модулями, мы их указываем, чтобы в целом у нас единая система была. На nx.dev том же пишут, что нужно стараться использовать одну экосистему, не нужно angular, vue и react мешать. Это же и справедливо к актуальности библиотек используемых микрофронтами.
А что касается монорепозитория, есть аналоги решения приведенного в статье - lerna и т.д.
Плюсы использования монорепозитория можете найти в интернете. И он никак не связан с монолитом, за исключение того, что у нас в монорепе общие зависимости для всех микрофронтов. Там очень много плюсов. Но бывают случае, когда бизнес приходит и говорит, что наши микрофронты делают разные компании под nda и доступа у них к коду друг друга нет. Но тогда придется согласовывать этапы встраивания микрофронтов между друг другом, возможно согласовывать стек и версии библиотек.
Да и если в интренете посмотреть, то компании чаще выбирают монорепозитории, чем микрорепозитории. Просто потому что это предсказуемо и управляемо. Меньше потенциальных багов.
Разобрались с проблемой, оказывается в package.json поле name повторялось у двух микрофронтов, поэтому webpack думал что мы один и тот же проект пытаемся загрузить и он брал из кэша.
Имхо, но статья через чур перегружена. Есть шпаргалка, где какой формат лучше использовать?
В идеале микрофронты не должны общаться друг с другом, иначе это нарушает основные преимущества микрофронтенд архитектуры. Если хотите данные показать на разных микрофронтах, обращайтесь к их бекендам, либо они могут к одному обращаться, это не нарушает принципы микрофронтендов.
Либо использовать события для взаимодействия между микрофронтендами чтобы подать сигнал что данные изменились и пора их обновить.
Отвечая на второй вопрос, я уже упомянул, что мы можем общие переиспользуемые вещи выносить на уровень libs, эта концепция взята из nx.dev, можно почитать здесь.
Иначе если у вас будут микрофронты иметь прямую связь между друг другом, то если упадет один микрофронтенд, то может отвалиться часть функционала в другом, что не очень хорошо.
не хотите схлеснуться в легендарной битве, где один будет на tailwindcss, другом на scss писать код. Оценим качество работы, сам код и время сколько ушло, как такая идея?
я ленивый программист, если можно сэкономить время разработки и деньги заказчика, я это сделаю, принимая во внимание еще сам продукт.
Я привык использовать готовые библиотеки, а не писать их с нуля. Зачем для каждого мелкого - среднего проекта делать свой ui кит? Если можно позаимствовать готовые, покрытые тестами и без нарушения семантики и стандартного поведения компонентов.
А на счет классов, вам никто не мешает использовать директиву @apply
Плюс еще подобные системы задают скелет для дизайн системы и в процессе сборки неиспользуемые классы из tailwind не добавляются.
Использование готовых утилитарных вещей экономит время. У вас могут быть готовые наработки на scss, которые вы можете из проекта в проект переносить, но не у всех они есть.
Взять тот же mui, мне очень удобно использовать на компонентах props, которыми я могу указывать отступы, цвет и т.д., разработчики позаботились о кастомизации; хотя это может быть спорно, т.к. гибкости там не так много.
Удобно не удобно, но все же есть вакансии где требуется знание tailwindcss, наблюдается его популярность при создании верстки с нуля. Чтобы каждый раз не создавать css. Если у тебя лэндинги, где не нужна поддержка, это будет идеальное решение для быстрого клепания.
Манипуляции эти для массы сделаны, чтобы меньшинство за счет их зарабатывало деньги. Опять биточек подрос, похоже сново хомячков стричь скоро будут.
Удача заканчивается ровно там, где начинается череда неудач.
Не ожидал, что тут много адекватных будут и будут против того, что делают с интернет пространством у нас в стране.
ШБ