What would happen if we did validation in builder methods instead of instantiate

[coolsoftwaretyler]

In, #2204 @thegedge said:

I might even go a bit further and say that the views and actions functions should do the validation, not even instantiateXYZ. When doing so, we can assume that model.create will always produce a valid instance with no conflicts, which would in turn may allow us to drop various safety checks we do post-instantiation (good for perf!).

I think this is really interesting. I'd love to explore it a little more.

My first concern is for people chaining views and actions calls for TypeScript reasons. Would they pay a performance cost for that pattern where they weren't before?

[thegedge]

I have various reasons for my stance:

1. I generally prefer software to fail as soon as possible.
2. I prefer things to fail at "boot time" rather than at "run time", which this would do (unless you're only creating models dynamically at run time). Note, this isn't my strongest reason, because it's likely CI will catch most people's "run time" issues.
3. By failing when creating views/actions/volatiles, we can likely provide better error messaging. The way we check for this scenario today is kind of sketchy, and I'm not even sure if it can only be the scenario where some view/action/volatile overrides a property.

My first concern is for people chaining views and actions calls for TypeScript reasons. Would they pay a performance cost for that pattern where they weren't before?

There'll definitely be a cost to this now, but my thinking is that we're mostly just shifting an existing cost around, and that the cost itself is pretty small.

For the benefit of anyone else reading: I haven't quite figured out why, but the current way we do these checks is perhaps leaking the snapshot reaction we set up on instantiation. By shifting this check sooner, you actually avoid paying a bunch of cost associated with failed instantiation (because this fails quite late in the instantiation process).