Clojurians Log v2

There's a longer answer at https://blog.phronemophobic.com/reusable-ui-components.html But the short answer is that :contextual data is implicitly passed down the whole tree. > How does this interact with the caching? As you might expect, putting lots of data that changes frequently in context is bad for caching. It's best for state that doesn't change frequently. Focus is the most common kind of contextual state, but I think it can make sense for other global state like drag&drop, modals, app-wide styling info, etc.

so if focus changes, does a component need an explicit reference to that focus to trigger a redraw? or everything redraws?

thanks for the link, I'll reread it

There's two steps that happens when state changes: 1. Creating a new view 2. Drawing the new view Right now, there's only a few optimizations to save repainting (mostly, because it hasn't been necessary). If the state changes, then it probably triggers both #1 and #2.

Basically, when the state changes, the view function gets called again and the repaint function gets called again.

There's quite a bit of caching done in the view function when using defui components and a little bit of caching done in the repaint function.

I think my question related to the interaction with the caching of the view function using defui components

I shouldn't have said redraw, you're right "view" vs "repaint" is the distinction

Yea, there's a cache that memoizes the building of components. Right now, there's not really any special way for a component to say which data it cares about (including contextual data). Part of the problem is that even if a component doesn't care about contextual state, a child component might.

I think there's some really cool optimizations that can be done, but I haven't spent much time on it because it hasn't been a bottleneck for me.

The neat thing is that these optimizations are generic and could be applied to any similar clojure program.

it's not a bottleneck for me, it's more trying to understand the motivations/constraints for the code

thanks for explaining

Yea, no problem.

I actually wish I could spend more time on these optimization problems because they're interesting, but there's a lot of other work that's probably more impactful.