Не смог вынести какой-то практической пользы из доклада. Возможно ориентировано на начинающих ребят, которые только знакомятся с концепциями и такие обзорные доклады могут им пригодится.
У слоёв основной минус это то что для некоторых крупных фитч их нужно много, а для некоторых мало, но все равно придется их писать так как архитектура обязывает, и получается что для 1 кнопки нужно сделать 10 файлов и 10 папок с булерплейт кодом в 1 функцию которая не чего не делает, еще лежит в разных местах проекта чаще всего.
Архитектура фронтенда состоит из 3-х частей: 1) отображение, View (собственно, это и есть слой компонетов в Реакте, Вью, Ангуляре и пр.) 2) хранилище состояния (Redux, Vuex, Pinia, NgRx) 3) т.н. бизнес-логика, то есть та часть, где у нас походы по сети, валидации, рассчеты и прочее, назовем данную часть "сервисами" По сути, все тот же MVC, только немного по другому разделен. Что важно, 1-й слой (View) может знать только о хранилище состояния - делать из него выборки и дергать экшины если юзер сделал какое-то действие. В слое View не должно быть никаких хождений по сети внутри хуков, никакой логики - все это вынесено в слой сервисов; слой View занимается только отображением информации из хранилища, и может дернуть только экшин из хранилища (а экшин должен тригернуть сервисный слой, результат работы которого обновить состояние в хранилище, и в конце-концов новое состояние будет отображено слоем View). По своей сути, данный слой - это View из MVC. 2-й слой, хранилище, ничего не знает о слое View, но знает о слое сервисов. Слой хранилища хранит состояние приложения, имеет средства выборки состояния в нужных разрезах; а также имеет набор экшинов - обращений к слою сервисов, по итогу работы которых экшин может поменять состояние. По своей сути, данный слой - это Controller из MVC. 3-й слой, сервисов, ничего не знает о слое View; и в идеале - также ничего не знает и о хранилище (правда, в ограниченных случаях может иметь частичное знание о слое хранилища - к примеру, если необходимо периодически изменять состояние в хранилище, но нет желания городить какие-то сложные велосипеды). По своей сути, данный слой - это Model из MVC. Вот и вся архитектура, без мечей и магии...
мда. бубнит-бубнит что-то непонятное без единого примера. потом бац. решил внезапно показать элементарный код как вложенные ифы поменять на логическое ИЛИ. для кого эта лекция ?? вы реально думаете что человек, которого интересуют вопросы связанные с архитектурой фронтенда не знает как вложенные ифы убрать ?
Мне кажется, что FSD это какой-то прикол из жанра "идеальный мир существует" и те, кто любит думать, что все можно сделать идеально, пытаются реализовать FSD ... Возможно, я и не прав, но когда методология хорошая, то и такого большого количества вопросов по ней возникать не должно. Но да, FSD в любом случае всегда лучше, чем ничего.
@@kirillmitskevich8851 FSD - это еще одна маркетинговая серебрянная пуля. К архитектуре это нечто не имеет никакого отношения. Архитектура строится исходя из технических требовани/предметной области. Для FSD нужно выразить предметную область под понятия FSD и это абсурд.
Хз какой конкретики ждете в докладе, в котором обсуждены чуть ли не все популярные архитектурные паттерны за 40 минут, естественно это будет поверхностный обзор без сложных примеров, такова концепция доклада. Целью автора, как мне показалось, было простым и понятным языком донести базовые понятия об архитектуре на фронте и ее различных проявлениях, любой начинающий после просмотра при желании может углубиться и найти уйму примеров по рассмотренным поверхностно темам, сеньерами же не рождаются) Ну и насчет чистой вы все правильно сказали, fsd основана на чистой, и именно поэтому автор доклада на фронте не рекомендует использовать чистую "чистую" архитектуру, так как она является слишком абстрактной реализацией данной идеи, подходящей под любые типы приложений. Зачем это делать, если можно использовать ее аналог, адаптированный под особенности фронта и обладающий теми же положительными качествами? (безусловно есть кейсы, когда чистая подойдет лучше ввиду специфики проекта, но в большинстве случаев fsd будет прекрасным вариантом)
@@bilbotea_bagins7318, обсуждены да, но какой смысл хотел донести автор? Какую пользу? Если про fsd сейчас на каждом заборе написано Я понимаю если была бы проделана реальная исследовательская работа, к которой можно обращаться в ходе доклада или после него, где был бы расписан реальный опыт применения. А так это лишь ведро воды из которой получишь минимум пользы.
Весь доклад ощущается как интригующая подводка к интересному докладу
Не смог вынести какой-то практической пользы из доклада. Возможно ориентировано на начинающих ребят, которые только знакомятся с концепциями и такие обзорные доклады могут им пригодится.
Это в какой вселенной бизнес приходит и просит Axios на Fetch поменять? 🤯
Какой смысл хотел донести автор?
У слоёв основной минус это то что для некоторых крупных фитч их нужно много, а для некоторых мало, но все равно придется их писать так как архитектура обязывает, и получается что для 1 кнопки нужно сделать 10 файлов и 10 папок с булерплейт кодом в 1 функцию которая не чего не делает, еще лежит в разных местах проекта чаще всего.
Архитектура фронтенда состоит из 3-х частей:
1) отображение, View (собственно, это и есть слой компонетов в Реакте, Вью, Ангуляре и пр.)
2) хранилище состояния (Redux, Vuex, Pinia, NgRx)
3) т.н. бизнес-логика, то есть та часть, где у нас походы по сети, валидации, рассчеты и прочее, назовем данную часть "сервисами"
По сути, все тот же MVC, только немного по другому разделен.
Что важно, 1-й слой (View) может знать только о хранилище состояния - делать из него выборки и дергать экшины если юзер сделал какое-то действие. В слое View не должно быть никаких хождений по сети внутри хуков, никакой логики - все это вынесено в слой сервисов; слой View занимается только отображением информации из хранилища, и может дернуть только экшин из хранилища (а экшин должен тригернуть сервисный слой, результат работы которого обновить состояние в хранилище, и в конце-концов новое состояние будет отображено слоем View). По своей сути, данный слой - это View из MVC.
2-й слой, хранилище, ничего не знает о слое View, но знает о слое сервисов. Слой хранилища хранит состояние приложения, имеет средства выборки состояния в нужных разрезах; а также имеет набор экшинов - обращений к слою сервисов, по итогу работы которых экшин может поменять состояние. По своей сути, данный слой - это Controller из MVC.
3-й слой, сервисов, ничего не знает о слое View; и в идеале - также ничего не знает и о хранилище (правда, в ограниченных случаях может иметь частичное знание о слое хранилища - к примеру, если необходимо периодически изменять состояние в хранилище, но нет желания городить какие-то сложные велосипеды). По своей сути, данный слой - это Model из MVC.
Вот и вся архитектура, без мечей и магии...
Круто, Александр! Сложные вещи достаточно понятным языком.
Продайте время кто нибудь, срочно...
верни моё время
Прекрасный базовый доклад, отличный тизер перед погружением в мир архитектуры, большое спасибо
FSD хорошь исключительно для микрофронта, Как только вы попробуете совметсить Клиентский и Админ фронтент то FSD превратит вашу жизь в АДДДДД
Приятный доклад, хорошие примеры, отлично для начинающих
За героев тупо лайк
мда. бубнит-бубнит что-то непонятное без единого примера. потом бац. решил внезапно показать элементарный код как вложенные ифы поменять на логическое ИЛИ. для кого эта лекция ?? вы реально думаете что человек, которого интересуют вопросы связанные с архитектурой фронтенда не знает как вложенные ифы убрать ?
Рассы - это глагол?
render props и composite component и есть Bridge
Доклад хороший, но сложилось впечатление, что FSD это какой-то "золотой ключ" и не имеет смысла всё что было до него. Спасибо!
С FSD лучше, чем без него. Но да, нужно практическое понимание. Теория часто не даёт конкретных ответов на многие вопросы. (It depends.)
Мне кажется, что FSD это какой-то прикол из жанра "идеальный мир существует" и те, кто любит думать, что все можно сделать идеально, пытаются реализовать FSD ... Возможно, я и не прав, но когда методология хорошая, то и такого большого количества вопросов по ней возникать не должно. Но да, FSD в любом случае всегда лучше, чем ничего.
@@kirillmitskevich8851 Судьба FSD, как и эффектора - мешать работать тем, кто не хочет думать сам.
@@kirillmitskevich8851 ситуация прямо как с Effector.
@@kirillmitskevich8851 FSD - это еще одна маркетинговая серебрянная пуля. К архитектуре это нечто не имеет никакого отношения. Архитектура строится исходя из технических требовани/предметной области. Для FSD нужно выразить предметную область под понятия FSD и это абсурд.
🎩
25:23 в условии должно быть '&&' вместо '||'
40 минут воды
Никакой конкретики
Примеры максимально поверхностны
Чистую не советует использовать, но FSD построенный на чистой у него one-love
Хз какой конкретики ждете в докладе, в котором обсуждены чуть ли не все популярные архитектурные паттерны за 40 минут, естественно это будет поверхностный обзор без сложных примеров, такова концепция доклада. Целью автора, как мне показалось, было простым и понятным языком донести базовые понятия об архитектуре на фронте и ее различных проявлениях, любой начинающий после просмотра при желании может углубиться и найти уйму примеров по рассмотренным поверхностно темам, сеньерами же не рождаются)
Ну и насчет чистой вы все правильно сказали, fsd основана на чистой, и именно поэтому автор доклада на фронте не рекомендует использовать чистую "чистую" архитектуру, так как она является слишком абстрактной реализацией данной идеи, подходящей под любые типы приложений. Зачем это делать, если можно использовать ее аналог, адаптированный под особенности фронта и обладающий теми же положительными качествами? (безусловно есть кейсы, когда чистая подойдет лучше ввиду специфики проекта, но в большинстве случаев fsd будет прекрасным вариантом)
@@bilbotea_bagins7318, обсуждены да, но какой смысл хотел донести автор? Какую пользу? Если про fsd сейчас на каждом заборе написано
Я понимаю если была бы проделана реальная исследовательская работа, к которой можно обращаться в ходе доклада или после него, где был бы расписан реальный опыт применения.
А так это лишь ведро воды из которой получишь минимум пользы.