Hi all. This may be a bit of a stretch, but I'm working Redux-Loops, a port of the Elm architecture to Javascript. If I'm remembering correctly, Re-frame uses a very similar architecture, so I'm hoping you guys help me with a question. I've got an event loop. I dispatch events. Event handlers (action reducers in my case) return side effects (as data) to be returned. Here's my conundrum: one of my side-effects is that I subscribe to some kind of stream (for sake of argument, lets say its a websocket connection that notifies me every time a chat message comes in). How do I handle this within the confines of this architecture? Can i dispatch actions directly from side-effecting code? I could see that becoming messy quickly if not tightly controlled.

@d4hines yes, this is how we do it. Why do you think this is a problem? How is it different from an action being dispatched from e.g. a UI event?

note that in re-frame event handlers are global though, which makes this pretty easy.

How can I use a subscription in a callback? I need to get check whether the search term matches. I don't want to trigger a rerender (performance), so I can't use a closure. When I use subscribe it causes a pretty terrible memory leak. 100mb or so for basic use.

Your callback should fire off an event. The event handler will get the app-db and you can just use get-in to look up the search term.

If for some reason that's not an option, you can save the ratom and call cljs.core/-remove-watch on it immediately after you get its value.

Beats my reaching into the app-db

I didn't realise that was all the cache cleanup did.

Actually, it seems that calling -remove-watch requires some Reagent internals know-how that I don't have, because you have to provide a key for it.

That's what I just hit, yeah.

Not sure if chasing this makes sense. Feels very internal.

Can you provide any more details about your use case?

You can always call the sub handler directly on app-db. Although that would be quite "dirty".

@manutter51 I'm using a react component, which takes a function predicate prop to determine whether to show an item. This allows me to implement an external search functionality. I don't want to use a closure because it is on a hot path, and running everything twice will tank performance. So I need to be able to statically define my function.

Aha, ok.

So here’s a quick thought just for brainstorming’s sake: You probably have a handler that updates the value of the search term in the db. Make your own atom someplace else and have the handler update that value also, so they stay in sync, and use your non-ratom atom in your callback.

Heh, that's pretty much the reframe appdb I guess.

“App-Db Lite™” 😄

it sucks that calling the subscription creates a memory leak

Basically you’re just caching out a specific piece of data, without the subscription overhead, as a performance optimization.

Also worth remembering that if you have to dig into Reagent internals to write code, it’s going to take similar in-depth knowledge to maintain it.

Doesn't seem like there's a official solution here though.

I wonder if calling reagent.core/dispose! would remove the leak

although re-frame might still hang onto the subscription since it does some caching

dispose! will remove the cache, along with all of the watchers. It will lead to other usages of the same sub not triggering any re-renders.

Don't do dispose! manually on subs.

I haven't used it, but it might be worth looking at https://github.com/den1k/re-frame-utils/blob/master/src/vimsical/re_frame/cofx/inject.cljc to see if something like that would solve your problem - it's recommended in the docs at https://github.com/day8/re-frame/blob/master/docs/FAQs/UseASubscriptionInAnEventHandler.md

Oh yeah, it has dispose-maybe. That may be useful.

this is very relevant to me since I’m using some subscriptions outside of reagent components (react hooks). I want to nip these memory leaks in the bud

But again, if you do that much stuff (more or less internal) around a simple sub, maybe it's worth it to just access app-db directly.

I haven't tried this yet, but what about binding reagent.core/**ratom-context** to nil when you dereference the sub? @dominicm

That sounds horrific. :)

why though? Obviously there is some global context being used in reframe and reagent

I'm not even sure what is evil anymore. :grinning_face_with_one_large_and_one_small_eye: I'm curious to at least try that in the morning. I've disconnected for now.

I think there’s a proposal at the heart of this for a public feature in re-frame that allows one to do this

I mean if that is evil, so is re-frame/reagent

Why? re-frame doesn't use *ratom-context*.

And Reagent has invented it.

I think it’s a question of public vs. private API @isak

They have this, it is just private: https://github.com/reagent-project/reagent/blob/2027a2d8881bae0567ecf9d4c90550b064a2ad0c/src/reagent/ratom.cljs#L36-L42

@p-himik You must know re-frame builds on reagent, so I don't see how that is relevant

Library A uses the internals of library A. Library B uses library A. Why do you think that both libraries are evil? The question is not about global context, but about internals.

If library A uses the internals of library A, that's a-OK. If library B uses the internals of library A (and is not maintained by the same people that maintain A, arguably), that's not good.

I'm not saying it would be a blessed perfect solution, but tradeoffs exist

That's for sure. And I was arguing about the downsides of the solution with *ratom-context*, nothing more.

Fair enough, I agree

hi, is there something similar to event bubbling in re-frame? I have a component that dispatch an event when clicked but I also need to fire another event from the parent of the component? is that possible?