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?

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

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

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

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

any suggestion about how to do that?

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

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

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

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

I would have to compose the two things somehow

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

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

mm this routing is more annoying than I thought

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

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

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

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

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.