Fork me on GitHub
#fulcro
<
2019-05-15
>
exit218:05:56

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

exit218:05:12

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

exit218:05:17

(defmulti api-read server/dispatch)

exit218:05:24

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

tony.kay18:05:36

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

exit218:05:09

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.

tony.kay18:05:28

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

tony.kay18:05:41

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?

tony.kay18:05:43

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

tony.kay18:05:35

hm…seems the clojureverse history is down?

tony.kay18:05:43

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!

exit219:05:49

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"}

exit219:05:48

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

exit221:05:06

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