@tony.kay: An easier read for first timers than previous documentation because there are no longer gaps. I really like it. If you needed to shorten it the om/computed in depth explanation could be put elsewhere - for getting started all application programmers need to know is that functions passed down to child components are to be handled differently: you can get a long way without knowing exactly why that's the case. That's my proofreading feedback.

I can’t get away from computed, because of thecallback I need 😕

It would be confusing to use it without some kind of nod to why

or did you mean to just kind of trim it down?

I guess that is what you’re saying….sorry didn’t read carefully enough

Thanks for proofing it! I think the new additions also make it seem more approachable. No parsers needed anywhere, until you start wanting to convert queries to graph walks of SQL

and even that could be done as a transform instead of a parse

What is great about it is the flow - telling a story and filling missing bits in as go.

Yeah, I had tried to do that in the quick tour in the dev guide, but I think it was too light

not sure how many times I have to write this before I like it 😜

3000 lines of code, 20,000 lines of docs

The first time users needs to go away having understood all, or almost all. The computed stuff is difficult and not absolutely required.

Esp - 'wrong way' - I must admit I didn't read that part.

Thing is I’ve just spent several pages telling that you “just pass stuff as props”. I’ll re-read it and see if I can make it shorter without feeling like I’m going to lose people

There’s a fine balance between boredom and confusion

and unfortunately that line is different for everyone

I’d rather have more bored and less confused

I've never really 'got' what's going on with computed, so perhaps it is hard for others too. All I know is as an app programmer I follow the rule - "if its not props I use computed".

perhaps if you read “wrong way” part…

but I hear you, rules are easy to follow

you don’t need to know why

Yes I will now 🙂

I get stuck on the why

I don’t like magic

But the line is important - between what user of framework needs to know and what builder of the framework needs to know.

agreed. Understanding computed is one I think the user should know..even though I see your point that there is a rule to follow. Cause if you don’t follow the rule, it looks like it works…until it doesn’t

and a lot of devs will run with things that look like they work, then get bogged down when they do “weird things”

and there’s nothing I dislike more that banging my head against a wall when trying to get something done. I guess that’s why I want to knw why…helps me debug

Perhaps I’ll move the why to a section marked optional, and simplify the main flow to just state the rule…“if you want to make stuff up that didn’t come from the query engine and pass it to a child, put it in computed”

i just re-read it. I reworded one sentence, but otherwise I still like it as-is

the explanation is pretty simple, if anything I could make a diagram or something.

I reworded this:

The problem is that Om can optimize away a re-render
of a parent when it can figure out how to pull just the data of the child on a refresh, and in that case the
callback will get lost because only the database data will get supplied to the child!

A few more tweaks and now I’m definitely happier with it. Thanks for the feedback

I have an ident that points to a ident that I use in a form that then breaks on untangled.ui.forms/validate-form Are idents that point to idents supported in om.next or am I breaking stuff? Or maybe I found a issue on form-support in untangled

An ident is supposed to point to a table entry

I don’t think a talble entry is supposed to be anything other than a map

@mitchelkuijpers

you’d have to look at the implementation of db->tree in Om, but I suspect it isn’t