Fork me on GitHub
#om
<
2016-10-05
>
molstt09:10:56

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

anmonteiro10:10:05

@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

anmonteiro10:10:55

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

anmonteiro10:10:10

@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

anmonteiro10:10:00

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

levitanong11:10:58

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

anmonteiro11:10:16

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

levitanong11:10:22

@anmonteiro The below should be enough to cause the error

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

molstt11:10:07

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

anmonteiro11:10:47

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

anmonteiro11:10:58

the output looks the same

anmonteiro11:10:54

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

anmonteiro11:10:18

awesome, thanks

anmonteiro11:10:46

tested with my om-next-fullstack project too

molstt12:10:51

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

anmonteiro12:10:51

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

anmonteiro12:10:51

@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

anmonteiro12:10:14

it makes sense that we have an option for that

molstt12:10:03

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

anmonteiro15:10:22

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

anmonteiro15:10:43

has the additions I’ve made to master since 0.2.1

peeja15:10:51

@anmonteiro Awesome, thanks!

anmonteiro15:10:09

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