The more I think about it, the more I think I don't understand how Om Next is supposed to work…

Am I correct in thinking that idents in the app state are meant to be an implementation detail of normalization?

Actually, the more I think about it, the more I realize there's less "supposed to" than i expected. 🙂

should (om/react-key (dom/div #js {:key :somekey})) not return :somekey?

Is there a way to clear/reset om's history? When a user logs out of the app I want to make sure I reset the application state.

make a mutation that resets the app-state, perhaps on componentWillUnmount? or logout :onClick ?

hlolli updating the app state I can do. Looks like clearing the history in the reconciler should be pretty straightforward, too.

Om Next's notion of "parent" is actually React's notion of "owner", is that correct?

That is, it's not based on the rendered tree, it's based on the tree of who builds which components

So if you build a component and build a second component you pass into the first, you're the Om parent of each

wrapping my head around om.next. Is the parser a combination of redux’s selectors and reducers? Specifically mutate fn = reducer and read fn = selector? or are they fundamentally different?

i suppose the queries are much more flexible than selectors and are co-located in the component. but transact! seems similar to dispatch

@liamd query concept is just lifted from Relay not Redux

however yes there is of course some conceptual overlap with Redux due to the functional approach

@peeja it is based on the render tree as that’s the way we propagate that information - it’s possible we could do it via the React context stuff, but I haven’t looked into that

Is it? It looks like it's based on dynamic binding.

it is but dynamic binding doesn’t work async

rendering isn’t async

and that’s where we establish the binding

So, if A builds B and C, passing C into B and returning B from its render, and then B wraps C in a div, who's the parent of C?

A or B?

A built it, but B is its closest ancestor in the DOM

you can answer all these questions by thinking about what I said

Okay, that's pretty condescending, honestly

I have thought about all of this, and read through the code, and found it surprising

you can interpret it that way if you like

or assume I’m being brief because of time

@peeja RE: the AST stuff, :query is a convenience

you’ll want to discard it if you’re doing something fancy

I’m unaware of any sophisticated users of AST so have had limited feedback about that

That makes sense

From what you're saying and from the code I'm reading, my understanding is that A is the parent of C. Is that correct?

just think about binding

there’s no need to consider anything else

if you build in some strange way, yes it won’t work

That's not strange, that's just higher-order components

That's a significant part of using React

I don’t really think that it is

and you can make it work if you like

You're saying it's strange to pass children to a component?

I don’t think it matter’s much

still I understand the attraction

Okay: I have old Om components and Om Next components. I need them to render each other sometimes. I also have native React components occasionally, and a bunch of functions which pretend to be components but are just functions that return React elements. I need to make sure I'm not screwing this up.

if there’s a way to thread the relationship via some other means more realiable in React then I’m open to the idea

I'm specifically not asking you to think through all of that for me, I'm trying to respect your time by asking a very straightforward question to validate my own conclusions.

I don’t know what you’re trying to do

I'm not saying that what Om does is wrong, I'm just clarifying that it represents what React refers to as "ownership", while React's notion of "parenthood" is based on the DOM tree.

we did relax the transact! case, so maybe some things will just work

React ownership isn’t changed

it’s all just React

the om.next notion of parent is something else entirely we use for other stuff

I'm not saying React's ownership changes, I'm saying that Om calls something "parent" which corresponds to React's notion of "owner" and not to React's notion of "parent".

That's not bad, I just want to make sure I'm correct in coming to that conclusion.

@peeja but I don’t know why this matters?

Because I have to muck with Om internals to get the parent chain to work properly here, and I want to make sure I'm doing the right thing.

I have to capture the correct dynamic vars when building an om.core component, keep them in the shared map, and then rebind them when I start rendering om.next components again.

(and the same in reverse)

AFAICT, that's the only reasonable way to migrate an app from om.core to om.next.

well we’re talking about too many different for me at the moment (om.core -> om.next)

but still, having to fix the parent chain is a bit ugly

we could instead have this be a stateful field that’s set when we have the info

I don’t know how much work that is - but probably not too hard?

happy to see someone work on that - at first glance I don’t see how it could cause any real problems

When you say "stateful", where do you see that state living?

just put it on the instance

or on state which is wrapper around raw React state already

but my impression is that the first thing should work

so it’s just a lazy field set after mounting

the primary problem is we don’t care about random React components

we only care about parents invovled in queries

Right, but the parent chain already has non iquery?s in it, and they're filtered out

so that should be okay

but you don’t control React components

how will you propagate?

Oh, yeah, no I don't have a solution for that

so Relay must have solved this - probably with non-public hacks

anyways I didn’t have time to look into it

As you said earlier, context might work, but context stuff has been changing a lot

and I didn’t really see higher order components as the end-all be-all

i.e. multimethods work just fine for composition

with delayed decisions

To be clear: I don't actually need higher-order queried components

I just need higher-order dumb components not to break the query chain

because they will hold something with a query?

That's right

Which should be fine

right so that’s higher ordered query components far as I’m concerned 🙂

anyways I think you understand why it is the way that is

if you have brilliant ideas I’m listening

Wait, why are those higher-ordered queried components?

For instance: We've got a component that builds a card (visually)

I want to wrap this Person component in a Card component

Person has a query, Card doesn't

I build the Person and the Card, and pass the Person into the Card to render

I build the Person with props from my props

I build the Person within my render, so I'm the parent

So there should be a correct chain from me to the Person that doesn't care about the Card component at all

I don’t think this part is all that relevant to the bigger point 🙂

Then I think I'm missing the bigger point 🙂

What is it?

I’ve explained the issue

what are you still misunderstanding?

the jargon doesn’t matter it seems to me

Oh, you're saying for the migration case, rather than the higher-order case

no, I don’t want to talk about the migration case - that’s downstream

Then I'm lost

the higher-case I’ve explained why it doesn’t work

I just explained why it does work, though…

that’s all that matters - then you can solve your subproblem

it doesn’t work

parent gets set when invoking the factory based on the bindings in place

Right. And the factory is not invoked by the higher-order component

yes

It's invoked in the render of the correct component

are we repeating ourselves here?

Yes, but we're coming to opposite conclusions 🙂

you compose B with C in A’s render

both will have parent A

Right

that’s not what you want

Sure it is

A -> B -> C

Why wouldn't you want that?

C's query is composed directly into A's

Its data path runs A -> C

they all have queries

it won’t work

Why would you have a higher-order component with a query?

why wouldn’t you?

Because I can't imagine how it would be useful

why do you believe that?

M-x doctor

😛

How would you compose the query?

What could A's query look like?

this is assuming there’s only one way to compose the query

I mean, you could have a B with a query, but it would have to be independent of C's query anyway, right?

You'd still want the parent of each to be A

once you disabuse yourself of that idea then you see you might want to do this

nothing about Om dictates how the queries are composed or resolved

Can you actually come up with a use case to demonstrate how it would be useful?

it’s just a function

Wait, that's not accurate

anyways I can’t do a brain dump right now

sorry, gotta get back to work

Om requires you to compose queries in a specific way to maintain the correct metadata

the default does

but you can replicate that however you feel like it

I see what you're saying. I'd love to see a use case someday to validate its utility, but I get what you mean.

In any case, the good news for me is that this means there's no problem with what I'm doing. So… 🎉

Thanks for talking it through

np