When an event needs data from the db are there any negatives of accessing the db directly in the even vs using a dedicated subscriber?

Only that if your subscriptions rely on others it gets complicated

Not sure what the question is about. Do you mean using a subscription value to create an event vector so that it can be used in the corresponding event handler to avoid making it go look into the DB?

and just to clear up, do you mean subscribe to the sub inside the event or have it passed in to the event dispatch?

I mean subscribe to the sub or inject it into the coeffects of the event.

Using a sub in an event handler is possible (https://github.com/den1k/re-frame-utils/blob/master/src/vimsical/re_frame/cofx/inject.cljc). But if the sub is not used anywhere else right at that moment then you don't gain any performance at all, you lose it.

I just wanted to make sure that there were no dangers in accessing the db directly in the event since most of the time the way to get values from the db is through subscribers. Sounds like it's actually the preferred approach to access the db directly.

Event handlers receive DB as one of the co-effects. They are designed for you to look into the DB directly.

Subs are mainly for views and for other subs.

Thanks for the clarification and break down! Much appreciated.

this won't do "the right thing", correct?

(defn item-list
  []
  (let [items (rf/subscribe [:items])]
    [:div
     [:h3 "items:"]
     [:ul
      (map item-list-entry @items)]]))

@mbarillier that item-list will update correctly however, passing in the items as props might be better if you intend to re-use this component to display multiple states

you also probably want something more like (assuming item-list-entry is also a Reagent component):

[:ul
 (for [item @items]
  [item-list-entry item])]

I’m assuming you’re using this as [item-list]. if you call it like a function, (item-list) then you’re right it might not re-render correctly

And don't forget about key. :)

@lilactown the intent is to have the ul update as the items change (single instance of the component). assuming [item-list-entry ITEM] generates [:li "..."] then reagent won't know that [item-list] would have to be refreshed when the data under the sub changes -- or is there some magic I'm missing? the atom used in the for/`map` expression won't be seen by reagent in the generated list hiccup.

there is magic you are missing, yes

it’s not about the generated hiccup. the atom only needs to be dereferenced when the function is executed

it’s not the ul that is updated; the whole function will be executed when the atom changes

then reagent will convert the hiccup to React Elements, and React will diff between what was last rendered and the new element tree, and update the ul in the DOM

I usually do this:

[:ul
 (for [item-id @item-ids]
  [item-list-entry item-id])]

Quick question: what "[:<>" means?

It creates a fragment.

(note to self: don't ever add anything like that to own libraries that others might use)

If you do, put it on the docs