Подход интересный :)
Но я бы делать так не стал по нескольким причинам:
— при вызове handleClick будет изменяться state компонента, а это значит будет происходить полный рендер компонента, только для того чтобы обнулить timeout звучит дорого
— читабельность тоже как по мне не особо улучшилась, теперь в этом коде стало гораздо React чем JavaScript. Чтобы обнулить timeout мы вызываем не clearTimeout, а вызываем какую-то функцию абстракцию, на которую где-то в другом месте подписан useEffect, который в return возвращает функцию, которая обнулит timeout. По мне так, этот вариант и есть спагетти когда одно за другое зацепленно, как макарошки вокруг вилки
Интересный вариант использования) я о таком даже не думал)
а что включает ваша viewModel?
onClick обработчики включает? как значение там обновляете, если к примеру redux-store обновился и прочее) если выложите черновик где-нибудь, было бы круто!
С другой стороны, автор утверждает что нет никакой заметной разницы при «лишней» мемоизации
Я утверждал, что в конкретной ситуации пользователь не заметит разницы, но всегда найдется 10 других ситуаций, в которых хочется выжать из инструмента максимум. И мы должны знать как это сделать.
Да и по поводу читабельности, догружать систему дополнительными хуками, это ухудшает читабельность кода.
Они мне с самого начала показались порочной практикой. Они слишком много делают «магически».
Тут дело субъективное, я, например, с первого дня втянулся в новые возможности хуков. Наконец решил проблемы с переиспользованием логики, наконец перестал биндить каждый метод во имя правильного контекста. Да и сама идея использования бесконечного замыкания для хуков максимально соответствует духу JavaScript, а не попытки имитировать классы из других языков, что вечно раздражало.
А после нажатия на кнопку, вы не меняете вообще ничего в футере? например, состояния isLoading для кнопки, пока выполняется обработка onClick, или же состояние активной выбранной кнопки? Я к тому, чтобы интерфейс был отзывчивым, чаще всего все равно нужно после взаимодействия с кнопкой рендериться, чтобы отреагировать визуально на нажатие.
Оригинальное решение, впервые такое вижу) но как мы знаем редкие ситуации требуют экстравагантных решений) Интересно было бы посмотреть, реальную задачу, которую решили таким образом
Мои аплодисменты, ответ шикарен! Жаль у меня недостаточно кармы чтобы плюсануть.
Единственное я бы добавил один нюанс по поводу следующих строк:
Однако в чём заключается render этой <button/>? На самом деле в removeEventListener и addEventListener. Всё. Это практически нулевые затраты.
Я изучал исходники хуков (про это тоже хочу написать статью и снять видео), и там useCallback включает в себя логику думаю не дешевле чем добавлять и удалять EventListener. Строится очердь хуков, запускает метод render hooks. Так же нужно сравнивать deps которые прислал через Object.is и другие сложности, так что думаю addEventListener будет если не дешевле, то как минимум столько же стоить
Здесь функция onClick явно зависит от props. Чтобы React не делал лишнего рендера нужно чтобы ссылка на функцию onClick не менялась, при передачи одного и того же значения. А добиться этого как раз можно используя useCallback.
Из этих слов не очень понятно, как ссылка на функцию, каждый раз новая, которую мы передаем в button onClick приводит к «лишнему рендеру»
Все верно, мы просто разрабатывая на классах привыкли к определенного рода магии реакта. Что есть какой то метод componentDidUpdate, что есть какой то setState, и по факту это все абстракции в виде черных ящиков. И когда ты привык к этой идее, тут тебе дали еще один ящик, который по синтаксису обманчив. И ты думаешь по привычке, ну реакт там сам все решит.
Видел как тяжело идёт понимание, что если мы создали функцию… ты мы её создали. И да и она и dependencies создаются вообще всегда с нуля, просто при удачном раскладе отбрасывается результат.
Я точно соглашусь с со словами про собеседование, точно такая же картина и у меня, поэтому и создал это видео и написал статью.
Есть лишь один момент в котором я сомневаюсь. Все мы с класами работали еще на php или Java или на других языках, когда JS использовался очень минимально в проекте. А что если нам с классами все просто и понятно именно потому что у истории программирования много лет опыта в этой стезе, уже куча статей как решать любую проблему с классами и мы уже все это давно прошли. Возможно и с хуками решится эта проблема, когда пройдет через хабр 10-ки статей и это уже будет все просто и очевидно
Ответа я конечно не знаю, но вопрос который я задаю себе: не являются ли все эти проблемы с хуками просто борьба с чем то новым? Не являемся ли мы просто консерваторами, потому что мы привыкли писать на классах?
Чтобы это понять, планирую общаться с новыми поколениями, как они вообще воспринимают хуки
Вызывает сомнение другое — что рендеринг компонента-функции с кучей не JSX кода, быстрее функции render в классе в уже созданном компоненте)
Тут непонятно что быстрее, но судя по их доке создание инстанса перевешивает все остальные операции, а инстансы создаются часто, вы перешли на новую страницу, создай тьму компонентов, нажали на кнопки, одни удали, другие создай. И еще одна проблема у инстанса, они не могут его оптимизировать, а если им отдать функцию у которой есть if который в текущем энвароменте возвращается всегда true, то условно, они могут выкинуть часть кода.
Я бы с удовольствием посмотрел на читабельные реализации основных хуков.
Через примерно 2-3 видео, планирую сделать экспериментальное видео, в котором покажу как это работает из нутри. Там под каждым хуком несколько функций, условно есть useCallbackMount, useCallbackUpdate и другие
Я конечно не знаю точного ответа, но если предполагать, то возможно у них есть условно лаба и есть фидбек о том сколько сложностей вызывает освоение функций и сколько сложностей после этого вызывает освоение классов и работа с контекстом. А сейчас на хуках осваивать контекст в принципе не особо то и важно, да и сами классы нет смысла изучать. Поэтому можно сделать вывод, чтобы теперь начать писать на React, вам нужно меньше знать о js чем раньше.
Для тестирования хуков есть вроде как уже готовые решения, на подобии этого
React core разработчики говорили по их статистике разработчикам новичкам гораздо проще понять хуки, чем осознать как работает class в js, как работать внутри него с this и когда надо функцию биндить, а когда лучше создать метод как arrow function. Для людей, кто это уже освоил давно, кажется очень простой задачей работать с классами, но видимо это не так.
Я не считаю вашу идеологию плохой, но мне ближе писать в первую очередь на JS чем на React, т.к. это лишь библиотека для отображения :)
Но я бы делать так не стал по нескольким причинам:
— при вызове handleClick будет изменяться state компонента, а это значит будет происходить полный рендер компонента, только для того чтобы обнулить timeout звучит дорого
— читабельность тоже как по мне не особо улучшилась, теперь в этом коде стало гораздо React чем JavaScript. Чтобы обнулить timeout мы вызываем не clearTimeout, а вызываем какую-то функцию абстракцию, на которую где-то в другом месте подписан useEffect, который в return возвращает функцию, которая обнулит timeout. По мне так, этот вариант и есть спагетти когда одно за другое зацепленно, как макарошки вокруг вилки
а что включает ваша viewModel?
onClick обработчики включает? как значение там обновляете, если к примеру redux-store обновился и прочее) если выложите черновик где-нибудь, было бы круто!
Я утверждал, что в конкретной ситуации пользователь не заметит разницы, но всегда найдется 10 других ситуаций, в которых хочется выжать из инструмента максимум. И мы должны знать как это сделать.
Да и по поводу читабельности, догружать систему дополнительными хуками, это ухудшает читабельность кода.
Тут дело субъективное, я, например, с первого дня втянулся в новые возможности хуков. Наконец решил проблемы с переиспользованием логики, наконец перестал биндить каждый метод во имя правильного контекста. Да и сама идея использования бесконечного замыкания для хуков максимально соответствует духу JavaScript, а не попытки имитировать классы из других языков, что вечно раздражало.
Поэтому сколько людей, столько и мнений :)
Единственное я бы добавил один нюанс по поводу следующих строк:
Я изучал исходники хуков (про это тоже хочу написать статью и снять видео), и там useCallback включает в себя логику думаю не дешевле чем добавлять и удалять EventListener. Строится очердь хуков, запускает метод render hooks. Так же нужно сравнивать deps которые прислал через Object.is и другие сложности, так что думаю addEventListener будет если не дешевле, то как минимум столько же стоить
Из этих слов не очень понятно, как ссылка на функцию, каждый раз новая, которую мы передаем в button onClick приводит к «лишнему рендеру»
Что вы подразумеваете под этой фрахой? приведите пример
Я точно соглашусь с со словами про собеседование, точно такая же картина и у меня, поэтому и создал это видео и написал статью.
Есть лишь один момент в котором я сомневаюсь. Все мы с класами работали еще на php или Java или на других языках, когда JS использовался очень минимально в проекте. А что если нам с классами все просто и понятно именно потому что у истории программирования много лет опыта в этой стезе, уже куча статей как решать любую проблему с классами и мы уже все это давно прошли. Возможно и с хуками решится эта проблема, когда пройдет через хабр 10-ки статей и это уже будет все просто и очевидно
Ответа я конечно не знаю, но вопрос который я задаю себе: не являются ли все эти проблемы с хуками просто борьба с чем то новым? Не являемся ли мы просто консерваторами, потому что мы привыкли писать на классах?
Чтобы это понять, планирую общаться с новыми поколениями, как они вообще воспринимают хуки
Тут непонятно что быстрее, но судя по их доке создание инстанса перевешивает все остальные операции, а инстансы создаются часто, вы перешли на новую страницу, создай тьму компонентов, нажали на кнопки, одни удали, другие создай. И еще одна проблема у инстанса, они не могут его оптимизировать, а если им отдать функцию у которой есть if который в текущем энвароменте возвращается всегда true, то условно, они могут выкинуть часть кода.
Через примерно 2-3 видео, планирую сделать экспериментальное видео, в котором покажу как это работает из нутри. Там под каждым хуком несколько функций, условно есть useCallbackMount, useCallbackUpdate и другие
Спасибо!
React core разработчики говорили по их статистике разработчикам новичкам гораздо проще понять хуки, чем осознать как работает class в js, как работать внутри него с this и когда надо функцию биндить, а когда лучше создать метод как arrow function. Для людей, кто это уже освоил давно, кажется очень простой задачей работать с классами, но видимо это не так.