yep 🙂 if no ident and query it could just be a normal defn unless you need react stuff there like life-cycle.

True, but Remember that defsc gets you pure component optimization which can be better than just defn

Specifically, I was considering the case of passing an ident to re-read after transact, and if that component had an ident but not a query. I came to the conclusion that it probably never even makes it into the indexer if the query isn't pulled up into root, so the re-read is probably a no-op?

you still in Om Next land?

Or if it could somehow identify the component from the ident, it traverses up the tree to find the closest ancestor with a query, and re-reads/renders from there. But i couldn't see how that would be implemented.

I'm in om.next land, but I'm guessing the principles are similar, or if not, interested how they might be different.

In Om Next ident-based targeted refresh isn’t as “optimal” as you might think…it is just used to find the component. The query still has to run from root unless you enable the ident render optimization.

and then your parser has to be written to support that

in terms of what Om Next’s rendering does: It can “focus” the query only if a component has a query (trim away side branches that don’t need refresh)

I think your indexes would be inconsistent…don’t think it was ever an intended use-case…but the parser does add metadata at every level of props about how it “arrived” at a given component. I think the props you’d pass to such a component would be missing that info (since there was no query to traverse)

so “figuring out” how to step up to a parent would not be possible

In Fulcro, targeted refresh only ever happens if your component has a query and ident.

because that (to me) is really the only case that makes sense in the larger context of the vast majority real apps

when you look at the actual performance numbers, though, the real cost that isn’t ideal is in things like focusing the query, adding path data to the parser result, etc. My experiments for (upcoming) Fulcro 3 show that it is better to eliminate those overheads in preference for a simpler overall algorithm (which Om Next can’t support, because of the requirement of the parser)

primarily because Fulcro has the opinion that the client-side parser is a complex artifact whose benefits are far outweighed by the engineering difficulties it adds…unless you do what Fulcro did: just have it call db->tree.

and at that point, having the parser in the mix just further complicates the full-stack story as well

You should make sure you’ve read this: https://fulcro.fulcrologic.com/vsom-next.html

Interesting, I think I assumed query focusing was standard in om. I imagined it starting from the component with the key to be re-read and taking a slice of the query all the way back to root, and only running that.

But I'm sure you're right, the complexity of that probably adds more overhead than its worth

it does take a slice back to root

but if you have an ident on the component, and only use db->tree, then it is trivial to already know the query you need (in isolation)

[{ident-of-component query-of-component}]

so no query focus, no path meta (which is more expensive than db->tree), no parser (which does multiple passes), etc.

you can make the whole mess many times faster (and less confusing internally and externally)

Have trouble groking that, because components with idents are usually nested and their query is not the whole query, its a partial query

Don't you need the slice back to root, to know where to start reading?

the ident is the place to start reading if your db is normalized

i.e. you know part of the query, but you still have to work your way back to the full query

Aah, yes, right

that’s where you’ll always be no matter what query you followed to get there

Yes, obvious now

unless you’re using a parser that can “mess with that”…like adding context to env as it goes

which is why Om Next can’t turn that on by default

but Fulcro can

lots of really nice things fall out when you drop the parser on the client…and you lose nothing that doesn’t have another (cleaner) way of doing it

95% gains….5% losses

which is why Fulcro exists 🙂

Fulcro 2 doesn’t have Om Next as a dep anymore but it has a lot of the internals. Fulcro 3 will have very very little original Om Next code in it. Fulcro’s internals are more complex than they need to be bending over backwards to use Om Next arch

Yep, i've followed fulcro's development from a distance (know that it dropped om next). By dropping the parser on the client, do you mean providing a stricter api for reading/mutating state? That's how I understand it

Presumably there is something similar to a parser underneath, but you're able to control how it's used

so, all mutations are is a way of turning a bit of data into a list of operations…you don’t need (much) parsing to deal with that..simple AST conversion and reduce is all.

for reads: db->tree is really sufficient. Loads really should not be part of the parser IMO, as described in that doc, and other things I’ve published

Let me read that page on the differences, because i think it may clear up a few things

what do you need to do a load via the parser? You need a mutation. Because otherwise you haven’t “remembered” what you queued to load and if another parser run happens you’ll queue the load again.

I mean, you can swap on state as you “parse”…it’s just all convoluted

then you’ve got the root trimming madness, etc…it’s all really very overly complicated

the parser (as a way to hydrate UI) gives you nearly nothing at very great cost in all practical cases I’ve found. Sure you can come up with theoretical benefits, but I care about getting stuff done

Yep, sounds like it resonates with my experience

I usually find a way to get stuff done in om.next, but sometimes it isn't pretty

@U0DHDNZR9 ^ that was exactly my experience until i started using fulcro

AFAIK om next was never actually used by it’s author(s) in an actual application

it has a lot of really good ideas, that fulcro adopted, but also has a bunch of rough edges and was never completely finished