Clojurians Log v2

search channel for virtual scroll patterns

we have not provided example cursor integrations though, this will be missionary layer integration, you may need to wait for us to provide it

My application has the following notions: • a selection • a hovered item • a focus item, which is the hovered item if there is one, otherwise the selection.

In the code below, when hover-id switches back and forth between nil and :the-selected-id, the code prints focus-id = :the-selected-id each time.

I would expect the printing to happen only once.

Am I confused or have I perhaps found a bug?

it can happen, once the clock signal is dirty, despite truncating it to a boolean, a value must be produced and pulled through the dag because the entrypoint has sampled the root signal due to being dirty. We think we can optimize this out but it is not optimized today. Basically, once an upstream signal changes and is not the same value as before, there is going to be a propagation from that point to the entrypoint.

Ah, OK. Good to know.

this is one of the things i wanted to look at in your app, can you remove any clocks, also you can try to minimize computation downstream of mousemove (can some of that be done in css?)

Yeah, I’ll take a look at both of those at some point. FWIW, I think there’s a lot in my app that can be improved, and stuff that wouldn’t be there if I were to start from scratch. Several reasons: • My focus up to now has been to get something that works. • I’ve been learning. • My porting from v2 to v3 introduced some weird hacks that I probably didn’t think about hard enough.

@dustingetz (not sure what you meant by “clocks”…) I don’t have any e/System-time-secs or e/System-time-ms in my app, but in my nomis-timelines.event-handlers.postponed-events namespace I do have some stuff driven from the clock` function in the above snippet. Do you want me to get rid of that? (It’s postponing handling of mouse events and seems to make things faster. There’s almost certainly a better way of doing what I’m doing.)

@dustingetz Thanks for the detailed explanation. e/Tap-diffs shows what you said, and I confirm that using e/Reconcile makes things behave as I want — no more duplicate side effects. (And I’ve been able to remove a nasty hack from my code.)

thanks

@dustingetz In case you’re still planning on looking at my code… I’ve created a new branch no-clocks-and-minimize-mousemove-computation-v2 based off the changes I’ve made this morning. FWIW, I may try improving performance myself in the next few days, but I’m not sure what time I will have or, if I do, what I will actually work on.

it's on our backlog, don't wait for us

@dustingetz I’ve created a branch named no-clocks-and-minimize-mousemove-computation. There I’ve removed all “mousemove” event handlers and also the code for postponing events that I mentioned above (which is less relevant without the “mousemove” events). Let me know if there’s anything else / different you’d like me to do.

@nomiskatz I have misdiagnosed your problem. You are 100% correct that the println is expected to workskip. There will be a propagation but the propagation will be invisible because the jvm interop effects will be workskipped. What is happening here appears to be that the conditional when is rebooting its body each time the predicate is recomputed. So in diff terms you're getting shrink/grow (unmount/mount) instead of change. which is why you see the println each time. We agree that nobody wants the current observed behavior, we plan to fix this eventually. You can probably confirm this using e/Tap-diffs to see the lifecycle.

due to there still being a propagation it can still be a source of performance problems

workaround: wrap the when in e/Reconcile , let me know if that makes the println behave as expected

Thanks. I’m busy this evening. I’ll take a look tomorrow.