Как управлять React Data Grid через Redux

[faiwer]

По первой я тоже пытался такие вещи как scrollToIndex и разного другого рода эффекты (например всякие swap-анимации) держать в redux. Ничего кроме боли и агонии это не принесло. У вас в store в итоге лежат ненужные данные временного характера (можно это назвать эффектом). Скроллить ничего никуда не нужно уже, а данные лежат. Оттого и всякие костыли вроде scrollSignal-а. Плюс отдельно нужно обрабатывать логику когда начинать скроллить, когда не нужно сколлить.

ИМХО, намного проще живётся, когда в store лежат только те данные, которые отвечают на вопрос что нужно отрендерить. Любые анимации, скроллы, фокусы-блюры и другие вещи просто обрабатывать другими каналами обычным императивным образом. И не передавать номер строки через props, т.к. props имхо не для этого.

Вариантов решения тут много, все они со своими нюансами. Но даже если вы несмотря ни на что твёрдо убеждены что лучше решать такие вещи через redux + props, то лучше исходить из другой схемы:

• ну нужен никакой signal
• по окончанию действия scroll-а вызывать action который очищает поле scrollIndex в store посредством reducer-а

[AlexanderShutov]

Не понятно как использовать императивное управление. У нас скроллингом в гриде управляют вообще из других компонент, которые не в курсе, где этот грид находится. Может он даже не отрисован. Да, и не держать же ссылку на грид в Store.

Можно, конечно, пойти от кейсов. И убедить, что наши кейсы можно закрыть и без управления скроллингом. Например, один кейс — это скроллиться к выделению при смене выделения (но не всегда, есть исключения). Намного проще разрешить управление и все кейсы закрыть через явное управление)

По поводу scrollSignal. Перед публикацией эту статью прочли в моем отделе, и сказали «что за хак, нельзя эту проблему по другому было решить?». Да, воспринимается это хаком. Но с текущим решением у меня не было боли и агонии, нормально взлетело, но с популяризацией тяжело.

По поводу чистить scrollToIndex после скроллинга: можно попробовать. В теории между установкой scrollToIndex и сбросом, может еще кто-то вклинится с желанием установить свое значение scrollToIndex, и важное не сбросить его, случайно. Надо потестировать, может и нет проблем. А вообще, хорошая идея, попробую как-нибудь на другом функционале.

[faiwer]

Как вариант:

• иметь где-нибудь на верхнем уровне контекст предоставляющий API вида { scrollTo: fn, ...otherEffect }
• на нижних уровнях использовать его за счёт useContext и вызываеть в нужных callback-ах
• само API обрабатывать в <Grid/>-е, и пробрасывать наверх за счёт useImperativeAPI или вызвав setActiveGrid-метод из другого контекста, проброшенного из того же метода сверху.

Варианто действительно много. Все какие-то плохоие. Ни одного хорошего и идиоматического придумать не могу. Но в redux я бы постарался не хранить ничего временного вроде isFetching, isAnimating, scrollTo и пр…