Sigurd Spieckermann

> I noticed another requirement that the runtime validation should satisfy in my opinion. While `mobx-keystone`'s current runtime type-checking only applies to model (state) properties, I think a comprehensive runtime...

I also agree with @Sladav and you about "application state" vs. "user input state", but I had only seen it this way for standard user input forms although the idea,...

@xaviergonz: Yes that's right, although in both cases the prop `value` is needed just to be able to express the "or" relationship. If this was the only problem, I could...

> If we added a typeCheck() optional method to models (that gets invoked as part of the runtime type checking), would it achieve the same? Well, for this particular refinement,...

The last idea seems to require TS types for abstract class properties derived from a mapped type which I don't think is (currently) possible. When the runtime type is provided...

@xaviergonz Not sure if you've missed my comments in #195 or didn't have time yet or perhaps absolutely dislike that PR, but is there any chance you could check it...

Yes, you're right. Your observation is related to #369, something I stumbled over while working on those BigInt features.

Something like `types..withTransform(...)` is along the lines of what I was vaguely trying to say in https://github.com/xaviergonz/mobx-keystone/issues/369#issuecomment-1019461236. Runtime types might ultimately not only check types but form a data schema...

> That being said, if there's a types.bigint with a built-in transform probably there should be a types.date("timestamp" | "isoString") as well... (I'm not implying that should be part of...

Hm, do you still have that branch and would you share it?