Live-coding: Чистая архитектура во фронтенде / Александр Беспоясов

Понравилось видео? Забирай весь плейлист на is.gd/kChYnl или купи билет на следующий сезон конференции is.gd/f6ZLuS.
Ссылки и дополнительные материалы: bespoyasov.ru/...
Твитер для связи: / bespoyasov
TDD: зачем и как
Ссылки и дополнительные материалы: bespoyasov.ru/...
Расшифровка доклада: bespoyasov.ru/...
Твитер для связи: / bespoyasov

[@marksalabutin621]

Спасибо за доклад, очень приятно наблюдать за тем, как зрелые практики software design проникают во фронтенд. Отдельно улыбнул момент на 1:01:36 , когда Александр говорит, что createOrder это чистая функция и что она с одинаковыми параметрами всегда возвращает одинаковый результат, а там используется new Date().

[@bespoyasov]

Да, я потом тоже это заметил, стало стыдно 😅 В статье по мотивам доклада я это поправил. Да и вообще написал в ней всё, что не успел рассказать за эти полтора часа 😃

[@eugeniabashieva2536]

Респект Александру за крутой доклад. Наконец-то увидела человека, который думает об архитектуре фронтенда. Обычно приходишь на проект, а там данные из бэкенда напрямую в представление отдаются. И когда говоришь, надо бы как минимум прослоечку в виде data mappera добавить народ вообще не понимает зачем.

[@leonidpetrov14]

Очень круто и понятно! Блог докладчика вообще от боженьки просто!

[@tarassavchenko2317]

У Саши оооочень крутые доклады)

[@kulakofft4]

вместо алиаса можно использовать User['id'], ещё более наглядно на мой взгляд

[@artem_r]

Спасибо за великолепный доклад! Небольшой вопрос касательно 51:34 - разве мы не хотим держать юайный фреймворк реакт за пределами нашего приложения? А то получается что мы завязываемся на конкретную реализацию пользовательского интерфейса. Еще немного не понятно чем обусловлено создание именно хуков - в примере не используются возможности хуков, и по сути получается это простые функции с названием содержащим use?

[@bespoyasov]

Хотим! Именно поэтому я делаю оговорку, что в каноническом исполнении функция юзкейса была бы вынесена за пределы хука, а сервисы были бы переданы юзкейсу через последний аргумент или с помощью DI. Я также написал об этом подробнее в Readme к исходникам и в посте в блоге по мотивам доклада. Хук там по двум причинам: 1. Доступ к стору можно получить только через хук, потому что в качестве стора используется React.Context + хуки. 2. Чтобы показать, что хуки - не помеха 😃 Юзкейс вполне можно было бы использовать и без хуков напрямую, если бы он использовал только сервисы, которые предоставляются без хуков. Но и сейчас хук можно использовать просто как обёртку для юзкейса, который можно вынести и использовать изолированно.

[@ddushkin]

Ээээ. Ссылки в описании к докладу автора про TDD, а не к этому.

[@igor_cojocaru]

Вместо type Order = { ..... user: UniqueId; }; обычно пишу: type Order = { ..... user: User['id']; };

[@dmitrybogo8784]

Интересный доклад. Спасибо! В докладе упоминалось про микрофронтэнд и webpack federation. Этот стрим уже вышел? Не могу найтию Спасибо!

[@ddushkin]

Микрофронтенд - это развлечение для команды, где есть 2-3 выделенных человека только про инфру. То есть это не нужно примерно никогда)

[@dmitryivanov6812]

Спасибо за доклад! Хотя видел уже его фрагменты на просторах Инет, но от первого лица всегда интереснее слушать. ;) Вопрос к автору. Все моменты связанные с проектированием так или иначе завязаны на время, а также на возможные пробы и ошибки... Что если "практически все", включая сам домен и бизнес-логику, уже реализовано на backend, а от frontend требуется только "красиво показать данные" и предоставить "набор кнопок" для запуска каких-то процессов на бэке (только UI!). Стоит ли тогда вообще "городить весь этот огород", если "модель фронта" это просто "зеркало", какой-то части "модели бэка"? Где поставить тут "точку баланса", чтобы не переписывать уже готовые "части бэка", например, ту же валидацию, и удобным/современным/функциональным фронтом?

[@bespoyasov]

Спасибо! :-) Если вся бизнес-логика на бекенде, фронтенд может без проблем превратиться в «интерфейс» к сервису без сложной архитектуры и логики. Точка баланса - в пересечении между ресурсами, которые проект готов потратить, требованиями от приложения и необходимости в сложном клиенте. Если от клиента требуется только показать несколько кнопок и по нажатию отправить команды в API, вероятно, это будет оверхедом. (Даже Реакт не особо будет нужен.) Если в приложении бекенда нет, логика есть, данные хранить как-то надо, а пользовательские сессии продолжительны, будет смысл позаботиться об архитектуре заранее.

[@TheSky5028]

чел ты ваще про бекенд слышал? все что тебе надо на фронте это получить данные с бека и отрисовать, платежи у него блять на фронте

[@vanyamaloy9170]

Так он говорит что платежи на бэке обрабатываются и то что пример игрушечный Используя интерфейс он защищает себя от изменений который могут произойти потом. Плюс спокойно может тестировать свое приложения не имея зависимости от реального сервиса платежей

[@pashkes]

Какая то спешка чувствуется, как будто за спиной кто то стоит и подгоняет

[@ivanjs7675]

возьмите feature-sliced и успокойтесь! хватит придумывать свое! потом приходишь в такой проект и мучаешься

[@bespoyasov]

О feature sliced в докладе упоминается. К тому же доклад о том, как воспринимать концепт «Чистой архитектуры», а не о том, «как буквально писать код».

[@6602-w2k]

feature sliced говорит как раскладывать код по папочкам, не более

[@АлексейСтупников-д4у]

к сожалению, fsd не серебрянная пуля. искусственное разделение кода на entities/features нарушает паттерн low coupling/high cohesion. и есть неопределенность в том, что считать фичей, а что сущностью. есть ещё другие вопросы. сейчас склоняюсь к использованию fsd не в чистом виде, а в виде модификации