Sigurd Spieckermann

Thanks, @AndrewMorsillo! 🙂 I think some of it is not bad, but there are some flaws in its approach that I have come to realize. For instance, type validation cannot...

How about adding a flag to `types.model(...)` like `types.model(M, { instance: true })` or `types.model(M, true)` to indicate that the _instance_ should be type-checked using the validation type instead of...

Yes, with a large number of props the redundancy is suboptimal. At least TS checks that the validation types are compatible with the data types, so some errors are caught...

Great, thank you very much for your feedback! I'd be happy to give it a try. 🙂

This would be my suggested API for `ExtendedModel`: - Generic extended model (TS only): ```ts @model("myApp/Generic3dPoint") class Generic3dPoint extends ExtendedModel(() => ({ baseModel: modelClass(GenericPoint), props: { z: prop(), }, }))...

I think this doesn't work in the general case. The mapping from the generic types of the extended class to those of the base class is not necessarily 1:1, so...

Apologies for the inactivity here. A quick update: I've started some first steps of implementing this feature, but realized it's actually not so straightforward. Conceptually, I've been wondering whether passing...

I have been thinking whether it makes sense to add a utility function `findParentPath` in addition to `findParent` which also returns the path of the found parent like in `RootPath`.

No, I meant that `findParentPath` may return the parent object and the path from the parent object to the source object from which `findParentPath` begins its search, similar to `getParentPath`...

About backrefs: Shouldn't the return type of `getRefsResolvingTo` be a readonly `ObservableSet`? (Not sure if that's possible by the way because MobX doesn't seem to have a `ReadonlyObservableSet` type ...)