Fork me on GitHub

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


I’d like to set them up using defquery-entity, but for some reason Fulcro can’t find those when I do that


(defmulti api-read server/dispatch)


This is how api-read is defined, used be om/dispatch from the untangled days


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.


you’d just do a defmethod on the same thing the existing macro uses


if you mean you want to use what FUlcro uses internally

Noah Bogart18:05:44

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?


@nbtheduke probably at least 3 discussions of this in the history of this channel 😜

Noah Bogart18:05:51

lol I'll do some digging, then!


hm…seems the clojureverse history is down?


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.

👍 8
Noah Bogart18:05:50

cool, thank you!


If I have nest db data, i.e. {:foo "bar" :baz {:quux "hi"} and I want my query to add :quux to the root level of the props. How would I do that? So that my props comes back as {:foo "bar :quux "hi"}


I was trying, [:foo :quux {:baz [:quux]}]


I guess using get-query and making a separate component is a good path for that