I’ve written up my thoughts on routing https://github.com/omcljs/om/wiki/Routing-Support

everyone working on routing should read this and provide feedback

based on the various solutions I’ve heard about - revisiting some assumptions and thinking a little bit differently about the problem should allow people to build robust and sophisticated routing solutions that don’t have the over-rendering problem

@dnolen: thanks for posting about routing - it’s something very important to me and i’m still don’t feel like i have a handle on how to do routing in a clean way in om next. "Questions like how to propagate or modify parameters from the top-level means users have not yet seriously considered the various tools around query - the simple AST”. what are you suggesting here? read-time interpretation of the ast? like using a union query and subselecting the interesting pieces based on the db state?

no separate everything I’m saying from storage or parsing

not relevant to this conversation

A) routing must happen from above at the root

B) what’s needed to make this tractable

that’s the only thing I’m interested in

do you think it should happen from the root and involve om/set-query!

it doesn’t matter how it happens

it could happen via the reconciler

basically I’m trying to get people to stop thinking about concrete stuff

only the actual problem

is there any notion of routing in relay or falcor that we could emulate?

nope

but again I’m not interested in routing

I’m interested in making it possible to do clean routing

got it. why concretely is that not possible with om next right now?

you can do it but not optimally

for example the router wants to parameterize

but the way query params on components works means people make the wrong assumptions

and over-render

instead people should be propagating params via the router

also rendering at the root whether via reconciler or root component means re-rendering everything

even if some nested child is just switching views

note that these are the fundamental concerns and problems - I don’t care about what high level solution people come up with. If the fundamentals get sorted people can build exactly what they want how they want

https://github.com/omcljs/om/issues/519

Re: routing, one thing I like about using joins for routing is that you can still get the root query of the application and know the entire demand for the application across all of it’s logical “pages”. This puts the burden on the programmer to give him or herself the correct semantics for when to fetch data through the parser implementation, but with set-query! you are kind of back to reasoning about objects changing over time.

@noonian: I’m not suggesting set-query! is what people will ever use directly

I’m only talking about people who want to build some generic router thing and the hooks they need

Ah, I see. So you could ship a routing component with no ties to application specific code and ship it as a library?

well it would be tied to application code but yes it could be a library

so some routing library might support

(set-view! [:main :login])

and this generically works with queries etc.

Yeah, you might ship both a component and a function to drop into your parser for one of the keys or something

also for for making urls maps to queries etc.

@dnolen: thanks for you thoughts. I have to meet some people for lunch but will be thinking about this

Is there any reason why this here https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L955 says must be “ref or keyword”, but the condition is only (if (keyword? k))

I’m getting an error when a remote returns an ident rather than a keyword at the top level of the map