I have a gridsheet based on https://github.com/hyperfiddle/electric/blob/master/src/contrib/gridsheet.cljc

It’s generally working well. I noticed that the e/for at https://github.com/hyperfiddle/electric/blob/45f7881df46f86e91a1730e893a05bed6cf4e728/src/contrib/gridsheet.cljc#L67 supplies key values in the range 0 to (dec page-size), rather than providing values that depend on the rows that are being displayed. I tried to fix this using a for-by with a key that is always the same for the same data row. But that causes my UI to continuously redraw, each time changing which is the top line. That’s happening because the value of scroll-top (returned by ui/scroll-state<) keeps changing. Any ideas on what the cause of this is? More detail… The video at https://drive.google.com/file/d/1rZwVG0TqnGPx17feSNmCtdIHR-sq5zTJ/view shows what happens. A cut-down version of my code is at https://github.com/simon-katz/nomis-electric-for-by-problem/blob/f750b83f59e66b82816d0c6a60696840ae0fcf7c/src/nomis_electric_demo/main.cljc#L105 That code could probably be cut down further — quite possibly I don’t need all the grid stuff to demonstrate the issue. If I don’t get any joy in response to this, I’ll try cutting that down.

off the cuff answer - electric v2 has a problem, which is why we work around it by stabilizing the row containers with fixed keys. The problem IIUC is that unmounting dom nodes, horrifyingly, pays round trip latency, due to a design flaw in v2. It should be fixed in v3, we're just about mature enough to start testing this use case

Ah, OK; thanks. I’ll move on to other things. 🙂

Did you have a reason for trying to change the strategy?

I thought it was the correct thing to do and that it might make things faster.

But it works well enough

So not a problem

ok