re-frame 2018-09-12 | Slack Archive

@mikerod can I do a dispatch-sync from a subscription? again to avoid race conditions

@trailcapital well, indeed I'd like for the loading marker to be in the app-db, but for that, I somehow need to modify the app-db from the subscription to make sure the loading marker is there immediately for the sub

mccraigmccraig07:09:55

@alex340 the subscription is a function - it can fill in missing data (from the app-db) with the loading-marker - it doesn't have to modify the app-db

👍 8

Chris O’Donnell11:09:02

For example you could replace (get-in @app-db [:some :path]) from https://github.com/Day8/re-frame/blob/master/docs/Subscribing-To-External-Data.md#some-code with (get-in @app-db [:some :path] ::loading).

bmaddy14:09:12

This triggers when there's a change on the ::selected-scenario signal:

(re-frame/reg-sub
 ::chart-data
 :<- [::selected-scenario]
 (fn [_ _]

This triggers when there's a change on the ::scenario-ids signal:

(re-frame/reg-sub
 ::chart-data
 :<- [::selected-scenario]
 :<- [::scenario-ids]
 (fn [_ _]

But this doesn't trigger when there's a change on the ::selected-scenario or ::scenario-ids signals:

(re-frame/reg-sub
 ::chart-data
 :<- [::selected-scenario]
 :<- [::scenario-ids]
 (fn [_ _]

Is there some kind of trick to get a subscription to respond to the logical OR of signals?

curlyfry15:09:17

@bmaddy Could you share more of the code? The subscription should trigger when either signal changes (no tricks)

bmaddy15:09:35

Yeah, but there's not much to show. I should have mentioned, I'm using re-posh. I wonder if there could be an issue on that side of things.

(re-posh/reg-sub
 ::selected-scenario
 (fn [_ _]
   {:type :query
    :query '[:find ?id .
             :where [_ :ui/selected-scenario ?id]]}))

(re-posh/reg-sub
 ::scenario-ids
 (fn [_ _]
   {:type :query
    :query '[:find [?e ...]
             :where [?e :scenario/name]]}))

curlyfry15:09:00

I don't have much insight regarding re-posh, unfortunately. I'd maybe try to make a smaller example?

bmaddy15:09:30

Yeah, that's probably the next step. It's nice to get it confirmed that things should be working the way I expect. Thank you @curlyfry!

👍 4

Alex H16:09:19

@mccraigmccraig, @codonnell sure, but that's not equivalent. The data may be present in the app-db but stale, so it's not just a matter of indicating a loading marker when it's not there

Chris O’Donnell22:09:30

Could you explain a bit more how you're putting this together? In my mind, the flow would be a bit like: Initially, no data is loaded. When the subscription is derefed, an event is dispatched (async) which makes a remote request to fetch the necessary data. There is remote data in app-db, so the UI is in a loading state. (You could also explicitly initialize app-db to have the a loading value rather than make the data just be absent if you prefer.) The response data is received, which dispatches an event that populates app-db. This triggers a rerender and the UI is populated with fresh data. The data that was once fresh is now stale. (Why is it stale? Is there a time bound on how long data is fresh? Expired by mutation?) This transition from fresh to stale is captured by an event. If the stale-ness is due to time elapsed, you could :dispatch-later a :mark-data-stale event when the initial response is received. If it's due to mutation, you could dispatch this :mark-data-stale event when the mutation is done. The :mark-data-stale event dispatches a request to fetch fresh data and marks the data stale in app-db so the UI reflects this new reality. I hope that was clear, and please let me know if I've made misconceptions about your use case. Also, it's your app and you're free to write it as you choose, so feel free to disregard!

Alex H16:09:31

which otherwise would indeed be trivial in the subscription handler.

Alex H16:09:14

it really is about tracking the lifetime of an access, which means reliably being able to set some marker regardless of whether the reaction runs 1, 2 or more times before the data comes back, etc

Alex H16:09:31

I think I'll just see if dispatch-sync works from a subscription handler as intended, and, if so, that'll do.

2018-09-12

Channels