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