Thanks for suggesting not to access db directly. I’m going to look into subscriptions in our app which do, because that’s indeed not good for performance.

What about subscriptions like this?

(reg-sub
 ::state
 (fn [db _]
   (get db :sub-state-of-widget)))

I guess this is not something you can avoid, you have to use the db somewhere to begin with

@borkdude subscriptions which draw data directly from app-db are known as "layer 2" subscriptions (layer 1 is app-db itself)

Follow both paths (First, and Then) at the top of: https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md

That’s great @mikethompson, thanks for this overview. It would be nice if there were also examples of what syntax to use, because I find sometimes stuff breaks by adding an extra function. The subscription destructuring changes

I guess a subscription with multiple functions are always level 3 and do not have access to the db

I’m using http-fx but don’t seem to be getting the correct http status code in my error handler. That is chrome dev tools shows the server is sending 401 and a json body but the error handler gets an object that says :status is 0. Am I misunderstanding something, or is there something else I need to do to get the status (and body), or ??

Oh, and its on a CORS request with an expired JWT so maybe the pre-flight OPTIONS is messing something up.

Look in the console, there might be an error there. 0 usually means something was wrong with the request I think

Failed CORS could do that

Hmmm I have to wait till my token expires to test it again 😄 Its against aws api gateway. The request works when the token is fresh but when expired IIRC the network panel looked like it was getting a valid OPTIONS but the actual post was returning a 403 and an expired token message but my call back was getting status 0. Thanks for your help. I’ll keep an expired token around for testing and let you know what I figure out.

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/status explains 0 status