Does anyone know how to get response-headers from http-xhrio?

@lachlan737 check the issues, I think that might be there as one

Yeah it is, was just wondering if anyone knew of any workarounds

There's an open issue for it https://github.com/Day8/re-frame/pull/413

I love it when I get errors like

react-with-addons.inc.js:14783 Uncaught TypeError: Cannot read property 'getHostNode' of null
    at Object.getHostNode (VM11514 react-with-addons.inc.js:14783)
    at ReactCompositeComponentWrapper.getHostNode (VM11514 react-with-addons.inc.js:6618)
    at Object.getHostNode (VM11514 react-with-addons.inc.js:14783)
    at Object.updateChildren (VM11514 react-with-addons.inc.js:4611)
    at ReactDOMComponent._reconcilerUpdateChildren (VM11514 react-with-addons.inc.js:12997)
    at ReactDOMComponent._updateChildren (VM11514 react-with-addons.inc.js:13101)
    at ReactDOMComponent.updateChildren (VM11514 react-with-addons.inc.js:13088)
    at ReactDOMComponent._updateDOMChildren (VM11514 react-with-addons.inc.js:8251)
    at ReactDOMComponent.updateComponent (VM11514 react-with-addons.inc.js:8069)
    at ReactDOMComponent.receiveComponent (VM11514 react-with-addons.inc.js:8027)

there is some extra information about the failure related to some internal re-frame stuff

but it doesn't help much either 😄

any debugging tip?

@vinai I solved it in my project, will get the code for you

@vinai https://github.com/JoelSanchez/ventas/blob/master/src/cljs/ventas/core.cljs#L29

Yes, it's a hack. Yes, it's awful. But it works, and it's reliable 😛

anyone using re-frame.test ?

I get quite wildly results if running with test-cljs or by doing cljs-test.run-tests from the repl

when using a signal-fn like here

(fn [query-vec dynamic-vec]
         [(subscribe [:a-sub])
          (subscribe [:b-sub])])

:<- [:a]
:<- [:b a]
(fn [[useless-a? b] _]
   

@jvuillermet ...where a would be the value of [:a]?

yes

I don't think that's possible using that form.

This might work?

(fn [query-vec dynamic-vec]
         [(subscribe [:b-sub @(subscribe [:a-sub])])])

Probably it's better to move it into a regular function and call it from the signal-fns

would be great to be able to visualize all the various dependencies between subs and events

since they are all data it should be possible, anyone tried that?

and any idea what this means re-frame: no :fx handler registered for: :http-xhrio ?

@andrea.crotti you are probably missing [day8.re-frame.http-fx] in :require

this will register the effect you need

https://github.com/Day8/re-frame-http-fx

uhm odd it's not there in master either though

and don't get that error there

that does fixes it though, weird

@jvuillermet @vinai in that sort of case, I ended up using reg-sub-raw since I thought it was less dirty than doing it in the signal fn (not sure if that is the appropriate use)

(rf/reg-sub-raw
 :do-it
 (fn [_ _]
   (r/reaction
    (let [a @(subscribe [:a-sub])
          b @(subscribe [:b-sub])]
      (do-it a b)))))

I don’t claim to be right, I just hesitated to put it in the signal fn

Maybe it is not an abuse of it. Perhaps some re-frame prophet on here can say? 😛

I’m looking at the impl for the signal-fn in reg-sub and I’m now a bit doubtful that it is safe to deref subscriptions in it

Which would mean - use reg-sub-raw

Basically, it’s this:

([db query-vec]
         (let [subscriptions (inputs-fn query-vec)
               reaction-id   (atom nil)
               reaction      (make-reaction
                               (fn []
                                 (trace/with-trace {:operation (first-in-vector query-vec)
                                                    :op-type   :sub/run
                                                    :tags      {:query-v    query-vec
                                                                :reaction   @reaction-id}}
                                                   (let [subscription (computation-fn (deref-input-signals subscriptions query-id) query-vec)]
                                                     (trace/merge-trace! {:tags {:value subscription}})
                                                     subscription))))]

           (reset! reaction-id (reagent-id reaction))
           reaction))

Both solutions seems complicated and hard to read to me. It feels that if one start going that road, you will end up with event more complex sub and signal-fn. At some point I guess it’s better to have a simple fn that do that by taking the whole db or some part

@jvuillermet taking the whole db may be fine. Can also lead to unnecessary recomputing though potentially

Also, I have done this pattern you describe due to other subscription doing significant “materialized view” work that I wanted to reuse

It’s the first case I encounter since a while where I needed that

Do you need it more frequently ?

However, I agree that it isn’t necessarily great and probably isn’t something you’d like to see a ton of

I’ve needed it quite a bit in one current case where I have a lot of configuration driving the UI in terms of which components are shown and their properties. I just end up having to use “id” sort of indexing into most subscriptions

so when most subscriptions need an “id” you have to pass the “id” along if you have subscriptions using other subscriptions

not sure it is a great thing, but I’ve had it come up a few time

well, I guess that is not the case you describe, we are talking about needing the return value of a subscription as an input to another. I’ve had that happen when my “id” isn’t explicitly passed in, but rather derived… Too abstract. This probably doesn’t make any sense to someone reading.

Let’s say it this way: Probably most of the time you shouldn’t need reg-sub-raw. However, it exists and is described fairly well @ https://github.com/Day8/re-frame/blob/master/docs/SubscriptionFlow.md So I’m guessing it comes up in practice for people. 😛

I think I get it. In my case, a blog can be edited or not based on user type, user-email and some blog props so the ::can-edit? sub take 4 params. When I want to use this sub, I often already have sub for user-type that would be nice to pass to the can-edit?

Yeah, I was sort of in a similar siutation when I decided to use reg-sub-raw

You could push the problem to the components/views like:

(let [user-type @(subs [:user-type])
     can-edit? @(subs [:can-edit? user-type <etc>])] <etc>)

I didn’t like that though, I wanted to be able to not keep pushing intermediary results to the view when the view didn’t need to know

So I ended up just making the :can-edit? style one look up its own user-type and that relied on another subscription and that’s where I’d end up at the reg-sub-raw usage

(using your example roughly)

yes, pretty sure it’s the same use case.

@jvuillermet one thing that I considered at one point is just share common logic via functions instead of have these more complex subscriptions rely on one another. However, the problem then becomes in always keeping things in sync. I think it starts to make the leaf subscription extra complicated are hard to manage

So you take all the impl from the subscription into a function for reuse that is independent of the subscription

but then all callers have to know the inputs to give this function. Which can mean you have to change more places when you have to alter how, in this case, the user type is determined.

Also, it means all that call this function will be recomputing the results independently. With subscriptions that use others as signals, results only computed once then shared