If I query for a prop in a component, key->components with that prop finds the component. If I query for an ident in a component, key->components with that indent doesn't find the component. In both cases, the key that's queried for ends up in the indexer in :prop->classes, but the indexer only looks there for keywords: https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L1901

key->components for an ident appears to only find components whose ident is that ident, not components which query for the ident

Is that a bug, or am I missing something?

In my case, I have a parent querying with the ident, rendering a child whose ident is that ident. At first, there's no data, so the child has no props, so it can't calculate its ident properly. When the remote data comes in, I need the parent to re-read so that it gives the child its props. The child doesn't know to re-read because it doesn't have an ident until there's data back from the server.

I suppose the parent could cheat its knowledge of the ident into the child's params somehow, but that feels like it's not the way it's supposed to work.

(Also, if the parent queries by an ident and shows the data from that ident directly, rather than using a child component, the parent won't be updated when new data comes in.)

@peeja sorry that’s doesn’t make a lot of sense

I think we index idents as idents and links as props

unless you’re conflating the two

Ah, I didn't realize there was a clear line between the two

Which is which?

ident: [:x/by-id 1]; link: [:x ‘_]

the difference is the _

Oh, really? I thought they were both idents and links…

The documentation calls them both both, AFAICT

https://github.com/omcljs/om/wiki/Thinking-With-Links%21

> Om Next is designed out of the box to fix this problem by making links (also called idents) a first class concept.

@peeja https://github.com/omcljs/om/blob/master/src/test/om/next/tests.cljc#L406-L409

so they’re both idents. but links are called “unique idents"

the difference is in the semantics

Got it. That makes sense. The tutorial's a bit ambiguous, but it's pretty old at this point.

an ident (not link) refers to something in the (normalized) app state that you can access with get-in (e.g. (get-in app-state [:x/by-id 0]))

a link doesn’t have that property

In this case, I'm talking about a regular ident

so regular idents are not indexed by their key

they’re indexed as themselves

Right, but only the components which have the ident as their ident are indexed

Not the components which read the ident

pretty sure they are?

look at the tests I linked above

If I have a component whose query is [{:current-user [:user/name]} {[user/by-id 5] [:user/name]}], that component is indexed by :current-user, but not by [user/by-id 5]

Huh. That does say what you're saying

it’s hard for me to believe what you’re saying because the tests pass 😛

That's fair 🙂

But that's good news for me. That means my app is doing something wonky, but my expectations of Om are correct

@peeja so here’s something that happened to me and could be happening to you

you have component with ident [:x/by-id 0] mounted

your remote returns a response with [:x/by-id 2], but that’s not indexed because it never mounted

it won’t re-render [:x/by-id 2 ] or associated components

I'm not sure I follow. What would you want to re-render, if there's no [:x/by-id 2] mounted?

wait that’s not the correct explanation

🙂

right, so the real problem is: you have a component with ident [:x/by-id 0]. now your route changes and you want to show entity with ident [:x/by-id 2]

this might get funky because React reuses instances

so although you’re rendering [:x/by-id 2] now, the component’s ident didn’t change

¯\(ツ)/¯

@peeja that make sense? ^

Oh, yeah, I think so

then although [:x/by-id 2] is mounted, it’ll never re-render because the component’s ident is [:x/by-id 0]

so the solution is to make the component’s ident depend on the current route

But won't it re-render because the parent will pass it new params?

if the parent's query depends on the route

it won’t re-render in the following case: 1. you make a remote call with query [{[:x/by-id 2] [:foo :bar]}]

2. [:x/by-id 2] is queued for re-render in merge!

but the component’s ident is [:x/by-id 0] because React reused the instance 🙂

OK that was hard to explain but I think it’s clear now?

By the time 1. happens, why hasn't the ident already become [:x/by-id 2]?

in my case, because the parser assembled the query’s ident based on the current route

but the component’s ident didn’t depend on that route

that said, this was a few months ago so I don’t know if I would structure that app the same way

and if the ident is based on the component's data, the data coming in from the server, it doesn't update the ident until it re-renders, but it doesn't re-render because it hasn't updated to the new ident

Is that the trick?

It's a chicken-and-egg problem

yeah

So, that's not exactly what I'm hitting, but it's pretty close

might be a variation

This is when the app is first loading, and I mount the child, but with empty params, because there's no data loaded yet

so its ident is [:x/by-id nil]

right

But it seems like when the data comes in the parent should be re-rendering, and that that should set everything right again

so it seems to me that’s exactly the same problem

For some reason, the indexer doesn't find the parent, but it seems like if that were working, the whole thing should work again

(Yeah, you're right, it is the same problem after all)

here’s something for you to try: in your parser, return {:keys [...]}

and override :merge in the reconciler so that it also queues the keys that you return from the parser

I’m not certain that will work, but it would be an elegant solution 😛

Huh, that's a neat idea

Oh, but that doesn't solve the problem here

merge is returning the right keys

The key doesn't point to the parent component

(but it should, according to those tests)

@anmonteiro Oh! I misread the test.

That only tests that the ident shows up in :prop->classes!

It shows up in my :prop->classes too, but the indexer doesn't look there for idents

It has to be a keyword for the indexer to look there: https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L1901

@peeja hah!

seems like a bug maybe?

Seems like it to me

Otherwise there's not much point storing it there 🙂

exactly

@peeja awesome, thanks for digging in. open an issue and I’ll get to it

Thanks!

If anybody wants to poke around, I made a clone of codenames (a fun little board game) using om-next. Code is here https://github.com/diminishedprime/secret-agent-ui suggestions are welcome.

@mjhamrick Ooh, cool!

Live demo on the github site, too. (https://diminishedprime.github.io/secret-agent-ui/)

@peeja btw currently working on cool stuff for Compassus, should solve this one in a nice way: https://github.com/compassus/compassus/issues/3

@anmonteiro I notice the indexer has this extfs that's overridable. Is that something I could use to implement a workaround for now?

Ah, nice

should also allow for setting params, not only queries

@peeja you sure can. here’s how to override that https://github.com/omcljs/om/pull/770/files#diff-106b1ef933177ab802b55f86a942230eR2372

Ah, you can pass in :indexer. Perfect!

Thanks!

@mjhamrick looking good!

no idea how to play though 🙂

@anmonteiro , take a look at this pdf if you're interested. http://czechgames.com/files/rules/codenames-rules-en.pdf Needs at least 2 players, much better with 4 or more (in my opinion)

I found out about the game at clojure-conj last year.

@anmonteiro https://github.com/omcljs/om/issues/772