Fork me on GitHub
#re-frame
<
2017-12-09
>
jeaye03:12:46

When testing a re-frame app, I'd like to intercept my login event to do a different event which creates a test user and logs in. I haven't found any existing docs in re-frame or re-frame-test for mocking or intercepting in this way (i.e. not re-frame interceptors). Any pointers?

madvas09:12:33

Guys, is there something wrong about using subscriptions inside subscriptions. Or is there performance difference between those 2 constructs?

(reg-sub
    :some-sub
    (fn [db [_ param]]
      (= 1 @(subscribe [:other-sub param]))))

(reg-sub
    :some-sub
    (fn [[_ param]]
      [(subscribe [:other-sub param])])
    (fn [[result]]
      (= 1 result)))

Hendrik Poernama11:12:08

@madvas why not use the other form of reg-sub using the :<-

Hendrik Poernama11:12:40

There's an example in reframe todomvc

madvas11:12:16

@poernahi how would you pass param there?

Hendrik Poernama11:12:53

You can pass a second fn to reg-sub to calculate the param

Hendrik Poernama11:12:31

(reg-sub :visible-todos ;; Signal Function ;; Tells us what inputs flow into this node. ;; Returns a vector of two input signals (in this case) (fn [query-v _] [(subscribe [:todos]) (subscribe [:showing])]) ;; Computation Function (fn [[todos showing] _] ;; that 1st parameter is a 2-vector of values (let [filter-fn (case showing :active (complement :done) :done :done :all identity)] (filter filter-fn todos))))

Hendrik Poernama11:12:55

The signal function calculate the subscription

p-himik11:12:58

@madvas I don't think that's anything wrong with it in terms of the behavior. If you look at the code for reg-sub, you'll see that input signals that Hendrik described are handled just like that - they're dereferenced and passed to the computation fn. But the explicit inclusion of subscriptions in the computation fn has a couple of problems. The first one, it's less composable. The second one, if you forget to dereference a subscription, there will be leak.

madvas12:12:39

okay understood, good points, thank you

notid15:12:08

Say you’d like to do an http post when someone clicks a button. Is it more idiomatic to a) execute the post in the on-click, and post and dispatch an event when the response is received, or b) dispatch a ‘clicked-button’ event, which has an event handler that triggers an effect handler that executes the post?

notid16:12:26

@p-himik Thanks. I suspected so. 🙂