I'm trying to use re-frame-test, but having throuble in a small/simple test. When I run this

(deftest login
  (rf-test/run-test-async
    (let [username "souenzzo"
          password "123456"
          authed? (rf/subscribe [:auth/authed?])]
      (rf/dispatch-sync [::db/init db])
      (fact "I'm not in!" @authed? => false)
      (rf/dispatch [:app/login username password])
      (rf-test/wait-for [:app.login/set-token]
                        (fact "I'm in!" @authed? => true)))))

I've seen that error recently too, but not with ref-rame test

Are you running this on the JVM?

yep @danielcompton

What happens with lein test?

I think it might be an IntelliJ error?

Sanity checking myself here because of discussion with a coworker. is doing a (re-frame/dispatch ) inside a (re-frame/reg-sub ) a terrible idea or not?

my response was that subscriptions should be free of side effects, but apparently it's an established pattern in this code base to use this for side-loading missing resources

@plexus i guess as long as the subscription function is being called deterministically w.r.t. your use case it doesn't sound insane but distateful and prone to later problems

that said, it is actually written somewhere that sub functions should be free of side effects?

and couldn't you dispatch the event from the same place the subscription is being invoked from and be a bit less surprising?

it was my impression that subscriptions being pure functions is a key part of the architecture. You're right we could do it in the component.

well i am sure that is the intention and it sounds pretty icky

if this was something that was somehow impossible any other way then... perhaps... but I struggle to see how it could be better than firing the event from same site as the subscription

i'd maybe write a helper reg-sub-with-side-load or something like that

@plexus https://github.com/vimsical/re-frame-utils might help you out...

There's a track effect which will automatically dispatch events when subscriptions update

@plexus @sandbags why is doing it in the component better or preferred?

I would say it's two-fold. (1) it's more intentional, (2) you don't have a lot of control or expectation about if & when the subscription code may be run

our use case is we want to perform an effect (evaluate code via a web worker) when a view is scrolled into the view but also cache that result so we only evaluate it once.

and we want to reevaluate when any arguments change

re-frame subscriptions cache does this for us

perhaps i misunderstand, but subscriptions IIRC handle caching automatically

yes they do

and again IIRC the cache is argument sensitive

so the only real question is about when & where the event is fired?

to me it seems more intensional and in the spirit of re-frame to expose it at the point of use, rather than burying it in the subscription where it is depending on the current behaviour of the subscription framework code

and do the caching ourselves?

?

are you talking about caching whether the event has been fired for some set of arguments?

surely that can be derived from the db state, i.e. if you've already side-loaded a particular resource you can ignore the event

yeah, then we end up dispatching a lot of events that never do anything

that felt wrong to me

i suspect that's pretty cheap depending on the actual value of "a lot" but you'd need to profile it yourself to be sure

look if it were me I would do 'the right' way and see how it worked in practice. the attach-to-sub thing feels like a hack. I'd fall back to that if in practice the other way didn't work out

ymmv of course

alright, thanks

(re-frame/register-handler
  :state/msgs
  (fn [db [_ msgs]]
    (debugf "state/msgs handler: %s" msgs)
    ; (update db :pers #(conj % (vector (js.Date.))))
    (assoc db :wsmsg msgs))
    ))

Hello, I would like to run 2 function from a re-frame handler.. but in every case, just run one.. what I did wrong?

(first the logger and second the real db action)

(I commented in this code the first function)

@sb The statement (update db :pers #(conj % (vector (js.Date.)))) does not change db as db is immutable. That line returns a new representation of the map

Which you promptly discard and use the old immutable db in the second line

What you want to do is use the result of the first statement as the input to the second statement

e.g.

Ok thanks the info

(assoc (update db :pers #(conj % (vector (js.Date.)))) :wsmsg msgs)

however that’s super hard to read so a thread-first macro is your friend

e.g.

(-> db
    (update :pers #(conj % (vector (js.Date.))))
    (assoc :wsmsg msgs))

that is work now, I changed the order of the functions.

thanks the advice!

thanks @kasuko !!

No problem

If I want to implement drag-n-drop, what is the general strategy? Are there some examples of this? Or even libraries?

I basically want a re-ordereable stack of divs

but i want to do it idiomatically, so i prefer not to directly touch the dom in some dirty way 🙂

and probably let the mouse coords be injected as cofx

as well as the position of the ‘drop area’ to see ifthere is any overlap so that it can highlight or whatever

any thoughts/pointers are welcome