Комментарии 3
«Банду четырёх» под суд! (закостенели, «закоболились»)
Да здравствует функциональщина!
Ура хукам! (С)
Наступил 19-й год.
Не уверен что это такая серьёзная проблема.
В реальном коде у вас не будет setTimeout
, у вас будет обращение к серверу, которому надо будет передать значение props.user
. Вот в этот момент и надо захватить это значение в замыкание, это, скорее всего, не приведёт к увеличению количества строк кода. Это было во-первых.
А во-вторых, вам, скорее всего, никогда не придётся выводить уведомление алертом, скорее всего вам понадобится изменить внутреннее состояние чтобы отобразить результаты. И эти результаты, скорее всего, как раз не будут содержать тех данных которые были переданы на сервер, они будут содержать ответ сервера! Возвращаясь к примеру из статьи, обработка той же кнопки follow будет выглядеть как-то так:
handleClick = async () => {
const {user} = this.props;
await fetch(…);
this.setState({ followed: true });
};
Вот о чём я говорю: { followed: true }
не содержит user
. Если в примере из статьи ошибка была в неправильном значении user
— то тут ошибка заключается в том, что если поменять текущего пользователя, то setState
в принципе не должна вызываться.
Для классовых компонентов эта проблема решается довольно просто:
handleClick = async () => {
const {user} = this.props;
await fetch(…);
if (user === this.props.user) {
this.setState({ followed: true });
}
};
А вот сколько костылей придётся дописать в функциональный компонент? Я пока что вижу вот такие:
const userRef = useRef(props.user);
useLayoutEffect(() => { userRef.current = props.user }, [props.user]);
const handleClick = async () => {
const {user} = props;
await fetch(…);
if (user === userRef.current) {
setFollowed(true);
}
};
Чем функциональные компоненты React отличаются от компонентов, основанных на классах?