re-frame

https://github.com/Day8/re-frame/blob/master/docs/README.md https://github.com/Day8/re-frame/blob/master/docs/External-Resources.md
lilactown 2021-03-29T00:29:53.040700Z

is there any particular reason that subscriptions couldn't be async?

lilactown 2021-03-29T00:30:06.041Z

other than the fact that reagent doesn't implement them like that

2021-03-29T06:41:48.049Z

@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/

lilactown 2021-03-29T15:34:35.051400Z

I mean addressing the "CPU problem" within subscriptions, instead of using events

lilactown 2021-03-29T15:42:23.051600Z

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

2021-03-30T21:20:03.059900Z

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?

lilactown 2021-03-30T21:23:54.060200Z

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

lilactown 2021-03-30T21:24:08.060400Z

but that wasn't what my question was about 🙂

2021-03-30T21:44:38.060600Z

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?

2021-03-30T21:46:18.060900Z

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?

lilactown 2021-03-30T21:46:43.061200Z

right.

lilactown 2021-03-30T21:48:22.061400Z

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

2021-03-30T21:48:22.061600Z

Hmm. I'll have to dwell on that. No clean way jumps out to me.

andre 2021-03-29T09:19:02.049800Z

re-frame stats soon in re-frisk

7👏
andre 2021-03-29T09:19:11.050300Z

this stats for our mobile app 😉

solf 2021-03-29T10:07:41.050400Z

Just for curiosity, classic web app, react-native, something else?

andre 2021-03-29T10:13:30.050700Z

react-native

andre 2021-03-29T10:13:41.050900Z

https://github.com/status-im/status-react

lilactown 2021-03-29T15:34:35.051400Z

I mean addressing the "CPU problem" within subscriptions, instead of using events

lilactown 2021-03-29T15:42:23.051600Z

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