Как стать автором
Обновить

Комментарии 11

То есть получился компонент, который определяет позицию тултипа по его тексту и для этого добавляет бесполезный div в дерево?
Разве не удобнее это было сделать функцией getTooltipPositionByText(hint) и использовать ее во всех реализациях тултипов?

Всë в ваших руках. Можете использовать функцию. Можете придумать абсолютно иной способ позиционирования - детали реализации остаются на откуп читателю. Но статья всё же не о том как позиционировать компоненты и не о глубине DOM дерева. Главное, чтобы компонент не напоминал банку кильки, а разбирая конкретный юз кейс, вы видели именно его и ничего лишнего и никак не аффектили все остальные юз кейсы.

Здесь хуки как раз хорошо работают. Когда идет речь про переиспользуемость логики, а не представления. render-props здесь делает ровно то же самое.


Разный "синтаксис" для решения той же самой проблемы.

Опять некая статья, где тупо забивается на useCallback, что приведёт к постоянному перерендеру детей, даже когда этого не требуется. А данная проблема копаться как снежный ком. Хотя что говорить, когда даже в официальной документации данный момент игнорируется.

Про useCallback есть другие статьи. Невозможно каждую статью превращать в статью про useCallback.

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


Про useCallback, например, ситуация не всегда однозначная. Но если речь про переиспользуемые компоненты, то, наверное, всегда его надо пихать.

Вот только useCallback сам по себе ничего не оптимизирует. Чтобы что-то соптимизировать его нужно использовать вместе с memo (или чем-то другим, что требует стабильности ссылок). Поскольку здесь memo не используется, то и в useCallback нет никакого смысла.

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

Wat? useCallback возвращает стабильную ссылку на лямбду, меняя только в случае, если меняются зависимости. Зачем такой бред писать. Если же не верите, посмотрите исходники для начала.

Вот вам ссылочка, если лень искать. Если же хотите всю цепочку до useCallback, уж поищите сами.

https://github.com/facebook/react/blob/568dc3532e25b30eee5072de08503b1bbc4f065d/packages/react-reconciler/src/ReactFiberHooks.new.js#L1623

А бред пожалуйста не пишите более, а то я тут чуть под стол не упал.

Так эта стабильная ссылка на лямбду нужна только для передачи в пропсы memo-компонента. Иначе от неё толку никакого - обычный компонент всегда перерисовывается, даже если пропсы не поменялись.

В этом смысле memo, ну да, тут согласен. Что-то не совсем правильно понял вышенаписанное.

Так же ненужно забывать, что сам callback все еще создается на каждый рендер, да когда deps не изменились он возвращает ссылку на старую функцию, но на момент обхода дерева в памяти у нас 2 функции.

Если коротко, без явного использования memo, вы замедляете приложение.

Ну если уже холиварить, то использование memo/useCallback в компонентах которые практически являются листьями virtual dom, это явно преждевременная оптимизация. Вы подумайте, возможно core team реакта специально не описывает это в документации, возможно создание и сверка virtual dom это операция сопоставимая с сравнением deps в useCallback/memo или вы считаете что это масонский заговор, чтобы замедлить все приложения?)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий