Первое погружение в исходники хуков (задел на будущее)

Самая лучшая документация - это исходники. Поэтому в этом выпуске будет первое погружение в исходники React-а. Здесь мы познакомимся
с тем как реализован хук useCallback и заложим задел на будущее, чтобы было проще ссылаться на исходники

Поддержать Айти Синяка можно здесь:

00:00 Анонс темы
00:24 Структура репозитория
00:55 Поиск исходников хуков
03:15 Один хук - много функций. Dispatcher
05:16 mountCallback
06:18 updateCallback
07:54 Как сравниваются зависимости areHookInputsEqual
09:26 Выводы из изучения areHookInputsEqual
10:12 Изучаем mountWorkInProgressHook()
12:18 Изучение updateWorkInProgressHook() в вакууме не имеет смысла
13:04 Голос сообщества
13:30 Подписывайтесь!

-------------------------

Данный канал создан для инициирования бесед на различные темы IT сферы (социальные / технические), а также для тех кому короткая видео выжимка статьи, выступления на конференции или же просто личных мыслей, являются более удобным форматом

[xandmore]

8:23, вообще говоря, количество зависимостей не должно совпадать. Там бы стояло OR. А это означает, что количество итераций цикла определяется по наименьшему из массивов, что довольно странно, не находите? Да, мы увидим console.error о разном количестве аргументов шагом выше, конечно. Но, коли мы уж копаем до сути, то давайте на это обратим внимание :)
Пример, показанный в видео: [apartment, user, null] будет равен [apartment, user]
Спасибо большое за труды!

[taras.batura]

Хорошее видео. В тему про: "зачем программистам с опытом, если и сами могут глянуть", у меня мнение, что всего не глянешь. У тебя может из-за ежедневной рутины никогда не дойдет дело до того, как же там реализовано в исходнике, а вот такие видео помогают с идеями как можно свои знания прокачать.

[sergeysibara]

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

[ilnurryazhapov]

я вот не новичок но не ковырялся в исходниках, с вашей помощью все становится понятно

[Ramosok]

Ролики можно пересматривать бесконечно и каждый раз ты видишь что то новое) это просто шикарно!

[alexanderpodlesnyi]

Я любитель перерыть исходники и очень классно когда есть такие видосы, которые подтверждают мысли которые сделал сам исходя из кода.

[atlantatesla]

@it-sin9k, я немного запуталась)

linked list на 12:10 хранит в себе хуки всего приложения или только одного компонента?

Из этого видео я поняла, что один linked list это место хранения для всего приложения.
Но в каком-то другом вашем видео, была схема дерева и linked list располагался в одной node (кажется так)

[sjoyely]

Отлично видео! Ещё бы чего-то подобного...

[gkuorcb]

Привет, расскажи про компоненты высшего порядка

[olezhonnv]

Во накрутили. Что они там курят, в фейсбуке, что такую дичь наворачиваают?

Я колупаллся в исходниках реакта. Там у них дичь, в том смысле, что изначально придумали чепуху, потом подперли костылем то, что болит.

Потом очередным костылем подперли тот костыль, который решал предыдущую боль.

Но снабдили это неплохим интерфейсом, более-менее удобным для юзера, которому под капот лезнь не обязательно.

И каким-то чудом хайпанули!

То же думаю и про редакс. Но редакс - еще большая дичь, потому что интерфейс неудобный.

[vibius]

Интересная задумка, но не думаю, что новички что-то поймут, а программисты с опытом сами в состоянии покопаться в исходном коде. Имхо, если и ковырять исходный код, то было бы интереснее получить более целостное описание архитектуры, а не "здесь такая функция, она берётся из такого файла, а там ещё одна функция etc".

[max_cr_it]

Нимчего не помняв, почиму так все сложно там?

[dm.hol.]

Вообще необходимость открывать исходники, чтобы понять работу программы, - признак плохого дизайна API. Публичные методы должны давать полное подробное представление о своей работе, выдавать ожидаемые результаты.