Fork me on GitHub

Looking for an opinion. I want to build a simple widget which I can make several instances of. According to what I've researched on the net, I've seen a couple ways to deal with this - the first is to assign an id to each widget, passing this id to the re-frame event/subscription functions and storing the widget's data in an atom stored in an associative structure keyed on the id; the second is to simply build a reagent component backed with its own reagent atom to store state locally. Which of these is preferred, or is there a better way to store local state in these simple components?

Drew Verlee05:02:45

Store state as locally as you can but no more, aggressively abstract your core state such that it stays focused and use functions to derive more information from it.

Drew Verlee05:02:27

But really the distinction in re-frame doesn't matter that much as you can subscribe to a a more "local" part of the global state.


Also, if it really is a simple widget, then making it a reagent component would be easiest. In which case, perhaps look to re-com for inspiration:


I should look at the code for re-com. I'm using some of these components already. There are just some that I want to build that aren't in that set.

Richard Bowen15:02:25

Hey, how does one handle changing hover styling with material-ui via re-frame?


Answered in #clojurescript, not #re-frame specific at all.

TJ Campanella22:02:00

Is anyone using this with server side rendering ?


tl;dr: there are reason for why re-frame is rather tough to use with SSR. Personally, I would try to avoid that.


What are the consequences of using subscription inside an event?

  (fn [db [_ id]]
    (let [some-data @(subscribe [::data id])]


The subscription will be placed in the subscription cache, but it may never be evicted from that cache. It is a memory leak. I have a PR open in re-frame related to this

👍 1

There are ways to work around it. Subscribe in a view and pass the value from the subscription to the event when you dispatch. You can also extract into a function that accepts a db value and whatever necessary argument and call it from the subscription handler and the event. This becomes challenging when the subscription is a layer-3 subscription. The event essentially has to build up the signal graph and thread all the arguments around. Subscribe handles all of that automatically


Somewhat recently, I've learned that it's actually worse than it seems, potentially much worse: • It can easily lead to unnecessary computations if your subscription depends upon other subscriptions • It has been claimed but there was no proof that it can lead to out-of-order computations in the case of diamond-shaped dependency graphs Of course, it's not that big of a deal if you stick to pure subscription handlers. But if you do, then you also should stick to pure event handlers. ;)