@anmonteiro I'm thinking about routing solutions and looking at compassus, trying to grasp how this will work at later stages of development... How would you suggest organizing the database if you have a singleton component that should be displayed in different views? Could you have the component data at the root state level to avoid data duplication? Feels like compassus would require all data be nested into the route key (like :app/home) which would mean one set of data for each component instance..? Do I have to normalize with ident in this case, even though the component is a singleton?

@molstt: I've gone to great lengths to make Compassus usable just like you'd use Om Next normally. So a singleton component that is displayed in different views can e.g. have a link (https://github.com/omcljs/om/wiki/Thinking-With-Links%21) in its query

A link looks in the root of the app state for the key so you can effectively avoid duplication

@molstt: Compassus definitely doesn't require you to have your data under route keys for normalization. Look for example at the normalized devcards example: https://github.com/compassus/compassus/blob/master/src/devcards/compassus/devcards/core.cljs#L126

Let me know of you have any more questions, happy to answer them

@anmonteiro Possibly a bug: React complains about a mismatch between client and server code if there is ’ in some text content.

@levitanong should be a bug, can you produce a minimal case?

@anmonteiro The below should be enough to cause the error

(defui SomeComponent
  Object
  (render [this]
    (dom/div nil “foo’s”)))

@anmonteiro thanks for the links link! seems like I somehow missed it (especially the [:key _] thing).

@levitanong yeah managed to repro, but I have no idea what’s going on 😄

the output looks the same

@levitanong open an Om issue please, and I’ll look into it later

@anmonteiro done

awesome, thanks

👍

@levitanong https://github.com/omcljs/om/pull/801

tested with my om-next-fullstack project too

@anmonteiro 🍻

@anmonteiro when using compassus the read function seems to only be called for the view keys and never for any subkeys in the sub component queries. I suppose this is the intended behavior, according to the readme. But when I want to read from a remote I want to do it only when one of the subkeys in a subcomponent are being encountered, and not every time the view is read. I've been thinking about using another dispatch function to dispatch on parts of the query instead (because unlike the dispatch key it differs between all reads, reflecting the components queries being parsed), but that wouldn't be trivial and doesn't seem like the intended way of doing it.. do you have any ideas about how to accomplish this?

@molstt do you mean, if your route is :foo the parser dispatches on :foo but you want it to dispatch on every key in the FooComponent’s query?

yes

@molstt I had already discussed a similar thing with @peeja. I’m not sure if he’s putting a PR together, but please open an issue so we don’t forget

ok!

it makes sense that we have an option for that

yes, it would fit the wiki tutorial on reading remotes..

https://github.com/compassus/compassus/issues/12

@peeja btw I pushed Compassus 0.3.0-SNAPSHOT the other day

has the additions I’ve made to master since 0.2.1

@anmonteiro Awesome, thanks!

let me know if anything isn’t clear, I think I’ve documented everything