ฝัง
- เผยแพร่เมื่อ 14 ต.ค. 2024
- Ближайшая конференция - HolyJS 2024 Autumn, 7 ноября (online), 14-15 ноября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/K18Cxd
- -
Скачать презентацию с сайта HolyJS - jrg.su/k2SDAM
В 2024 году в архитектуре фронтенда одновременно много и мало того, что может помочь построить эффективную архитектуру фронтенд-приложения. Такой парадокс из-за того, что самих инструментов - много. Но каждый из них подходит под ограниченный круг применения, а их сочетание этот круг еще больше сужает.
В последнее время спикер раскрывал тему архитектуры фронтенда на нескольких конференциях и митапах. Но раскрывал каждый раз только одну какую-то часть. Теперь он подводит итог всего «странствия» по архитектуре фронтенда.
На примере билда персонажа (aka проекта) в RPG простым языком разберем, какие инструменты (aka артефакты) мы можем использовать для построения архитектуры проекта. Рассматриваем готовые архитектурные подходы (aka готовые билды). Каждый инструмент изучаем со стороны баффов и дебаффов для проекта. Также рассматриваем комплекты артефактов (aka инструментов), которые в сочетании друг с другом образуют новые баффы или нейтрализуют определенные дебаффы друг друга. В конце Александр показывает небольшой «гайд», как нам прокачивать нашего персонажа (развивать проект) в зависимости от места спавна (требований и ограничений от бизнеса).
![โรงเรียนดัดสันดาน นักเรียนเถื่อน..!! [โรงเรียนไดเม่]](http://i.ytimg.com/vi/vRKPeXn4Fl4/mqdefault.jpg)
Весь доклад ощущается как интригующая подводка к интересному докладу
Круто, Александр! Сложные вещи достаточно понятным языком.
Не смог вынести какой-то практической пользы из доклада. Возможно ориентировано на начинающих ребят, которые только знакомятся с концепциями и такие обзорные доклады могут им пригодится.
У слоёв основной минус это то что для некоторых крупных фитч их нужно много, а для некоторых мало, но все равно придется их писать так как архитектура обязывает, и получается что для 1 кнопки нужно сделать 10 файлов и 10 папок с булерплейт кодом в 1 функцию которая не чего не делает, еще лежит в разных местах проекта чаще всего.
Какой смысл хотел донести автор?
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.
Вот и вся архитектура, без мечей и магии...
Прекрасный базовый доклад, отличный тизер перед погружением в мир архитектуры, большое спасибо
За героев тупо лайк
Это в какой вселенной бизнес приходит и просит Axios на Fetch поменять? 🤯
мда. бубнит-бубнит что-то непонятное без единого примера. потом бац. решил внезапно показать элементарный код как вложенные ифы поменять на логическое ИЛИ. для кого эта лекция ?? вы реально думаете что человек, которого интересуют вопросы связанные с архитектурой фронтенда не знает как вложенные ифы убрать ?
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 сейчас на каждом заборе написано
Я понимаю если была бы проделана реальная исследовательская работа, к которой можно обращаться в ходе доклада или после него, где был бы расписан реальный опыт применения.
А так это лишь ведро воды из которой получишь минимум пользы.