Fork me on GitHub

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 ( 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.

✔️ 4

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])]
     [:h3 "items:"]
      (map item-list-entry @items)]]))
the generated hiccup won't contain any ratoms so reagent won't know to update the component when the underlying data changes. the proper thing would be to subscribe in the parent component and generate [item-list @items] -- correct?


@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):

 (for [item @items]
  [item-list-entry item])]
so that if item-list-entry dereferences any atoms, they will also re-render correctly


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. :)

☝️ 8

@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:


 (for [item-id @item-ids]
  [item-list-entry item-id])]
(There will be less component re-rendering this way)


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)

👍 4

If you do, put it on the docs


The problem is that it's *impossible* to find via any search engine. You have to either open every single documentation page and just incessantly Ctrl-F it to hell, or just download Reagent sources and search through there (which was exactly what I did myself back when I was still getting started with it).