konstantin_shopot May 10 at 11:46

Разбираем Bulletproof React: как не утонуть в хаосе собственного кода

11 min

9.1K

ReactJS * TypeScript * JavaScript *

Review

From sandbox

Comments 11

AndreyDov May 10 at 12:36

Более интутивно понятный подход в сравниении с FSD

EvaKerrigan May 10 at 13:58

Работала и с проектами на Bulletproof React и с проектами на FSD. Проекты на FSD это кашекод в котором крайне трудно что то искать, в отличие от Bulletproof.

DmitryKazakov8 May 10 at 17:22

Видно, что автор этого подхода действительно его выстрадал, поработав с десятком проектов на лапшекоде Redux и разочаровавшись в FSD. И в целом сделал логичный следующий шаг, решив несколько проблем легаси-проектов.

Осталась всего сотня-две таких шагов и получится что-то нормальное - без прибивания гвоздями к Реакту, хукам, с нормальной файлогенерацией и автовалидацией, со встроенным эффективным feedback loop для LLM, со стабильными SSR / Widget режимами, без 2-3мб бандла на старте и т.п. И пройдя это все и протестируя на десятках проектов с разного размера командами, окажется что Flat Architecture (я предпочитаю называть "классическая файловая структура") не так уж и плоха, если скомпоновать в формализованные слои.

Но как шаг для борьбы с легаси в условном 2018 году выглядит отлично. Как старт для новых проектов - очень сомнительно.

Iluha05 May 11 at 18:41

Я как раз не стал бы использовать flat architecture на новых проектах, если есть четкое осознание что проект планируется вырастить до 100К+ строк кода. Все что меньше - на самом деле без разницы какой подход применять.

Имею удовольствие поддерживать подобный легаси-проект, стартовавший в середине 10х, плоская структура доставляет много боли, потому что люди на проекте менялись и каждый привносил свое видение модулей, не было какой-то единой методологии, дерево из сотен компонентов превратилось в кашу. На подобный проект (новый) прямо сейчас я бы взял или усеченный FSD (отточили на еще одном проекте) или Bulletproof. Скорее второе, т.к. FSD даже на средних размеров проектах вызывает фрустрации внутри команды. Bulletproof в этом плане выглядит проще и интуитивно понятнее.

IslamX May 10 at 18:25

Между UI State и Application State в некоторых более-менее сложных приложениях есть еще один уровень стейт менеджемента - это локализованные состояния для группы компонентов связанных между собой горизонтально и/или вертикально. Назвать ее можно как угодно: Widget State, Feature State. Это в основном композиции из нескольких компонентов которые все вместе образуют какой то цельный виджет или логику. Выносить состояния на уровень Application State размазывает локальную логику на глобал, а опустить на уровень UI State (useState, useReducer, Context) приводит к запутанным и не оптимизированным конструкциям типа prop drilling

ivankprod May 11 at 00:36

Если у вас useContext приводит к prop drilling, значит вы неправильно его используете

IslamX May 11 at 09:23

Я немного скомкал этот момент, context приводит к неоптимизированным и бойлерплейтным многословным конструкциям а те другие к prop drilling

ivankprod May 16 at 10:11

Ни к чему такому он не приводит, как раз таки наоборот, с помощью context легко можно избавиться от всяких многословных конструкций и prop drilling. У Вас точно есть экспертиза в данном вопросе? :)