This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-15
Channels
- # announcements (2)
- # aws (52)
- # beginners (326)
- # cider (24)
- # clara (7)
- # clj-kondo (14)
- # cljs-dev (175)
- # clojure (183)
- # clojure-ecuador (2)
- # clojure-europe (4)
- # clojure-italy (11)
- # clojure-nl (1)
- # clojure-norway (1)
- # clojure-spec (5)
- # clojure-sweden (5)
- # clojure-uk (103)
- # clojurescript (49)
- # cursive (29)
- # data-science (9)
- # datascript (17)
- # datomic (23)
- # emacs (6)
- # events (4)
- # fulcro (19)
- # graalvm (8)
- # graphql (2)
- # hoplon (36)
- # jobs (1)
- # jobs-discuss (92)
- # juxt (3)
- # luminus (10)
- # off-topic (4)
- # pedestal (8)
- # planck (1)
- # re-frame (59)
- # reagent (1)
- # reitit (22)
- # rewrite-clj (8)
- # ring-swagger (3)
- # shadow-cljs (101)
- # spacemacs (15)
- # tools-deps (36)
- # vim (68)
In my app, we have most server side fetches defined as follows
(defmethod api-read :person/by-id [env _ {:keys [person-id]}]
(let [person (person-by-id! person-id)]
person))
I’d like to set them up using defquery-entity
, but for some reason Fulcro can’t find those when I do that
@tony.kay This seems to be in line with this idea, https://github.com/fulcrologic/fulcro/blob/86e68249e62b5ca091fbe68c107f5e8270adc85d/docs/_posts/2017-12-26-remotes-as-an-abstraction.md#L93 ?
The server API is still the same idea as before: you plug in a parser. If you’re using the predefined parser, then it uses predefined server-side multimethods
Any recommendations on how to plug in the new defquery-entity
style methods? I tried (defmulti api-entity server/defquery-entity`) and that doesn’t seem to work.
i've been reading through the docs and fulcro seems pretty sweet. is there a description/discussion somewhere of why hiccup syntax wasn't used?
@njj http://book.fulcrologic.com/#_the_server_multimethods_for_mutations and read the defquery-root macros
@nbtheduke probably at least 3 discussions of this in the history of this channel 😜
lol I'll do some digging, then!
The short answer:
- Historical (inherited from Om Next)
- Functional: Fulcro’s DOM calls work as macros when possible (making them resolve to raw js at compile time), but can act as true functions as well, so they can be functionally composed.
- Use Sablono if you want. It should work fine.
Oh, while I’m at it: The macros generate faster code if you pass props as a literal map (e.g. (dom/div {} (dom/p ,,,))
will be about 3x faster at runtime than (dom/div (dom/p ...)
. The latter forces runtime evaluation of the nested s-expression to see if it is making props (e.g. (dom/div (makes-my-props) (dom/p ….))
is legal, but requires some runtime checks to see what the function made…props or a component). But then again: I rarely experience a problematic performance problem at that low of a layer. Usually your perf problems are around not using decent techniques in other parts of the stack.
cool, thank you!