V
не понял тебя)
я больше мучное люблю
ну видимо нужно что бы бы каждый из айтемов, был memoизированным компонентом.
https://ru.reactjs.org/docs/react-api.html#reactmemo
Size: a a a
2021 January 08
P
export default React.memo(PatientTableRowContainer)
<List
ref={ref}
outerRef={outerRef}
style={{ width: "100%", ...style}}
height={window.innerHeight}
itemCount={patientsIds.length}
onScroll={onScroll}
itemSize={76}
width={"100%"}
>
{({ index, style }: { index: number, style: any }) => (
<PatientTableRowContainer key={patientsIds[index]}
{...{ patientID: patientsIds[index], index, style, canReadOnly, position, updateDatepickerPosition }}
/>
)
}
</List>
TG
так и есть
обернул
обернул
значит нарушаешь мемоизацию прокидывая объект/массив/стрелочную функцию
TG
export default React.memo(PatientTableRowContainer)
<List
ref={ref}
outerRef={outerRef}
style={{ width: "100%", ...style}}
height={window.innerHeight}
itemCount={patientsIds.length}
onScroll={onScroll}
itemSize={76}
width={"100%"}
>
{({ index, style }: { index: number, style: any }) => (
<PatientTableRowContainer key={patientsIds[index]}
{...{ patientID: patientsIds[index], index, style, canReadOnly, position, updateDatepickerPosition }}
/>
)
}
</List>
PatientTableRowContainer
должен быть мемоизированным компонентом
должен быть мемоизированным компонентом
TG
хотя они так вроде такой. просто код перекошенный
TG
export default React.memo(PatientTableRowContainer)
<List
ref={ref}
outerRef={outerRef}
style={{ width: "100%", ...style}}
height={window.innerHeight}
itemCount={patientsIds.length}
onScroll={onScroll}
itemSize={76}
width={"100%"}
>
{({ index, style }: { index: number, style: any }) => (
<PatientTableRowContainer key={patientsIds[index]}
{...{ patientID: patientsIds[index], index, style, canReadOnly, position, updateDatepickerPosition }}
/>
)
}
</List>
там style прокидывается. скорее всего это объект который был только что в рендере создан. он и ломает мемоизацию.
как я понимаю у тебя тут вартуализация списка, а значит перерндеревиваются не все, а только те что в радиусе видимости. если у тебя строки слишком тяжелые для ререндеринга, попробуй спустить оптимизацию ниже, для чилдренов компонента PatientTableRowContainer
как я понимаю у тебя тут вартуализация списка, а значит перерндеревиваются не все, а только те что в радиусе видимости. если у тебя строки слишком тяжелые для ререндеринга, попробуй спустить оптимизацию ниже, для чилдренов компонента PatientTableRowContainer
TG
я больше мучное люблю
ну извини. тоже не люблю когда от темы отходят. но я сам много раз сталкивался с подобным и каждый раз убеждался что логику лучше вытаскивать за пределы компонента. и запросы делать тоже за пределами.
P
там style прокидывается. скорее всего это объект который был только что в рендере создан. он и ломает мемоизацию.
как я понимаю у тебя тут вартуализация списка, а значит перерндеревиваются не все, а только те что в радиусе видимости. если у тебя строки слишком тяжелые для ререндеринга, попробуй спустить оптимизацию ниже, для чилдренов компонента PatientTableRowContainer
как я понимаю у тебя тут вартуализация списка, а значит перерндеревиваются не все, а только те что в радиусе видимости. если у тебя строки слишком тяжелые для ререндеринга, попробуй спустить оптимизацию ниже, для чилдренов компонента PatientTableRowContainer
очень странно(
сделал так
все равно ререндерит
сделал так
function customFunction(prevProps:any, nextProps:any) {
if(!R.equals(prevProps, nextProps)){
return true
}
return false
}
export default React.memo(PatientTableRowContainer, customFunction)все равно ререндерит
V
ну извини. тоже не люблю когда от темы отходят. но я сам много раз сталкивался с подобным и каждый раз убеждался что логику лучше вытаскивать за пределы компонента. и запросы делать тоже за пределами.
много однотипных действий, вся бизнес логика вытянута, просто не удобно/не приятно писать лишнию логику на реакте для таких кейсов
TG
очень странно(
сделал так
все равно ререндерит
сделал так
function customFunction(prevProps:any, nextProps:any) {
if(!R.equals(prevProps, nextProps)){
return true
}
return false
}
export default React.memo(PatientTableRowContainer, customFunction)все равно ререндерит
const mapProps = {};
Object
.keys(prevProps)
.forEach((key) =>
prevProps[key] !== nextProps[key]
? mapProps[key] = {prev: prevProps[key], next: nextProps[key]}
: null
)
вот такой код воткни в первую строку функции и законсоль mapProps что бы увидеть кто из пропсов изменяется и мешает мемоизацииTG
много однотипных действий, вся бизнес логика вытянута, просто не удобно/не приятно писать лишнию логику на реакте для таких кейсов
полностью согласен если речь идет о геморном стейтменеджере например таком как redux. а вот если взять effector код пишется в удовольствие и ты бы написал меньше кода с ним чем написано в твоем примере.
TG
очень странно(
сделал так
все равно ререндерит
сделал так
function customFunction(prevProps:any, nextProps:any) {
if(!R.equals(prevProps, nextProps)){
return true
}
return false
}
export default React.memo(PatientTableRowContainer, customFunction)все равно ререндерит
effector бы тебе сразу дал:
1. переключатель pending true/false
2. возможность мапить данные с сервера (изменять ответ с сервера под нужный формат для вьюшки)
3. расшаривать данные сразу на несколько компонентов если вдруг они там будут нужны
4. перегонять данные в разные сторы если вдруг данные потребовались за пределами определенной области
и многое другое
1. переключатель pending true/false
2. возможность мапить данные с сервера (изменять ответ с сервера под нужный формат для вьюшки)
3. расшаривать данные сразу на несколько компонентов если вдруг они там будут нужны
4. перегонять данные в разные сторы если вдруг данные потребовались за пределами определенной области
и многое другое
TG
я столько шишек набил с этими попытками уйти от стейтмедежера и от redux в сторону чего-то более упрощенного, без нужды написания лишнего кода. единственное оправданное решение которое нашел — effector
TG
типа такого, но еще хотелось бы добавить
ErrorBoundary. И лучше в композиции, где используется ViewSource сделать обертки (2 фото)вот например тут в коде вижу потенциальные уязвимые места. например service если измениться, у тебя пойдет запрос повторный. но если пойдет повторный запрос надпись 'loading...' не появиться потому что старые данные этому помешают. придется вводить флайг isLoding который нужно вручную включать/выключать при старте и завершении запроса.
effector из коробки это бы сделал
effector из коробки это бы сделал
V
вот например тут в коде вижу потенциальные уязвимые места. например service если измениться, у тебя пойдет запрос повторный. но если пойдет повторный запрос надпись 'loading...' не появиться потому что старые данные этому помешают. придется вводить флайг isLoding который нужно вручную включать/выключать при старте и завершении запроса.
effector из коробки это бы сделал
effector из коробки это бы сделал
представь себе отдельную модалку которая загрузила данные и показа и все. service - одна ручка и не более. реакт из коробки это делает, но через стейт =(
V
представь себе отдельную модалку которая загрузила данные и показа и все. service - одна ручка и не более. реакт из коробки это делает, но через стейт =(
хотя в офф доке написано, что можно (см ссылку выше). Но там кривой пример =((
TG
типа такого, но еще хотелось бы добавить
ErrorBoundary. И лучше в композиции, где используется ViewSource сделать обертки (2 фото)а еще, если ты покинул роут или каким-то еще способом размонтировал компонент, в момент когда запрос ушел, по завершению запроса будет setState и реакт кинет свою ошибку об этом.
V
а еще, если ты покинул роут или каким-то еще способом размонтировал компонент, в момент когда запрос ушел, по завершению запроса будет setState и реакт кинет свою ошибку об этом.
не уверен… ну можно вызывать метод отмены промиса, все в сервисе есть, спасибо 😉
TG
не уверен… ну можно вызывать метод отмены промиса, все в сервисе есть, спасибо 😉
да, можно. но все это действия дополнительные. я через все это не один раз прошел
V
да, можно. но все это действия дополнительные. я через все это не один раз прошел
что значит дополнительные?