И
я ведь скинул полный пример)
и никто не знает, как этот полный пример будет использован. кто гарантирует, что вот этот провайдер не будет ререндериться родителем каждые 100мс? я не гарантирую. ты гарантируешь?
Size: a a a
2020 August 13
P
лучше сразу задавай вопрос. Так больше вероятности, что получишь нормальный ответ, а не сарказм-комменты
PI
не думаю что есть готовая таблетка для этого 🙂 На каждом проекте приходят к своей структуре
RD
короч:
вот такой компонент:
когда ОН, сам Comp перерендерится, будет передавать ребёнку каждый раз НОВЫЙ объект. а значит Child будет ререндериться каждый раз, когда ререндерится Comp. не важно, по какой причине и когда
а вот такой:
будет каждый раз передавать ОДИН И ТОТ же объект своему Child. и не важно, из-за чего и когда он ререндерится
вот такой компонент:
const Comp = () => <Child prop={{foo: 0}} />когда ОН, сам Comp перерендерится, будет передавать ребёнку каждый раз НОВЫЙ объект. а значит Child будет ререндериться каждый раз, когда ререндерится Comp. не важно, по какой причине и когда
а вот такой:
const Comp = () => {
const prop = useMemo(() => ({ foo: 0}), [])
return <Child prop={prop} />
}
будет каждый раз передавать ОДИН И ТОТ же объект своему Child. и не важно, из-за чего и когда он ререндерится
вроде разобрался, но спасибо за разъяснение)
а так записать можно?
const Comp = () => {
return useMemo( ()=> (<Child prop={prop} />) , prop)
}
а так записать можно?
const Comp = () => {
return useMemo( ()=> (<Child prop={prop} />) , prop)
}
ei
вроде разобрался, но спасибо за разъяснение)
а так записать можно?
const Comp = () => {
return useMemo( ()=> (<Child prop={prop} />) , prop)
}
а так записать можно?
const Comp = () => {
return useMemo( ()=> (<Child prop={prop} />) , prop)
}
Нет
ei
Для такого есть React.memo
PI
У нас есть common для хранения общих фрагментов, остальное кладем в месте вызова, чтобы было удобнее. Но в новом проекте стали делать отдельную папку где лежат чистые вызовы без логики вместе с схемами
RD
нет, потому что не сработает или сработает но не везде и не всегда?)
ei
нет, потому что не сработает или сработает но не везде и не всегда?)
Потому что есть React.memo
RD
вроде советуют использовать хуки в функциональных компонентах)
MK
вроде советуют использовать хуки в функциональных компонентах)
ты это сказал против React.memo?
RD
ты это сказал против React.memo?
не то чтобы против, я прост сказал то что прочитал в доке про хуки)
MK
не то чтобы против, я прост сказал то что прочитал в доке про хуки)
причем хуки к React.memo?
MK
не то чтобы против, я прост сказал то что прочитал в доке про хуки)
Для чего React.memo?
PI
=))) загонял
И
вроде советуют использовать хуки в функциональных компонентах)
советуют, да. используй. и документацию дочитай до конца. и ютуб посмотри и статьи почитай
memo и useMemo — две разных штуки для разных задач
memo и useMemo — две разных штуки для разных задач
RD
вот к примеру, почему не useMemo ?)
RD
советуют, да. используй. и документацию дочитай до конца. и ютуб посмотри и статьи почитай
memo и useMemo — две разных штуки для разных задач
memo и useMemo — две разных штуки для разных задач
ок)
PI
useMemo нет смысла использоваться для хранения компонентов, потому что это не оптимизирует рендер - компонент обернутый в useMemo все равно будет рендериться как ни крути.
а React.memo нужен чтобы реакт мог сравнивать измнение в props прокидываемых в компонент, чтобы если они изменились вызвать рендер вновь.
При этом React.memo никак не влияет на то будет ли рендериться компонент "изнутри" при изменении стейта внутри компонента
а React.memo нужен чтобы реакт мог сравнивать измнение в props прокидываемых в компонент, чтобы если они изменились вызвать рендер вновь.
При этом React.memo никак не влияет на то будет ли рендериться компонент "изнутри" при изменении стейта внутри компонента
ei
Потому что ЦЕЛИ РАЗНЫЕ