Comments 4
По моему, это не вежливо по отношению к читателям выкладывать такую муру. А если вы использовали еще и ИИ, то нужно было, как минимум, поправить все косяки.
Кстати, я думал это ИИ сгенерил:
const useBoolean = (initialValue = false) => {
const [value, setValue] = useState(initialValue);
const toggle = (value?: boolean) => setValue((prev) => value ?? !prev);
return [value, toggle];
};
А оказывается это находится в рекламируемой библиотеке.
Мне просто любопытно, и как? Удобно этим пользоваться?
В зависимости такой toggle не прокинешь, т.к. каждый раз новое значение, а значит эффекты и компоненты от него зависимые будут каждый раз по новой выполняться.
Как показал ваш пример, так называемый toggle необходимо оборачивать в безымянную функцию, что бы прокинуть как обработчик дом события.
Спасибо за развёрнутый отзыв
Насчёт реализации useBoolean - это действительно распространённый и хорошо зарекомендовавший себя паттерн, который используется во многих production-библиотеках, включая Chakra UI, Material-UI и Microsoft Fluent UI. Это не просто случайный код.
По поводу проблемы с референсами и перерендерами - при необходимости уже надо использовать useCallback для мемоизации toggle функции, что решает проблему нестабильных референсов.
Такой подход даёт хороший баланс между простотой использования и производительностью, что подтверждается его широким применением в enterprise-решениях.
По поиску, мне первой нашлась Chakra UI и все мои замечания там учтены. В Microsoft Fluent UI так же нет недостатков вашего решения. Дальше искать уже не нужно.
Поэтому нет, решение из вашей библиотеки какая-то мура. Я не хочу обидеть, но вы сами сослались на библиотеки, которые лишены всех недостатков вашего решения, которые делают его неюзабельным.
Иными словами, вы точно уверены, что у вас решение способное выдержать хоть какую-то критику и проверенное временем?
Вот по поводу 2-го пункта - что значит при необходимости?
Мне кажется, он должен быть обернут by-default в useCallback, чтобы пользователи вообще не думали, когда используют его в зависимостях. И тут речь не об оптимизаци, а об удобстве использования библиотеки.
Просто если вы называете свою библиотеку лучшей, с самым большим количеством хуков для реакта (и дока действительно выглядит очень презентабельно), качество тоже должно как минимум соответствовать, иначе оно реально никому не нужно и будет плохо влиять на проекты. Нет смысла иметь сотню хухов, если они реализованы некачественно.
Кастомные хуки в react