Пока готовлю большой проект и много контент на RU-vid решил разбавить новым форматом. Как вам? Лично мне очень нравится учить новое, и если вы оцените, то буду таким делиться чаще) Так же напишите, какую тему в подобном стиле еще разобрать?
@Зорица Караджич насчёт разработчиков, которые в нативном js разбираются хуже, чем в реакт, это очень плохо. Такими быть нельзя. Обходиться без фреймворков конечно можно, но зачем? Фреймворки проще для разработчика, а потому все крупные проекты на них написаны. Давно я вакансий по чистому js не видел, очень давно. Надо конечно и по чистому js снимать, тут я согласен
Если есть желание посмотреть пример реального проекта с использованием архитектуры микро-фронтэнда, предлагаю пообщаться, покажу реальный проект. Отправил запрос в друзья в vk. Сделаете ролик про "честный" микро-фронтэнд.
Владилен, добрый день! Канал великолепный. Очень помог подтянуть знания по js. И помогает пополнять. За это большое спасибо! На канале совсем не затрагивается тема 3d и и в целом, в интернете, очень не просто найти хоть какие-то материалы по Three.js. Есть план помещения нарисованная в Blender ни как не могу найти как его импортировать на сайт и оживить при помощи js. Думаю многим так же был бы интересен такой курс. Спасибо!
Это не совсем микро-фронтэнд. Это монолит с использованием разных фреймворков. Можно назвать его - ГИБРИД. Микрофронтэнд - это когда каждый модуль вообще никак не связан с другими модулями, когда они собираются в разных проектах, а подключаются в хост-модуль например с помощью webpack moduleFederation плагина и лучше по какому-нибудь конфигу на лету. Или вообще подключаются непосредственно в html Ну и еще про стор замечание. Это по функционалу - шина событий. Стор все-таки должен хранить данные. А в общем спасибо за рассказ.
@@user-pe5qr2wp4u - это способ включения стороннего модуля на страницу и ВСЕ! На этом функционал и возможности заканчиваются. Встречный вопрос, кто они?
Стоит дополнить, что реализация стора в глобальной переменной очень плохая идея. И да это не стор, а простой event emitter паттерн в который докинули коун, что тоже не хорошо.
@@alung414 Да, привязка к глобальному объекту window - это с точки зрения безопасности плохо. Надо искать другие варианты решения создания EventBus с глобальной областью видимости. А вот в качестве стора удобно использовать Mobx и пробрасывать его в модули через пропсы.
класс, сначала загрузим реакт, потом загрузим вью и через кошачью жопу будим их синхронить..... огонь идея, производительность должна расти на глазах :)))
Ну хз, обычно компонентам не требуется такой синхронизации, я думаю Владилен показал пример, как можно научить компоненты взаимодействовать при необходимости.
Кстати, не извращения) в продакшне такое используют нередко сейчас. Правда это почти никогда про разные фреймворки, просто разные команды занимаются разными частями одного большого сервиса, даже не обязательно, чтобы всё это на одной странице было и есть связующее звено между этим всем
Классно рассказано, спасибо тебе! Правда в части общей шины данных не совсем корректно применено к микрофронтендам. Я сейчас разбираюсь с микрофронтендами углубленно, и суть их в том, что каждый микрофронт должен работать изолировано, только со своим набором данных. Ни один микрофронт не должен реагировать на изменения в другом. Посыл микрофронтендов заключается в том, что каждую часть приложения разрабатывают разные команды, и по итогу их части приложения - модулями можно грубо назвать, должны легко слиться в одно большое приложение. Но фишка даже больше не в этом, а в том, чтобы данные для других микрофронтов подгружались лишь тогда и только тогда, когда они нужны, и подгружаться должны только те данные, которые не были подгружены ранее для ранее потребовавшихся микрофронтов. Т.е. общие пакеты или данные не должны подгружаться дважды, например react для каждого микрофронта. Все это поддерживается в webpack5. А так, мне понравилась теория о микрофронтендах! :))))
Привет, а если у нас есть какое-то состояние например токен пользователя, и нам надо его иметь для запросов на разных фронтах Не должны ли они делить данное состояние между друг другом
@@djorji7114 Привет! Нет, каждый фронт несёт свой набор данных, необходимый ему для работы со своим сервисом. Токен пользователя лучше хранить в куке, по которой каждый микросервис сам определит что это за пользователь. Идея микро фронтов заключается в том, что в какой-то любой момент один микрофронт удаляется например, другой загружается и работает, что-то вроде когда-то активно применяющийся в реализации фронтовой разработке. Хорошо что от них ушли 😁
@@djorji7114 я сейчас на проекте, где, к сожалению, нет микрофронтенда (( Погугли, на просторах интернет тонны информации. Реакт не панацея для микрофронта, любой фреймворк можешь использовать и даже чистый is. Главная суть, что твой сгенерированный js bundle имеет свой уникальный путь загрузки и должен скачиваться по этому пути, а в настройках главного контент сайта должна быть логика по его подключению в определённый контейнер
Мне кажется, не совсем корректно описано. Микрофронтенды живут на своих собственных хостах и могут быть загружены в другие приложения лениво. Для этого используют ModuleFederation из Webpack 5. В конфиг заранее прописывают какие модули (микрофронтенды) могут быть запущены. А еще, есть ощущение, что бессмысленно создавать микрофронты на разных фреймворках, тк придется скачивать бандлы всех этих фреймворков. Лучше писать на одном, а в конфиге указать какие зависимости у приложений одинаковые, чтобы юзер скачивал их не больше одного раза.
Отличная тема! Мне бы очень хотелось посмотреть, как оптимально организовать совмещение различных css-библиотек, например, весь проект на Materialize, а вот какой-нибудь слайдер прикрутить с Bootstrap. Еще интересно было бы посмотреть про сессии в Ноде, по работе с куками в бэке и на фронте. Интересна интеграция в проект сторонней аутентификации, через гугл, к примеру. Интересна двухфакторная авторизация, с подтверждением по почте/телефону. Короче, жду))) Удачи тебе во всем!
Канал замечательный. Проштудировал все видео про создание CRM на vue, просто шикарно. Для начинающих самое то. Спасибо большое, ждем новых видео, особенно интересно по vue
Владилен, в какой-то момент видоса я вдруг осознал, что полностью понял программирование. Все твои объяснения и весь код стал кристально ясным и понятным. По сути, программирование - это действительно своего рода общение;) Спасибо Вам, дорогой друг
@@VladilenMinin да, потому что данный архитектурный подход имеет место в очень крупных проектах, когда одной команде приходится ждать, пока задеплоит другая, пока соберётся (в плане сборки проекта) огромный монолит и т.д. Для проектов средней величины, наверное, мало смысла в подобном подходе.
Кромешный ад. Не дай господь мне столкнуться с таким чудом по работе. Мало того что мы в "рантайм" тянем каждый фреймворк на котором пишут приложение, так ещё и прослойки-адаптеры для них, чтобы это чудо запустилось. В итоге, получаем полуживое приложение, которое со скрипом общается меж своими внутренностями. Единственный плюс лишь в том, что можно команду разработчиков за копейки собрать. Так что, если стоит задача собрать приложение в бюджет булки хлеба, и без планов на поддержку с вашей стороны - Вариант ещё может чего-то стоить.
@@anotherakuma Ещё как неприятно, но зато экономно. Только до сих пор в голове уложить не могу одно: Даже если у разношёрстная команда, где каждый пишет код на том, на чём может - Как это, в дальнейшем, проблему нехватки кадров решит. Да и со взаимозаменяемостью внутри команды проблемы большие приходят. Короче, я правда этого не понимаю...
Привет! Большое спасибо за крутой контент. Ты растешь, мы тоже не стоим на месте и хотелось бы видеть больше видео направленных на архитектуру веб приложений, выбор технологий и тд. (син-архитекторские штуки) Спасибо:)
Это можно сделать по-другому. Под каждое приложение определенный репозиторий. Выбираем главный и подключаем в него придаточные через npm link (подключаются как dependencies), и подключаем в основной тегом в нужное место. Связь через общий стор, или стор каждого отдельного репозитория, если это написано на 1 фреймворке, либо кастомное решение стора в случае разных фреймворков
Ах, какой красивый и умный мужчина) Недавно начала работать с Vue.js. Наткнулась на это видео случайно, но была рада, что я не одна люблю извращаться :D Было очень интересно, с меня подписочка)
Привет уже давно твой подписчик. Очень нравится твои видео, и как ты подаёшь материал. Сам начал записывать видео. Например про микрофронтенды, на angular. А так цель немного другая, стараюсь записывать всякие тонкости в технологиях, которые использую.
Владилен, приятно видеть, когда вы, как человек, который обладает значительными знаниями и практикой в разных технологиях, честно и открыто говорите: "а вот это я не знал, но узнал, разобрался и вам, друзья, расскажу и покажу что это и как выглядит". Спасибо большое! Если будет желание/возможность/время, то не могли бы вы показать, как вместе работают: Nest - GraphQL-ArangoDB. Хотя бы на уровне: вот так подключать, вот так включать. Вообще ничего нет в рунете по теме. Спасибо :-)
Владилен, рассмотри еще Module Federation для микрофронтендов ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-pcY8-pDGLkI.html По сравнению с single-spa он позволяет шарить общие модули; каждое приложение это независимая webpack-сборка, и приложение "собирается" в браузере; позволяет строить интересные гибриды, когда вставляется компонента с другого приложения и в коде это выглядит как-будто используется компонента из соседнего файла.
У меня лет 5 назад был SPA-проект на bootstrap+jQuery, в котором реализована идея плагинизации: сервер отдает список подключенных (оплаченных пользователем) фич-микросервисов, фронт читает этот список и загружает соответствующие js-файлы через "добавить в head тег "), которые "находят" себе место на SPA. Когда визуально компоненты можно разнести - это (как выше отмечалось) можно сделать и на 'ах. А вот когда в едином SPA что-то дорисовывается или меняет логику - это квест. К сожалению, с переходом на React пришлось "потерять" эту крутейшую штуку и прийти к фронту-монолиту. В итоге, даже если пользователь не оплатил какую-то фичу, по факту при загрузке страницы эта фича ему грузится (но не работает) - такое себе решение. Но уход от вермишели кода на jquery к компонентам на React в целом многократно прибавил надежности
Я считаю это извращением, но может понадобится когда нужно срочно написать за час модуль для vue, но в гугле ты нашел его только на реакте, тогда вполне годные костыли получатся)
При разработке на реакт ты сразу начинаешь страдать изза размера бандла, но придумали же микрофронтенды!! ТЕПЕРЬ можно и реакт библиотеку тянуть и вью, вот бы еще ангуляр подключать тогда приложение точно будет удобно и быстро работать
А какой практический смысл такого подхода? Юзать две либы по одному маршруту, загружая обе библиотеки не очень рационально получается. Наверное, есть смысл разные либы всегда по разным маршрутам.
В целом прикольно, но мне кажется тяжело в использовании и особенно в рефакторинге, потому что при наличии нескольких либ, например река и вью, человек, который будет рефакторить должен будет знать и то и то. Плюс у приложух разная скорость загрузки, порядок загрузки компонентов и запросов нельзя будет поменять. Владилен, подскажи пожалуйста, у тебя макбук 16 или 13 дюймов и во время разработки, подключаешь ли ты дом мониторы?
Для ознакомления с темой микросервисов - ок. В реальности их спользование под большим вопросом. Не, не так... под ОГРОМНЫМ вопросом (даже целой серией вопросов) - а надо ли оно вам действительно?
@@max_mgtow не только поэтому. Вот, на примере, который был рассмотрен. Разделил ты на блоки, у каждого свой микросервис. И ты такой: "О господи! Как же я охренителен!". А потом так - ЧИК! - и тебе надо сынтегрировать взаимодействие 2 микросервисов, потому как у каждого своя отдельная база и надо как-то синхронизировать состояния и обеспечивать транзакционность и т.д. и т.п. А ещё это не приносящий тонну бабок проект, а очень даже пилотный, а тебе надо уйма времени для поддержки твоего хитрого набора микросервисов. И ты такой уже тонешь в болоте этих проблем: "Оу... вечно я во что-то вступлю... то в дерьмо, то в пионеры...". Така фигня, малята.
С точки зрения программирования - это просто интересно, но нежиснеспособно. А вот с точки зрения бизнеса, к сожалению, очень даже реальный кейс. Например, есть две команды разрабов, одна знает vue, другая - react. Бизнес давно ждёт фич и по отдельности ресурсов каждой команды не хватает. Дальше начинается веселье. У меня как-то был опыт по встраиванию angular приложения во vue приложение, которое, в свою очередь, работало на рельсах. В принципе, все работало и задачи бизнеса решало, а на производительность все клали.
А мне этот подход прям понравился, гибкость нереальная. А какой связавшись стор интересно можно использовать вместо window, чтобы это было не костыльно.
оно интересно, но в этом случае тащится бандл react и vue, зачем? чтобы скрестить одно с другим? даже если будет два приложения vue, то каждое в итоге либы потащит, общий размер кода получаемого юзером будет расти
Если раньше даже при использовании одно фронтенд фреймворка собиралось "полмира". Теперь собираться будет вообще "весь мир". А потом удивляются почему на "сяоми тыщ за 10" приложение чуть сложнее hello_world безбожно тормозит (либо вообще не работает).
Контент интересен, спасибо. Один только вопрос зачем, а самое главное нахрена?)) давайте один проект будет лепить команда по вью, команда по ангуляр и команда реакщиков) раньше мы плавали в фекалиях индусского кода, почему бы теперь не добавить ещё сюда и микро-фронтенд на разных фреймворках и соединять их йух пойми чем)
@@VladilenMinin Спасибо за ответ. Конечно можно, но все же я думаю лучше взять один фреймворк и разбить его как Module Federation или в Angular вообще есть возможность разбивать по проектам приложение. За контент отдельное спасибо, меня спрашивали вопросы по микрофронтендам на собеседовании
У меня была недавно немного иная ситуация. Даже не знаю, можно ли это назвать микрофронтендом. Есть несколько SPA страниц на Vue и React. Необходимо было создать отдельный виджет, который можно подключить к любой из SPA, причем без публикации в npm. Хотелось сам виджет сделать на Vue. Пришлось помучиться с реализацией, но уверен, если бы была видео-инструкция от Владилена, это было бы проще)
Добрый день. Владлен Подскажите можно ли найти что-то подобное в принципе? Как лучше поступить ? Писать игру с нуля не получится точно! Простая карточная игра (качество и сложность не важно. лучше что-то по проще..) HTML, CSS, JS, MySQL Описание: Регистрация игрока, Минимум два участника Спасибо
В теории микросервисов упоминались динамически создаваемые сущности с заданным временем жизни. Которые создаются, отрабатывают или падают, умирая передают состояние на новый круг. Но это наверное уже совсем другая история
Странно, что стор делает что-то с данными, а не просто хранит их. Если нажатие кнопки обрабатывается во VUE, то пусть там будут методы для этого. Иначе у нас еще 3 слой появляется.
А интересно, главные компоненты с ID React и Vue (index.html), может быть один или можно несколько и если несколько, то как это указать в react.app.js и vue.app.js? Это бы позволило обойти вот это вот представление глубокого дерева после написания всего приложения.
у меня есть проект на github. на который я включил по ошибке dependabot[bot]. и он у меня появился в авторах проекта!! это очень бесит... и как я не пытался его убрать. так и не получилось. подскажите как как убрать этот бот безопасности dependabot[bot]!!! плиз...
плз. если можно... сделать урок, как создать свою библиотеку для React, хотя бы ui[с аккордеоном, модульными окнами, своим слайдером, ...args] => return с выгрузкой в npm, и с примером потом как её использовать. Понятное дело найдутся умники которые напишут : "это уже всё создано, зачем?". Но интересен сам процесс как создать свою ui библиотеку хотя бы и понять как их делать, шаг за шагом. Инструменты использовать могут все, а создавать их единицы. (с) Неизвестный прогер :) А то я что-то ничего толкового не нашел, какие -то лекции с достаточным количеством литража воды в уши (( Спасибо огромное за Ваш труд.
@@r45her на данный момент сам пользуюсь VSCode, но хотелось бы понять, в чем же лучше WebStorm. В инете нет толком сравнений нормальных. Хотелось бы услышать от человека, который работал и на том и на этом. Просто VSCode с плагинами тоже крут, но в чем же на самом деле Storm лучше...
Таак, а разве micro frontend архитектура не то когда условно есть роут с логином и роут с настройками пользователя и вы с помощью nginx ссылаетесь на разные SPA
Всем привет, я учу vue и столкнулся с проблемой при передаче объекта через props например: В родителе пишу data: () => ({ person: { name: 'Ivan" } }) В файле компонента пытаюсь вывести имя {{person.name}} props: ['person'] Но получают ошибку Cannot read properties of undefined (reading 'name') но если отдельно передавать не person а person.name в родителе, то все работает Мб кто-то подскажет где я ошибаюсь?
если честно, то видео ни о чем. Инетересно было бы увидеть, как устроен роутинг (это все-таки SPA), как встраивать компоненты Recat во Vue или наоборот, а сделать такое приложение, как в ролике можно и без дополнительных библиотечек
