В React компонент перерендеривантся всегда если обновляется его родитель в не зависимости от того поменялись ли передаваемые ему пропсы или нет. Чтобы убрать лишнее рендеры нужно явно использовать memo или PureComponent.
Ваш код напомнил замечательный пример из какого-то доклада где TS позволяет таки выстрелить себе в ногу - валидный с точки зрения типом код сломает runtime.
Предлагаю выносить загромождающие код обработчики в объект класса вместе с зависимостями. Разве так не лучше?
Довольно странно видеть, как автор попробовав путь функциональных хуков вернулся, пусть и не явно, к использованию привычного набора методов объеденных в класс, получив все те недостатки, что были в классовых React компонентах и проигнорировав все те преимущества, что несут функциональные React хуки.
Предлагаю свой вариант приведенного выше синтетического примера в попытке продемонстрировать идею функциональных хуков. Первое, что нам понадобиться это вынести общий код в небольшие функции хелперы, достаточно простые и переиспользуемые:
1. Хук позволяющий вызвать коллбэк с заданным интервалом:
Еще раз обращаю внимание что у нас появилось 4 небольших хука с вполне понятной и законченной логикой, которые можно переиспользовать в любых компонентах и протестировать независимо друг от друга. Например, мы можем их использовать для рефакторинга приведенного в статье кода:
А что делать если достался проблемный легаси, который либо сложно либо невозможно покрыть тестами, поскольку писался он без соблюдения модульности, изолируемости и тестируемости компонентов системы?
Код ниже вполне ок работает без ошибок (в браузере по крайней мере):
const a = { b: 1 }
a.b = 2
Все верно, однако присваивание a = {} выдаст ошибку, что вполне очевидно, на мой взгляд. С объектами const гарантирует, что ссылка будет всегда указывать на заданный при объявении объект. Для объектов с неизменяемыми полями следует смотреть в сторору Object.freeze().
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
В React компонент перерендеривантся всегда если обновляется его родитель в не зависимости от того поменялись ли передаваемые ему пропсы или нет. Чтобы убрать лишнее рендеры нужно явно использовать memo или PureComponent.
Ваш код напомнил замечательный пример из какого-то доклада где TS позволяет таки выстрелить себе в ногу - валидный с точки зрения типом код сломает runtime.
Довольно странно видеть, как автор попробовав путь функциональных хуков вернулся, пусть и не явно, к использованию привычного набора методов объеденных в класс, получив все те недостатки, что были в классовых React компонентах и проигнорировав все те преимущества, что несут функциональные React хуки.
Предлагаю свой вариант приведенного выше синтетического примера в попытке продемонстрировать идею функциональных хуков. Первое, что нам понадобиться это вынести общий код в небольшие функции хелперы, достаточно простые и переиспользуемые:
1. Хук позволяющий вызвать коллбэк с заданным интервалом:
2. Хук позволяющий хранить некое значение на изменение которого можно подписаться:
3. Хук создающий обработчик для input элементов:
4. Хук создающий обработчик изменяющий значение на заданную величину:
Еще раз обращаю внимание что у нас появилось 4 небольших хука с вполне понятной и законченной логикой, которые можно переиспользовать в любых компонентах и протестировать независимо друг от друга. Например, мы можем их использовать для рефакторинга приведенного в статье кода:
Ну и в заключении, никто не говорит, что код на хуках лучше или хуже классов, выбирайте то что вам по душе и используйте с умом.
А что делать если достался проблемный легаси, который либо сложно либо невозможно покрыть тестами, поскольку писался он без соблюдения модульности, изолируемости и тестируемости компонентов системы?
Все верно, однако присваивание a = {} выдаст ошибку, что вполне очевидно, на мой взгляд. С объектами const гарантирует, что ссылка будет всегда указывать на заданный при объявении объект. Для объектов с неизменяемыми полями следует смотреть в сторору Object.freeze().