Fork me on GitHub
#re-frame
<
2018-09-08
>
Hukka09:09:33

Hm. I'm a bit worried about how tightly some of the effect handlers are coupled to the db structure. Mostly when I need to send a REST query that is build using from ten different settings in the app. If components shouldn't know the structure, and use the subscriptions instead, why should the effect handler?

andrea.crotti10:09:26

I'm wondering what's a good way to structure a multi page SPA, where each page has its own view of the database

andrea.crotti10:09:59

I'd like to simply make sure each page has an independent part of the database, just by prefixing each submap with the namespaced keyword from the page itself

andrea.crotti10:09:27

I already wrote some helper functions that then allows to get-in assoc-in etc with that page-id, but would be even nicer to not having to that at all

andrea.crotti10:09:51

if somehow I could make sure that every time I get db as argument it's actually the sub-db, it would all magically work

andrea.crotti10:09:11

any suggestion about how to do that?

Hukka10:09:06

You don't want to make the sub-db a subscription, and tie the other subs to that?

andrea.crotti10:09:47

yes that could work, but then I have to pass it to all the subs?

andrea.crotti10:09:13

or maybe I could simply do a (def myreg-sub (partial rf/reg-sub my-db))

andrea.crotti10:09:44

would not work very well with reg-subs that already use a subscription function though

andrea.crotti10:09:55

I would have to compose the two things somehow

andrea.crotti11:09:18

I got something working in the meanwhile simply with helper functions that take the page-id

andrea.crotti11:09:31

I'm also undecided if I should make all the handlers use namespaced keywords or not

andrea.crotti13:09:40

mm this routing is more annoying than I thought

andrea.crotti13:09:59

I was thinking to use bidi for the backend API and Bidi + Accountant for the SPA

mikethompson22:09:48

@tomi.hukkalainen_slac 1. ultimately *something* has to be coupled to your data structure. That layer always has to exist. 2. BTW, you mean that event handlers get coupled (you said effect handlers), right? Just checking. event handlers will be constructing the REST query (via access to app-db. 3. Perhaps there is something about the design of your app-db which is problematic, if you are taking data from all over the place? Just me guessing. Might be nothing wrong.

mikethompson22:09:33

@andrea.crotti A. It is generally a good idea to use namespaced keywords for event and subscription ids. 1. For event handlers the path interceptor can be used to automatically "narrow" db 2. The equivalent for subscriptions might be to create one subscription to which you pass the panel-id (subscribe [:get-panel-data :my_panel-id-3])

mikethompson22:09:36

But the alternative you are looking for might be something like this:

(reg-sub      ;; some boilerplate so you can subscribe to all of `app-db`
     :db 
     (fn [db _]
        db))

(reg-sub 
    :panel-data 
   (fn [_ _] 
       [(subscribe [:db]) 
        (subscribe [:current-panel-id])])

   (fn [[db  current-panel-id] _] 
        (get-in db panel-id)))

mikethompson22:09:11

One warning: that subscription depends on the entire app-db (via the sibscription to :db ... so it is going to re-run every time app-db changes in any way.