I have the following component hierarchy: Wrapper -> Header -> Nav -> [Dropdown1, Dropdown2, Dropdown3] Dropdown1, Dropdown2, Dropdown3 can change based on route (effectively I want a secondary routing system alongside compassus for main routing). I want to be able to add root queries to Dropdown1, Dropdown2...How would you do this?

Global links? {[:foo _] <subquery>}

@jannis What would the query look like in Wrapper, Header, Nav? I was thinking it would involve some recursive parsing like in https://awkay.github.io/om-tutorial/#!/om_tutorial.E_State_Reads_and_Parsing

Do you always need to hike the child query into the parent or can you have a query with a link just floating in space?

Ah, no, I’m almost sure you can’t.

What I’m doing these days is recursive parsing with a single read entry point, using my own query engine and data store. You can lose some of Om Next’s features that way though.

I think it will work with something like this:

(defmethod read :header
  [{:keys [query parser] :as env} _ _]
  {:value (parser env query)})

(defmethod read :nav
  [{:keys [query parser] :as env} _ _]
  {:value (parser env query)})

It just nests it under the key and delegates the query to the next level.

That by itself doesn’t solve the problem but I never liked the idea to use join keys that are tied to the UI just to pull in sub-component queries. So I decided to never do that and always only join on actual data / entities.

Yeah, I don't like it either but I can't see another way other than inventing my own query engine, as you say...

I wrote

(defmethod read :delegate/nav
  [{:keys [query parser] :as env} _ _]
  {:value (parser env query)})

hi all, super newb here... can anyone give me pointers to any overviews on why I'd pick either om.dom or sablono? I presume there's a reason they both exist, and I'm guessing there's some extra stuff that om.dom is doing.

@rgm choose what you prefer. the only thing to be aware of is that sablono won’t support server-side rendering if you eventually want to go through that path

ah, ok. That is a good thing to know, thx.

seems like they mix/match/compose, so if I were feeling particularly hostile to future-me I could om.dom only the parts that I currently guess would benefit from SSR.

seems to be pre-om.next but I guess this'd be another pro of om.dom ... http://swannodette.github.io/2014/02/27/taking-off-the-blindfold

Changing file extensions from .cljs to .cljc and seeing my UI loading instantly with SSR was extremely satisfying

hello guys, any recommandation for validation in forms ? I am not talking about the validator key in factory which assert props (and then throw an error if it goes wrong). I am more talking of a strategy to validate user’s input

Do you use simple components ?

@baptiste-from-paris use Spec.