Andrew M

@sisp I like that this approach allows for both data and validation checking cases. The redundancy of specifying types in both the decorator and the model might become tedious however....

Ah I understand now. I think your approach is a good one. It seems like having this level of "redundancy" is likely not avoidable if we want full validation of...

@xaviergonz I think that might work but wouldn't be the most ergonomic API since default properties would need to get specified "twice". ex: ``` someNestedStuff: prop().mergeWith(() => ({y: "foo"})) ```...

@sisp Ah, good catch on that use case. As I've experimented further with transitioning some of my models from MST to mobx-keystone I think that the idea of removing `prop`...

I think there might be a lot of benefit to dropping the `prop` API but I definitely see the concern about such a big change. I agree a deprecation warning...

I'm really only talking about code organization here -- functionally there are no problems. These actions aren't common to (not called from) multiple models but they may need to access...

@mashaalmemon I think it's important to note that using `tProp` is not forcing runtime type checking. IIRC the behavior is _identical_ to `prop` in static typescript checking and at runtime...

This is affecting me as well. Even if I manually delete all of the caches like so ``` caches.keys().then(function(names) { for (let name of names) caches.delete(name); }); ``` The cache...

The way the chrome bug affected me and what I am concerned about solving is the case where users end up "stuck" with an old version of the application. This...

I've torn my hair out for several days trying to figure out why my app is crashing in production. It was because of this issue. A library should NEVER overwrite...