@pandeiro yeah that's a common trip up for people

https://github.com/Day8/re-frame-http-fx#warning-this-effect-handler-depends-entirely-on-the-api-of-cljs-ajax-make-sure-you-are-familiar-with-the-api-for-cljs-ajax-and-especially-with-ajax-call-before-proceeding

@gregg Thanks! Unfortunately i want label html label to be shown as well.

Hey all, if anyone here is familiar with .dirs-local.el I'd appreciate either your thoughts on this ticket, or your help via a PR 🙂 https://github.com/Day8/re-frame-template/issues/49

when using the :<- dynamic subscription shorthand there's no access to app-db, right?

(reg-sub
  :test-dynamic
  :<- [:another-subscription]
  (fn [dynamic-subscription-vec evt]
    "Where's app-db?"
    true))

@joshkh i suppose it's intentional so you could define subscriptions strictly in terms of other subscriptions so re-frame could efficiently narrow down list of subscriptions to check after every handler update

i was thinking along the same line, thanks @nidu

Hi, I'm coming up to speed with re-frame. I was curious about making multiple changes to app-db inside a -db or -fx handler. The page I'm reading makes it seem like this is a bad idea and multiple changes should be handled by multiple events. Am I interpreting this correctly?

I'm curious if anyone has made any attempts to automatically graph re-frame subscription relationships?

I have a fairly convoluted component I'm working on and spent the better part of last night diagramming it out in graphviz

it proved useful if tedious to compile, and I was thinking I could write a macro to help with that part

@dealy If you mean updating multiple keys in the app-db then I think there's nothing wrong with that. I would do something like this:

(reg-event-db
  :update-foo-and-bar
  (fn [db _]
    (-> db
        (assoc :foo 1)
        (assoc :bar 2))))

yes, that is how I was doing it

Haven't heard of such project but I'd like to see a nice graph of the whole reactive side of re-frame too~ 👍

https://github.com/Day8/re-frame/blob/master/docs/Subscribing-To-External-Data.md#some-code Shouldn’t there be at least % in the :on-success handler there?

not necessarily

you could just want to dispatch something without the return value

but often, yes, you would use the % to include the return value in the dispatch

yeah, but this code suggests that the handler should put an async query result somewhere into db

good point

Also, my first thought before reading this article would be to write some kind of coeffect, say (query conn "select * from items") that would expose query result to, say :load-items event handler and make it so that the handler just moves the data from the coeffect to db. It’s somewhat the other way round than presented here.

I see that they mention this here: https://github.com/Day8/re-frame/blob/master/docs/Subscribing-To-External-Data.md#the-alternative-approach Do you maybe know of any good examples of the alternative approach?

Are you guys thinking of cutting a new release for the cljs 1.9.660 compiler warnings due to reagent? I see it's been addressed upstream

@mattly https://clojurians.slack.com/archives/C073DKH9P/p1498668950274812 this is part of https://github.com/Day8/re-frame-trace. It's still pretty green, but it dynamically discovers the relationships in your code as they run, showing you the current subscription tree

oh neat