Комментарии 10
Так а как "правильно"-то?
В данном случае, я намеренно не стал описывать "правильный" вариант, т.к. вариантов избежать подобной проблемы много, главное знать о ней. Самый простой - не использовать значение по умолчанию для ссылочных данных (т.е. иметь необходимые проверки, чтобы не допускать ошибок работы с undefined), можно подготавливать данные заранее на уровне работы с API различными способами, хранить значения по умолчанию в константах, тогда при проверках - это будет одна и та же ссылка, назначать такие значения по умолчанию в низкоуровневых компонентах, которые мемоизированы и не передают их ниже, мемоизировать сами эти значения. Зависит от походов на проекте.
const EmptyArray = [];
const ChildComponent = ({ images = EmptyArray, title }) => {обьявите вне компонента и использу`те в компоненте как дефолтное значение
Непонятно, как деструктуризация относится к описываемой проблеме. Без деструктуризации, при передаче props.images ?? [] было бы то же самое. И, наоборот, с деструктуризацией, но если можно передать, например, undefined в качестве images, то проблемы нет.
Смысл как раз в том, что это и есть одно и тоже, но на проектах часто не воспринимают добавление значения по умолчанию в момент деструктуризации, как создание новой переменной с присваиванием ссылки на новый пустой массив или объект. Цель была - обратить на это внимание тех, кто об этом ранее не задумывался.
Круто, спасибо
Особенно забавно, если проп с дефолтным объектным значением залетает в депенденсы useEffect, в котором меняется стейт - тут уже бесконечный ререндер. Помнится, столкнулись с таким на работе в прошлом году.
Согласен. Могут быть даже более "забавные" события, например, когда такая переменная залетает в массив зависимостей useCallback какой-нибудь невзрачной функции, которая прокидывается на несколько уровней вложенности, уже где-то там эта функция залетает в зависимости useEffect, где изменяет стейт на уровне, где применяется эта "злополучная" деструктуризация с установкой значения по умолчанию и потенциально может войти в бесконечный цикл выполнения, но случай, когда эта переменная прилетает пустая и применяется значение по умолчанию сам по себе довольно редкий кейс, то еще надо словить его, прежде чем хотя бы начать поиск источника проблемы. А если это проект, где не проводят тестирование на получение минимального объема данных сущности, то можно и не знать, что где-то на проде есть 1-2 страницы товара, например, где страница пользователя зависает без шансов на спасение. Я, честно говоря, конкретно с таким не сталкивался на практике, просто дофантазировал один из примеров, но, теоретически, это вполне реально)
Все так. Поэтому кажется норм решением стараться максимально писать логику прилаги вне Реакта (классы с MobX) и максимально избегать useEffect'ов
1) Не на каждом проекте нужен стейт менеджер, не на каждом проекте применяется именно MobX;
2) useEffect имеет свое прямое назначение, его, в принципе, не стоит применять для того, чего он не предназначен, т.к. он является инструментом работы с жизненным циклом функционального компонента React;
3) Если вернуться к теме материала, то пытаться исправить проблему из-за необдуманного использования значений по умолчанию в деструктуризации путем прикручивания стейт менеджера к проекту и только из-за этого начать задумываться зачем нужен useEffect, вместо того, чтобы задуматься над правильным использованием дефолтных значений, звучит странно.
Деструктуризация в React. Очевидно, но важно