Fork me on GitHub
#re-frame
<
2020-12-22
>
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

p-himik08:12:21

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.

p-himik08:12:59

How does it affect you anyway?

Daniel Craig12:12:48

I’m using day8.re-frame/undo, 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 https://github.com/day8/re-frame-undo#the-result

p-himik12:12:37

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?

p-himik13:12:34

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

clyfe15:12:42

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

clyfe15:12:55

Or core team wants to do it themselves?

skykanin17:12:47

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":"pokedex.events", "name":"println","fqn":"pokedex.events/println", ...} . Am I registering the effect incorrectly? I just followed https://github.com/day8/re-frame/blob/master/docs/Effects.md re-frame docs on effects, but tweaked the effect slightly.

p-himik17:12:17

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

p-himik17:12:49

Switch ::print and ::print-effect in pokedex.events.

dpsutton17:12:09

also :println and ::println are different values

👍 3
🔥 2
metal 1
skykanin22:12:20

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.

p-himik22:12:01

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).

skykanin22:12:37

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

p-himik22:12:08

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

👍 1