Ребят подскажите какой вариант более правильный и почему? 1) const Comp

= ({id}) => {
const renderName = () => id % 2 ===0 ? 'even' : 'odd'
return <div>{renderName()}</div>
}

2) const renderName = (id) => id % 2 ===0 ? 'even' : 'odd'

const Comp = ({id}) => {
return <div>{renderName(id)}</div>
}

2 более правильный, потому что функция renderName будет создана только 1 раз в 1 случае же, функция будет пересоздаватся при каждом ререндере но на самом деле, это не сильно повлияет на перфоменс

const renderName = useMemo(() => id % 2 ? 'odd' : 'even', [id])

это плохой вариант, совершенно не нужная мемоизация

это не повлияет абсолютно

Если функиция сложная то повлияет же по логике

да какая бы она не была ее обьявление на каждом рендере это невероятно быстрая операция

А как же понятие что компонента должна быть чистой

По твоему это у нас грязный компонент?) const Comp = () => { const render = () => <div>text</div> return ( <div>{render()}</div> ) }

может ты имел ввиду stateless компоненты? но все равно это не причем в данном случае

ну человек переживал что функция будет создаваться каждый раз. Пусть не переживает

так может так ему и надо было писать, а не давать вредный совет?

так может со своей стороны напишешь? Учитель) А по поводу ненужной мемоизации - покажи мне метрику, где показано, насколько больше занимает этот расчет в сравнении с мемоизацией (сравнением значения и обращением к аккумулятору)

Мемоизация это не бесплатно, на хранение мемоизированого значения тратиться память и доп затраты для вычисления нужно ли нам вычислять значение заново или нет https://kentcdodds.com/blog/usememo-and-usecallback

собсно что я и написал) Только затраты эти, как правило, очень маленькие. Просто хранишь аккумулятор для предыдущих аргументов и значения. В даном конкретном случае - да, мемоизация - скорее защита от страхов)

Нет. Без реального измерения и понимания хотя бы порядков этих затрат - это всё бессмысленно. То, что в статье написано должно всех натолкнуть на мысль - научиться измерять, для своих проектов, в своем окружении... без этого такие статьи абсулютно бессмыссленны.

Я не хочу холиварить. Просто интересно стало. Есть какие-то данные о реальном импакте, по типу разноскейловых проектов, где кто-то хуярил мемоизацию для всего и для ничего? МОжет знаешь такие? я просто частенько сижу и думаю, вот стоит этот импакт того или нет. И в итоге все сводится очень часто к одной простой вещи. Если на проекте принято мемоизировать, то херячу, а если нет, то нет. Ну, если там будет редьюс в мапе в фильтре и т.д. и тп, то понятно, но вот в более простых кейсах, мне кажется, что самая большая экономия - это экономия времени разработчика, когда он не думает, а делает)

Не знаю... Мемоизация для всего это конечно перебор. Но по опыту, ререндер чего-то сложнее одной ф-ции должен быть медленнее любой мемоизации (имеется ввиду сам механизм мемоизации, не целиком useMemo). Для примера (цифры не реальные, а с отладчика, который в хроме на хосте, но в среднем отличия от девайса в продакшн режиме не на порядки, в дебаггере чуть быстрее, чем на телефоне в проде), акшн в redux + сложный большой редьюсер с immer'ом + куча селекторов ~5мс и ререндер компонентов с реконсайлингом (без селекторов) ~40мс, из которых ~18ms экран с FlatList, ~10ms экран с айтемом и остальное какая-то неизвестная машинерия с бесконечным шедулингом фиберов внутри реакта. На этих цифрах текст было невозможно редактировать в поле ввода - лезли баги рассинхронизации с нативом. Т.е. пыталось приехать больше одного onChange пока JS тред был занят. Я поменял в селекторах ф-цию сравнения с shallow на deep equal, и чуть memo добавил в нужных местах. Экран со списком вообще перестал ререндериться (потому что данные непосредственно нужные списку не менялись), а остальное... В общем в сухом остатке, по вне реактовским вещам так и осталось ~5ms, а ререндер остался только в текстовом поле и вместе с реконсайлингом и прочей машинерией стали занимать ~10ms. А главное, стало возможно работать после этого с приложением.