Fork me on GitHub
#re-frame
<
2020-01-31
>
kirill.salykin08:01:50

Hi, morning I think I am not the first one asking this question, (sorry my google kung fu failed to find any) is it ok to have a :dispatch in the :subs? why or why not?

pwojnowski08:01:05

Just out of curiosity... Why would you like to do that? What do you want to achieve?

kirill.salykin08:01:23

Sorry, code is not mine (doing review) figuring out is this a good pattern to use or not

(rf/reg-sub-raw
 ::customers
 (fn [db _]
   (rf/dispatch [::fetch-customers])
   (r/reaction (:customers @db))))
As far as I understand it triggers the fetch when subscribe

pwojnowski09:01:39

Well, my understanding is that subs react on changes in app-db (e.g. data loaded from the server) and are used in views to display the data. The data are normally loaded in response to some events and put into app-db. So the flow, IMHO, should be something like: 1. An event is produced (dispatched) somewhere (for instance by a click). 2. Event handler receives it and declares what should be done (load customers from the server). 3. Event-fx calls the server and produces an event that the data have been retrieved. 4. Success-event handler inserts the data into app-db. 5. Sub is notified about the change in app-db. 6. View is rendered on sub change.

pwojnowski09:01:10

So, the dispatch of the initial event happends in a copletely different place.

kirill.salykin09:01:41

I fully agree with your points

kirill.salykin09:01:27

just was currious maybe there are other things to be aware of, like memory leaks.

pwojnowski09:01:51

Maybe there are such things, but unfortunately, I'm not aware of them. :man-shrugging:

kirill.salykin09:01:45

This document will soon be retired, and you probably shouldn't be reading it. It may mislead you. 🙂

p-himik09:01:40

Oh, right - that's a somewhat recent change, I haven't seen it before, thanks.

p-himik09:01:58

I definitely don't agree with some points. But that's a complicated topic. re-frame's approach to state management is not without its drawbacks.

p-himik09:01:07

Consider a component that cares about a set of keys in the DB. This set comes from outside, and the component has to switch its representation depending on the values and the presence of those keys. Also, for each key the component requires some external data. The data cannot be loaded all in advance - it has to be loaded after any changes to those keys in that set. re-frame approach here is to create a bunch of events that change the keys in the required ways and to make those events also load the external data. The issue here is that it creates unneeded coupling. With just a few such components and keys, it becomes unbearable.

kirill.salykin09:01:42

not sure the keys thing has something to do with dispatch in the reg-sub-raw

p-himik09:01:12

In my example, the data query would depend on the keys and their values.

p-himik09:01:08

:x is changed in the DB -> load data for X, display page X of the component. :y is changed in the DB -> load data for Y, display page Y of the component. And so on.

p-himik09:01:52

It is possible to implement such components with idiomatic re-frame code and without introducing the unneeded coupling. But it becomes unbearable in a different way - you'd have to either pass everything that's required for the data queries to the events or store everything internal in the DB.

p-himik09:01:00

Ah, right, there's yet another approach - via re-frame-async-flow-fx. But it gets even more messier and cumbersome.

kirill.salykin09:01:01

dont think it is related to the question, but thanks for your input

p-himik09:01:38

It's tangentially related. :) I have explained my view on that note about retiring that document, and that document is definitely relevant.

isak16:01:51

Why not just use component-did-mount?

isak16:01:37

ah, strange