Clojurians Log v2
hyperfiddle
virtual scroll works well but one issue I found was that selecting content while scrolling doesn't work, because the content is dynamically replaced. Like if I want to render a log stream, or a long chat log (e.g. a slack room), being able to select / copy text is quite important. I suppose a solution could be to implement selection myself and keeping a separate state for it, but then you'd need to override default behaviour for styling / copying etc. Doesn't sound too hard but feels a bit hacky. Is it the right approach? Anyone done this before with the electric virtual scroll?
Maybe another solution could be to disable virtual scroll when selecting, somehow
can you give a screenshot or example to demonstrate the exact requirement? Slack and Grafana (log viewer) are both heavy virtual scroll apps, you cannot select the history of a channel for example, or 100k rows of logs
there must be bounds to what is rendered
I'm just playing around with v3, see if I can make a slack clone for learning, and I was wondering about using virtual scroll for rendering messages. Slack does seem to allow you to select history, I mean the rendering is a bit clunky but it does preserve selection and allow to select wider ranges than what is on the screen. The problem isn't really with electric as any virtual scrolling would have this problem, but I was wondering if anyone has done any work on this before. However I do wonder though if with electric we need to reach for virtual scrolling sooner compared with other rendering libs, in which case it might be a nice thing to have a pattern for
> However I do wonder though if with electric we need to reach for virtual scrolling sooner compared with other rendering libs yes this is definitely true today, it may remain true forever, our designs are targetting table rendering at dev-tool scale (git clients, IDEs, PKM software) which have typical collections in the 500-50,000 range of row count. We consider collections whose largest possible row count is <500 to be the edge case
with that said, Leo is investigating the virtual scroll pattern again (we want the vanilla e/for "natural" pattern to be fast), which is driving electric optimizations
I just played with Slack's selection of channel history, slack is also dynamically replacing the content underneath the selection
if you just want to widen the bounds of the virtual scroll to include rendering several additional pages of offscreen rows, that is mostly just a css problem, our current scroll widget doesn't support "over scrolling" out of the box because the boundary condition math is annoying and has to be perfect
it's https://github.com/hyperfiddle/electric/blob/757025f7627e302edd071a74ef43e48d83bf1c2c/src/hyperfiddle/electric_scroll0.cljc#L36-L58 we're talking about, someone just needs to "do the math"
the other thing slack does, which you can do, is use a virtual scroll strategy where you load more results when the user scrolls past a cutoff point (using the intersection-observer browser api). The idea is to progressively add more rows into the DOM as needed, and leave them there forever basically (until the user navigates away). This will result in acceptable performance with Electric because you're not loading/rendering the full history, load/render is still incremental. Up to whatever size limits of the actual DOM, which will start dropping frames when you exceed ~1k-2k elements in a single container. Since Electric is incremental, Electric does not care how many actual elements are rendered
there are working examples of this in electric v2, idk how well they will translate to electric v3 yet due to today needing to use the optimized IndexRing scroll strategy to get good real world performance
thanks for the detailed answer, super helpful. I'm not going to implement this just yet but if I get anything useful I'll share my approach or code 🙏 Also I'm interested to know what comes out of Leo's investigation.