Comments 4
Вот тогда закройте эту статью нафиг. И статьи этого автора вообще не открывайте.
Потому что технический уровень его очень низок. Возможно он вообще в серьезный продакшн в жизни не писал, а только туториалы и клепает.
Он генерирует статьи с бешеной скоростью и каждая строится по следующей структуре:
— ссылки на примеры из документации статьи и исходники с которыми сложно спорить.
— собственные выводы и мысли которые почти всегда чушь и часто выдают непонимание проблематики. Это позволяет заподозрить отсутствие сколько-нибудь серьезного опыта разработки.
Критических комментариев к таким статьям обычно мало, потому что чтобы опровергнуть выводы надо свою статью писать, а лень.
Конкретно в этой статье например автор подменяет причину (дизайн решение положиться на порядок хуков) и следствие (мелкая неважная деталь реализации — хуки реализованы через связный список).
Если кому интересна причина такого дизайн решения — вот обсуждение рфс по хукам в котором детально обсуждаются трейдофы и разрабы отвечают за принятые решения.
Оно большое, не чтение на 5 минут, но есть саммари в комменте Себа
+1, что не довод в статье то "WAT?".
Подведем итоги. Для управления хуками React использует связный список.
А могли и обычный массив использовать. Ничего бы снаружи не поменялось.
Каждый (текущий) хук содержит указатель на следующий хук или null (в свойстве «next»).
Ну это потому что там список. Однако, опять же, как правильно написал комментатор выше — это малосущественная деталь.
Вот почему важно соблюдать порядок вызова хуков при каждом рендеринге.
Да нет же. Не путайте причину и следствие. Просто представьте как бы вы смогли реализовать вызов хуков без этих вот ограничений, не выдавая им уникальные ID-ки? Условно если бы автор React сделали так:
const [state, setState] = useState('uniqId1', 0);
const onClick = useCallback('uniqId2', ...);
useEffect('uniqId3', ...);
// etcто никаких ограничений на порядок и количество вызовов хуков бы не было. Так как можно было бы однозначно соотнести конкретный вызов с его сохранёнными данными. Но было бы сложнее их переиспользовать (а в этом во многом и состоит задумка). Ну и код был бы более замусорен.
Касательно "условного рендеринга компонент". Come on, при условном render-е целых компонент React их монтирует и демонтирует. Включая работу по DOM-у. Это вот прямо несопоставимые по затратам операции. Зачем вы это связали с порядков вызова хуков — мне не понять. Особенно вот это:
Тем не менее, это показывает, что, при желании, добиться условного использования хуков все-таки можно
Хех. Подсказка — вы можете в runtime случайным образом создавать новые компоненты, которые случайным образом будут вызывать любые хуки в любом порядке. Главное чтобы не больше 1-го рендера :)
P.S. автору: если делать нечего и скучно — посмотрите как работает определение древа вызова хуков (включая custom-ые, конечно) в React Dev Tools. Много интересного откроете :)
На мой взгляд, в данной статье имеет место "ненужное копание в коде". Желтенькие цитаты поясняют суть намного понятнее, чем дальнейший разбор. Это всё равно что ходить по пустыне Наска, разглядывая камешки, вместо того чтобы взять самолет и увидеть картину в целом.
Заметка о том, как работают хуки в React