Fork me on GitHub
Daniel Craig03:12:34

How can I understand why my subscriptions are getting disposed? It’s driving me nuts and I’m sure that this question will help me understand laziness better


Subs (which are just Reagent reactions) are disposed of automatically when the last watch on them is removed. Usually it happens when the last view that was using a sub is unmounted.


How does it affect you anyway?

Daniel Craig12:12:48

I’m using, and my :undos? subscription is being disposed on the first undoable event that I dispatch

Daniel Craig12:12:22

But I don’t understand why, because I have an undo and a redo button on my app and I don’t think they’re getting unmounted... they do get disabled however. Here’s the tutorial that I’m following where it describes what the buttons are like


OK, but how does it affect you? How do you even know that duspose! (IIRC the function) was called on the reaction?

Daniel Craig13:12:35

Ok I figured out how to fix the behavior: could you explain what’s going on though? I had written my button like so: (defn undo-button [] (let [undos? @(subscribe [:undos?])] ;; only enable the button when there's undos (fn [] [:input {:type "button" :value "undo" :disabled (not undos?) :on-click #(dispatch [:undo])}]]))) Note that this deviates from the tutorial slightly, by moving the deref of my subscription into the let binding itself. With my button written this way, the subscription to :undos? gets disposed. When I do it the tutorial’s way instead, ie like so: (defn undo-button [] (let [undos? (subscribe [:undos?])] ;; only enable the button when there's undos (fn [] [:input {:type "button" :value "undo" :disabled (not @undos?) :on-click #(dispatch [:undo])}]]))) I get the correct behavior. Why does moving the @ result in this change of behavior?


The first example uses @ outside of the view function but, I think, within the Reagent's ratom context. It's expected. In short, don't use @ on subs/ratoms/reactions outside of view functions.

Daniel Craig13:12:46

Ok I’ll remember that - thanks for your help


What's the plan on re-frame instances there? Should I make a PR? @mikethompson


Or core team wants to do it themselves?


So I have this basic println effect which I'm trying to dispatch in my init function start here renders the root view, but for some reason I'm getting an error re: frame: no :event handler registered for: {"ns":"", "name":"println","fqn":"", ...} . Am I registering the effect incorrectly? I just followed re-frame docs on effects, but tweaked the effect slightly.


::println in your case is an effect. dispatch and dispatch-sync work on events.


Switch ::print and ::print-effect in


also :println and ::println are different values

👍 3
🔥 2
metal 1

So I have registered this effect and event which fetches some data from an API which I then conj onto a vector in my re-frame db which works fine, but it's quite slow for some reason and I'm not exactly sure why. First I thought it was an issue with the component that renders this data, but I made it basically empty to check and it seems that dispatching to ::fetch-pokemons is the bottleneck.


Your (http/get p-url) requests are done sequentially, not in parallel. Also, a small nitpick: you can replace (update db :list #(conj % pokemon)) with (update db :list conj pokemon).


I see, how would I make the requests in parallel?


Try using take! for example. There are innumerable approaches.

👍 1