Про деструктуризацию пропсов

Давно заметил, что она стала де-факто стандартом в React-разработке: так учат на курсах, так показывают в видосах, даже линтеры часто на это настраивают. Мне это не нравится, и я попытался понять, почему так. Начнем с минусов.

Конфликты имен и затенение переменных Получил в пропсы name. Деструктурировал. Отфильтровал список имен — в .filter() еще одна локальная переменная name. Сделал запрос, деструктурировал ответ, получил еще одну локальную переменную name. Отфильтровал массив пользователей, в сложном фильтре деструктурировал пользователя — еще одна локальная переменная name. Продолжать можно долго, смысл понятен. Как предлагают решить эту проблему? В итераторах использовать однобуквенные имена, а если есть одноименный стейт или локальная переменная на уровне компонента — переименовывать пропсу: const { name: propName } = props;. Но так мы нарушаем консистентность имен либо вынуждены переименовывать все ключи в таком стиле и теряем всю экономию. Получается хуже чем с props. Однобуквенные переменные в простых итераторах — ок, но не все итераторы простые, решение не универсально.

Читаемость кода Есть мнение что повторение props. ухудшает читаемость, я думаю, что улучшает. Потому что так мы держим данные в своих пространствах имен и всегда сразу видим, откуда они читаются. Популярны примеры с длинными однострочными компонентами, которые сильно растягиваются с props., но так в реальности никто не пишет, пропсы всегда по строкам разбиты, автоформатирование вообще все упрощает.

А вот такие я нашел плюсы деструктуризации

Сокращение кода Один раз распечатали и больше не нужно писать props.. Не могу поверить, что это для кого-то является проблемой, но постараюсь без субъективности. Даже если принять этот аргумент, улучшение читаемости кода важнее, потому что когда мы пишем — мы в контексте, нам и так все понятно. А когда читаем чужой код — нужно разбираться какие данные откуда пришли. Если пропсы передаются в виде name={props.name}, мы сразу понимаем, что здесь prop drilling и name передается неизменным с верхнего уровня. Короче, структурирование данных важнее экономии на спичках.

Линтинг неиспользуемых пропсов Линтер плохо справляется с поиском неиспользуемых пропсов, если обращаться к ним через props.. На самом деле проблема только в динамическом чтении пропса вида props[propKey]. Если тем же линтером запретить такой код, то валидировать пропсы по их типу не представляет сложности.

Был еще странный аргумент, якобы мы все деструктурируем: ответы бэкенда, возвращаемые значения хуков и прочее. И нужно сохранять единый подход. Но хуки отдают объекты с ключами в своем пространстве имен. Та же data — очень популярное поле. Библиотечным хукам вообще плевать, что вы в своем проекте еще используете. Поэтому тема на самом деле шире и касается деструктуризации в целом, а не только пропсов.

Почему тогда это стало стандартом?

Так начали делать разработчики библиотек и всяких UI Kit. В их случае подход зачастую оправдан, потому что они редко активно оперируют данными и для них плюсы деструктуризации перевешивают. В продуктовом коде данных больше, и изменяется он чаще. Поэтому лучше предпочесть единый подход, который точно не вызовет проблем в будущем. Следом подтянулись авторы курсов, и в индустрию пришло много людей с уже сложившейся привычкой. Популярность подхода сделала популярным и соответствующее правило линтера, окончательно закрепив стандарт.

Какая мораль? Да никакой, пишите как хотите, мне похуй.