Clojurians Log v2
re-frame
is there any particular reason that subscriptions couldn't be async?
other than the fact that reagent doesn't implement them like that
@lilactown
Philosophically, subscriptions should reactively deliver what is in app-db. The hiccup produced by renderers are just a materialised view of what's in app-db, yadda, yadda, yadda.
Now the data in app-db can be delivered by async processes, and then the subscriptions will reactively carry that data through, yadda, yadda. So, subscriptions are indirectly async to the extent that they are reacting to processes delivering data into app-db in an async way. Kinda. Sorta. But ... you know all that, so you are asking a different question, I think.
Are you are wondering about subscriptions which react to ratoms other than app-db, where there are processes which deliver data into those ratomgs, and not app-db?
Maybe you are wondering about this kind of approach (a very early document containing a lot of warnings :-)):
http://day8.github.io/re-frame/Subscribing-To-External-Data/
I mean addressing the "CPU problem" within subscriptions, instead of using events
it's always felt clunky if I have (what turns out to be) a very expensive subscription, and must move it out of a subscription and into a chain of events
when I've needed to source external data into re-frame, I've avoided putting it in appdb: see https://widdindustries.com/clojurescript-firebase-simple/ . is there an argument for doing so?
in lieu of the machinery that firebase provides out of the box, I think re-frame's app-db is most useful when used as a place to store external data
but that wasn't what my question was about 🙂
By "The CPU problem", I'm assuming you a referring to the process of having more than 16ms of computation to do. So you do some computation, and then you want to hand back control to the browser, and then pick up where you left off and continuing on for a while longer, and then hand back control, etc, multiple rounds?
And so you are wondering about doing that kind of iterative process (round after round) in a subscription handler? Rather than via an event handler?
right.
or even just splitting up the computation of the subscription handlers. if I change some data in the app-db, and it triggers 5 subs that each take 4ms, I've overrun my budget
Hmm. I'll have to dwell on that. No clean way jumps out to me.
re-frame stats soon in re-frisk
this stats for our mobile app 😉
Just for curiosity, classic web app, react-native, something else?
react-native