This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (1)
- # announcements (7)
- # beginners (63)
- # cljs-dev (39)
- # clojure (78)
- # clojure-dev (40)
- # clojure-italy (4)
- # clojure-nl (22)
- # clojure-russia (5)
- # clojure-spec (5)
- # clojurescript (60)
- # cursive (8)
- # datomic (6)
- # emacs (1)
- # figwheel-main (53)
- # fulcro (19)
- # jobs-discuss (11)
- # mount (1)
- # off-topic (3)
- # om (1)
- # pedestal (9)
- # philosophy (1)
- # re-frame (19)
- # reagent (4)
- # reitit (5)
- # shadow-cljs (66)
- # tools-deps (64)
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
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
would not work very well with
reg-subs that already use a subscription function though
I got something working in the meanwhile simply with helper functions that take the
I'm also undecided if I should make all the handlers use namespaced keywords or not
I was thinking to use bidi for the backend API and Bidi + Accountant for the SPA
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
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.
A. It is generally a good idea to use namespaced keywords for event and subscription ids.
event handlers the
path interceptor can be used to automatically "narrow"
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)))