Sigurd Spieckermann

On the other hand, when using my suggestion with `tProp`, the input of the prop transform would not be validated whereas with the current approach it is, e.g.: ```ts @model("M")...

Perhaps `tProp(...).withTransform(...)` could return a new `tProp` with the new runtime type? Each prop transform would need to provide it, of course. E.g.: ```ts @model("M") class M extends Model({ int:...

The more I think about it, the more it feels related to the other discussions about dropping `prop` in favor of only using `tProp` (https://github.com/xaviergonz/mobx-keystone/issues/299 / https://github.com/xaviergonz/mobx-keystone/issues/299#issuecomment-905784266, https://github.com/xaviergonz/mobx-keystone/issues/308). What I...

Just a brief comment: Deeply nested default values require a schema like you've shown above, which only exists when using `tProp` and runtime types. It wouldn't work without runtime types,...

Although I don't use `tProp`s at the moment, I see no alternative to using `tProp`s in this case, and I don't think the suggested `mergeWith(...)` method would be sufficient. Think...

> Couldn't you do that use case if mergeWith had as parameter the original snapshot? > > e.g. > > ```ts > prop< > { > kind: 'int'; value: number;...

Ah, no worries, I'll derive an SVG version then.

Just noticed that in their contribution guidelines they request a GitHub project to have 5k stars or more. :confused: MobX and MST meet this requirement. It might be difficult to...

Could you use contexts to dependency-inject common actions (or perhaps also model instances) from parents to children? I think children should not be concerned with where exactly those actions are...

@rkdrnf Do [snapshot pre-/post-processors](https://mobx-keystone.js.org/class-models#snapshot-prepost-processors-fromsnapshotprocessor--tosnapshotprocessor) solve your problem?