This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-13
Channels
- # announcements (6)
- # babashka (96)
- # beginners (159)
- # calva (16)
- # cider (17)
- # clj-kondo (4)
- # cljdoc (6)
- # cljfx (3)
- # clojure (202)
- # clojure-europe (21)
- # clojure-italy (2)
- # clojure-nl (36)
- # clojure-spec (6)
- # clojure-uk (16)
- # clojurescript (29)
- # conjure (25)
- # cursive (29)
- # data-science (12)
- # datalog (18)
- # datomic (58)
- # depstar (73)
- # duct (16)
- # emacs (65)
- # events (3)
- # fulcro (8)
- # honeysql (12)
- # jackdaw (6)
- # jobs (7)
- # jobs-discuss (3)
- # kaocha (50)
- # leiningen (8)
- # lsp (14)
- # malli (83)
- # meander (34)
- # off-topic (2)
- # polylith (4)
- # proletarian (7)
- # re-frame (8)
- # releases (9)
- # remote-jobs (3)
- # shadow-cljs (101)
- # sql (1)
- # tools-deps (48)
- # vim (7)
- # xtdb (13)
- # yada (14)
Hello there, I’m staring at a re-frame codebase at the moment that has dozens and dozens of injected-subscriptions in various reg-event-fx
Would you consider this an anti-pattern? I can understand where the desire comes from: there’s already code massaging the app-db to deliver data in a specific form.
Repeating that in the event handler seems like a lot of code-duplication. The flip-side would be to add a battery of named fns that can also act as layer-3 subs and refer to those in an event handler.
How are you dealing with this?
> to add a battery of named fns that can also act as layer-3 subs and refer to those in an event handler Exactly this.
Not entirely related, but my app-db is split into two parts - domain data and app's state.
The latter I query with a bunch of get-in
calls, usually wrapped in appropriately named functions.
The former I query with a single function, because the data is normalized.
I've also found the domain/ui split useful.
Esp for domain data have been looking into datascript, datahike and the like for flat storage and datalog querying of data. So far its obvious that posh/re-posh should be avoided as the query analyzer is significantly slower than the queries themselves (e.g. see https://github.com/athensresearch/athens/pull/665). Otherwise havn't made many conclusions so far. I'm considering if async cofx/interceptor chains should be supported for datahike-like use-cases but I'm not sure thats even a sane idea yet.