There are rare scenarios when the same subscription handler can be called multiple times. Also, dispatching from a sub is 100% not needed. If you describe your problem, I'll describe how it can be solved without that.

^ I actually do this (dispatch in a sub) 🙂 the use-case is I wanted to have automatic fetching for objects that don't exist yet on clientside within a sub (subscribe to a path within an object and checks if the object exists if not there it does a remote request). I don't have any issues with it for my use-case but theirs code to ensure requests don't get spammed etc... It leads to a nice UX:

;; obj-path is a string that contains meta information about an object and has a protocol for descending and ascending the path.
(let [v @(re-frame/subscribe [:get-value obj-path])])
;; v is a value within the object if object does not exist does a remote request automatically and subscribes to the nested value (only retriggers if value from path changes).

Thanks @U2FRKM4TW. I’ll try to formulate my problem, it will take some thinking.

I wrote a post on Clojureverse about my struggles https://clojureverse.org/t/creating-async-subscriptions-in-re-frame/9052

It seems like you're doing things in subs that were meant to be done in events. There's a common question about "how do I know that I need that specific data, given that a specific view might or might not be mounted". In your case, the answer seems to be simple - you said it yourself that you always have all the views present, so no need to figure out what computations can be completely skipped. But in general case, the views are secondary in re-frame - it's not that you determine what you need based on what views you have but rather you determine what you show based on what you need. It can sometimes be hard to put things into that perspective though. And regarding not doing the same computations over and over again - reactions (which subscriptions are) are only one of the ways to achieve that. Given that events can't really use them, you can figure out what to compute and when manually - e.g. there's a on-changes interceptor built into re-frame. You can set it as a global interceptor that would emit relevant events that compute and cache the results in app-db when their inputs change. Then subscription would become simple getters of that cache.

Thanks @U2FRKM4TW. I do believe that my current solution, described first in the post, does what you are describing. The computations are done events, in chunks to avoid locking. And the computations are cached and the view subscribes to that cache (it is not however the only view - so when it unloads, I clear the cache and it gets recomputed when I return to the view). And it's all working fine.

But doing the computations in events and caching them, I end up needing to "determine what I need based on what views I have", right?

This is kind of annoying and I thought it would be cool if I could use subscription semantics to trigger the chunked computations. As if they were simple computations done in layer-3 subs (albeit not returning a result while computing). But writing my problem up, I think I realized that the gain from writing my own reg-sub and possibly subscribe to achieve this would probably not be huge. I will instead focus on refactoring my existing solution to fit my needs. Thank you

Your input is really appreciated so I am thankful for any additional thoughts!

Of course, my concern here is not IO but chunked computations to prevent the UI from locking. It seems to suffer from a similar problem to IO.

(Sorry for replying in the channel)

I don't think it breaks it, it just makes some things less convenient, that's all.

@U2FRKM4TW: Agreed. What solutions do you use for IO + re-frame? I've been inspired by kee-frame's controllers but modified it to be declarative.

Yeah, I'm usually using kee-frame for page-related data and simple effects for AJAX requests and WebSocket communication.