Clojurians Log v2

That's so interesting to read, thanks for sharing this Mike. It sounds quite similar to what we use in my current project (and it's a plain React app, no cljs)

It's fascinating to see how much more clojurescrip-ish the React ecosystem has become, they copied some good ideas but unfortunately completely ignored the core concepts behind those ideas.

Are there any libraries or ideas for only performing effects (like backend calls) for components that are actually visible on the user’s screen? Maybe by utilizing js/IntersectionObserver? Maybe by not even loading the component using a library?

Has a plan distilled for re-frame instances? The idea is 5 years old at this point and there are a few forks. I'm happy to do some work if there i an agreed path.

FWIW it seems to me that such questions usually get much better traction in re-frame's GitHub issues. I'm pretty sure there's one (at least) that is about separate instances or at least touches on the idea.

Ty, forwarded here https://github.com/day8/re-frame/issues/137#issuecomment-754173161

Newbie question about performance: reading through the re-frame documentation on reusable-components, I found the implications section interesting WRT to how generic one can make a component. The first question I had (and perhaps this is covered elsewhere in the documentation?) was related to performance. I don’t have deep understanding about how re-frame determines if a component needs to be re-rendered but I would assume that the same subscription (something like :fetch/from-app-db) with distinct parameters (in this case, different path vectors) would result in distinct instances within the signal graph? I.e. a layer 2 or layer 3 node within the tree is distinct based on subscription-name+parameters, not just subscription-name? Is this a correct assumption and, if not, how does re-frame prevent multiple UI elements from re-rendering when they subscribe to the same subscription but with different parameters?

Follow up question, if my assumption above is correct, are there negative performance implications to having a generic layer 2 subscription which simply extracts data from the app-db based on a path that it is passed when it is subscribed to? This would seem quite useful in any effort to make a generic component library with reasonable defaults, as many/all of the components could use the same subscription to extract data (at least as a default).

@ajporter

https://day8.github.io/re-frame/reusable-components/#implications

@mafcocinco Indeed, subscriptions are identified by the entire subscription vector So (subscribe [:a 1]) is a different node in the Signal graph to (subscribe [:a 2]) In light of this information, have a read through http://day8.github.io/re-frame/subscriptions/#why-layer-2-extractors

Thanks @mikethompson !