Было полезно, спасибо) Если можно, то можно накидать простой пример (или кинуть ссылку), как ты реализовал через context и providers. Вроде понятно, но хотелось бы глянуть пример, такой реализации еще не видел просто
Я за свои там фиг знает уже сколько лет пришёл к модульным решениям по типу /modules/app /modules/admin /modules/admin/modules/dashboard..... Вся логика в хуки и допустим хук который раньше использовался только в одном модуле лежит в (modules/admin) а теперь используется в нескольких перекидывается на верх (/hooks) Очень люблю использовать подход виджетов где в одной папочке лежит вся логика, сервисы и ui это прям очень удобно и тоже виджет может быть положен на какой надо уровень Плюсы: Ты всегда знаешь где примерно используется виджет на каком уровне модулей Если что то упадёт то не всё так как для каждого виджета свой запрос на получение данных Виджеты могут работать спокойно везде, если верхний конфиг настройки api, ui kit etc... такой же Минусы: Всегда хочется запихнуть виджет в корень проекта ))) Много запросов в api, что бы отрендерить квадратик с циферкой свой запрос, бэкендер прям будет очень рад ))) хотя для serverless вообще заходит В принципе очень похоже то что я делаю только без контекста.... тема интересная если очень много логики на фронте... у меня в основном в проектах весь state лежит на сервере и гоняется через useQuery() что очень удобно но надо договариваться с бэком Ещё Pages разделять с папочкой Views. Pages для аналитики, react-helmet, проверка входных данных с урла итп... а Views для отрисовки уже контента PS: Если кто то дочитал)) то можете даже кинуть коммент почему так не правильно ))) у каждого свой подход и каждый прав по своему
Подход хороший! На последнем проекте тоже использовал React Query для работы. Если делать инверсию между модулями, то всё будет путём. Спасибо за комментарий!
А есть опыт построения действительно большого приложения на этой базе? полагаю, что в какой-нибудь crm (в которой пускай 100 фич), это в кашу превратиться, так что не стал бы называть ее лучшей, тем более я сходу вижу тут как минимум несколько проблем связанных с рефакторингом и взаимодействием между разработчиками . Безусловно, в контексте фразы "архитектура приложения" - структура папок имеет место быть, но прикол в том, что архитектура приложения - это совокупность решений, которые решают какие-то проблемы в контексте конкретного приложения\команд\экосистемы.
Да, есть опыт, по началу мы делили фичи на под фичи (features/depositOperations/earlyTermination), растет проект -> приходят разрабы, делим проект на микрофронты. Естественно, что нету «лучшей» архитектуры, на данном примере было удобно показать основные принципы, на большом проекте невозможно сделать так, чтобы не было проблем, даже лучшие программисты не могут на 100% предугадать в какую сторону пойдет проект. Код-ревью решало проблему с определением куда и что класть. Во время сжатых сроков иногда не было времени на это, старались рефачить во время фича фризов Спасибо за подробный комментарий!
@@y0na24 а нужны ли вам микрофронты ? ) Может модульность? Если интересны другие подходы, то можешь на гитхабе по поиску " frontend-modules-mvvm" глянуть Задача начальной архитектуры как раз таки в том, что бы подготовить проект к жизни, так как у него имеются разные стадии, и на каждой из них позволяются некие допущения, но боль приходит при переходе с одной стадии на другую. Вот ты написал что делите проект на микрофронты => проводите глобальный рефакторинг, потому как текущая архитектура полагаю не готова под это, а задача как раз таки избежать этого. P.S: В обзоре хотелось бы слышать не только о плюсах, но и о минусах
@y0na24 эх: зарубило сообщение, ну да ладно, повторюсь. Микрофронты - отнюдь не панацея, на мой взгляд они несут больше проблем чем плюсов (Нужны они только в одном случае - если вам необходим независимый релизный цикл, в остальном проблемы закрывает - модульный подход). Можешь на гите (frontend-modules-mvvm) глянуть. У проекта обычно существуют разные стадии и например на стадии mvp многое допускается, но основная боль приходит при переходе с одной стадии на другую, и вот как раз задача архетиктуры как раз - решать эти боли, а fsd, к примеру, их не решает и за выбор ее расплачиваются многие разработчики. По этому вы сейчас не взяли и скопом перевели все на микрофронты, а каждую фичу выносите и рефакторите приложение. Пожелание по видео - хотелось бы что бы ты разбирал не только плюсы, но и минусы
при чем тут структура папок в проекте к архитектуре? это понятия вообще из разных вселенных. Можно написать архитектурно правильный проект в одном файле, и наоборот написать кашу в проекте где есть структура папок
Есть архитектура на уровне кода, есть архитектура на уровне решений, я понимаю о чем ты говоришь, но если честно, не хотелось бы работать на проекте, где у тебя 10к строк кода в одном файле. Как по мне слово «архитектура» в контексте построения папок в проекте допустимо.
@@y0na24 Ну скорее, архитектура папок уже натягивается на архитектуру проекта в целом, в любом случае, как бы оно там не располагалось, примерно одна и та же суть будет, просто возможно разные названия и чуть другая структура папок, главное что под этим скрыто
Красавчик. Удачи тебе в развитии канала и менторстве!!
Большое спасибо!
Удачи в развитии канала) Спасибо большое, всё понятно объяснил))
Спасибо :)
Годный контент! Привет от коллеги с проекта, где работали вслепую и была сломанная колбэк форма(115фз)😁
Привет, Бадма :)
Хорошо, что всё закончилось
Спасибо огромное, все максимально подробно разобрано, интересный подход с разбором собеса!
Спасибо!
Спасибо за видео, все максимально подробно и понятно. Жду еще видео про собеседования!
Топ, спасибо большое Матвей!
Вам спасибо за просмотр, Павел :)
@ когда следующий ролик?
На днях постараюсь выпустить
Отлично снято
Спасибо!
Очень круто, спасибо!
Спасибо за комментарий, рад стараться!
Огромное спасибо! Как мало в youtube хорошего синьорского контента! Подписка и репост, однозначно!
Спасибо большое за поддержку! Буду продолжать радовать контентом :)
не бросай делать контент, неплохо получатся)
Спасибо за поддержку! Буду стараться улучшать подачу с каждый разом
Как забавно что в итоге я тоже пришел к такой архитектуре спустя пару лет
Круто! И она хорошо себя показывает на большинстве проектов :)
Матвей, вы мой герой!
Было полезно, спасибо)
Если можно, то можно накидать простой пример (или кинуть ссылку), как ты реализовал через context и providers. Вроде понятно, но хотелось бы глянуть пример, такой реализации еще не видел просто
Конкретные реализации будут охватываться в следующих видео, ссылку предоставить не могу, т.к рабочие проекты.
Спасибо большое за комментарий!
Можешь написать в личку, подскажу
@@y0na24 да примерчик бы живой увидеть, пусть самый маленький, но отражающий то что показано в видео...
@@operunв тг канале выпустил видео с ссылкой на гитхаб, где на простом примере можно понять, как реализовывать инверсию с помощью контекста
Было полезно, спасибо
Рад стараться, спасибо!
Я за свои там фиг знает уже сколько лет пришёл к модульным решениям по типу
/modules/app
/modules/admin
/modules/admin/modules/dashboard.....
Вся логика в хуки и допустим хук который раньше использовался только в одном модуле лежит в (modules/admin) а теперь используется в нескольких перекидывается на верх (/hooks)
Очень люблю использовать подход виджетов где в одной папочке лежит вся логика, сервисы и ui это прям очень удобно и тоже виджет может быть положен на какой надо уровень
Плюсы:
Ты всегда знаешь где примерно используется виджет на каком уровне модулей
Если что то упадёт то не всё так как для каждого виджета свой запрос на получение данных
Виджеты могут работать спокойно везде, если верхний конфиг настройки api, ui kit etc... такой же
Минусы:
Всегда хочется запихнуть виджет в корень проекта )))
Много запросов в api, что бы отрендерить квадратик с циферкой свой запрос, бэкендер прям будет очень рад ))) хотя для serverless вообще заходит
В принципе очень похоже то что я делаю только без контекста.... тема интересная если очень много логики на фронте... у меня в основном в проектах весь state лежит на сервере и гоняется через useQuery() что очень удобно но надо договариваться с бэком
Ещё Pages разделять с папочкой Views. Pages для аналитики, react-helmet, проверка входных данных с урла итп... а Views для отрисовки уже контента
PS: Если кто то дочитал)) то можете даже кинуть коммент почему так не правильно ))) у каждого свой подход и каждый прав по своему
Подход хороший! На последнем проекте тоже использовал React Query для работы. Если делать инверсию между модулями, то всё будет путём. Спасибо за комментарий!
лучшее обучение!
👍👍👍
😊
А есть опыт построения действительно большого приложения на этой базе?
полагаю, что в какой-нибудь crm (в которой пускай 100 фич), это в кашу превратиться, так что не стал бы называть ее лучшей, тем более я сходу вижу тут как минимум несколько проблем связанных с рефакторингом и взаимодействием между разработчиками .
Безусловно, в контексте фразы "архитектура приложения" - структура папок имеет место быть, но прикол в том, что архитектура приложения - это совокупность решений, которые решают какие-то проблемы в контексте конкретного приложения\команд\экосистемы.
Да, есть опыт, по началу мы делили фичи на под фичи (features/depositOperations/earlyTermination), растет проект -> приходят разрабы, делим проект на микрофронты.
Естественно, что нету «лучшей» архитектуры, на данном примере было удобно показать основные принципы, на большом проекте невозможно сделать так, чтобы не было проблем, даже лучшие программисты не могут на 100% предугадать в какую сторону пойдет проект. Код-ревью решало проблему с определением куда и что класть. Во время сжатых сроков иногда не было времени на это, старались рефачить во время фича фризов
Спасибо за подробный комментарий!
@@y0na24 а нужны ли вам микрофронты ? ) Может модульность? Если интересны другие подходы, то можешь на гитхабе по поиску " frontend-modules-mvvm" глянуть
Задача начальной архитектуры как раз таки в том, что бы подготовить проект к жизни, так как у него имеются разные стадии, и на каждой из них позволяются некие допущения, но боль приходит при переходе с одной стадии на другую. Вот ты написал что делите проект на микрофронты => проводите глобальный рефакторинг, потому как текущая архитектура полагаю не готова под это, а задача как раз таки избежать этого.
P.S: В обзоре хотелось бы слышать не только о плюсах, но и о минусах
@y0na24 эх: зарубило сообщение, ну да ладно, повторюсь.
Микрофронты - отнюдь не панацея, на мой взгляд они несут больше проблем чем плюсов (Нужны они только в одном случае - если вам необходим независимый релизный цикл, в остальном проблемы закрывает - модульный подход). Можешь на гите (frontend-modules-mvvm) глянуть.
У проекта обычно существуют разные стадии и например на стадии mvp многое допускается, но основная боль приходит при переходе с одной стадии на другую, и вот как раз задача архетиктуры как раз - решать эти боли, а fsd, к примеру, их не решает и за выбор ее расплачиваются многие разработчики.
По этому вы сейчас не взяли и скопом перевели все на микрофронты, а каждую фичу выносите и рефакторите приложение.
Пожелание по видео - хотелось бы что бы ты разбирал не только плюсы, но и минусы
@@rioz00 Спасибо за коммент! Учту пожелания в следующих видео :)
Здравствуйте, спасибо за видео! Куда вам можно написать по поводу менторства?
Вот сюда t.me/y0na24
Збс, спасибо
🤝
при чем тут структура папок в проекте к архитектуре? это понятия вообще из разных вселенных. Можно написать архитектурно правильный проект в одном файле, и наоборот написать кашу в проекте где есть структура папок
Есть архитектура на уровне кода, есть архитектура на уровне решений, я понимаю о чем ты говоришь, но если честно, не хотелось бы работать на проекте, где у тебя 10к строк кода в одном файле. Как по мне слово «архитектура» в контексте построения папок в проекте допустимо.
@@y0na24 Ну скорее, архитектура папок уже натягивается на архитектуру проекта в целом, в любом случае, как бы оно там не располагалось, примерно одна и та же суть будет, просто возможно разные названия и чуть другая структура папок, главное что под этим скрыто
Следующий Ulbi TV растет, запомните