Switch prop type and prop transform output type?

[sisp]

While adding the stringToBigIntTransform prop transform, I found it not very intuitive to give the prop the encoded type (e.g. string) and then apply a prop transform to get the desired type (e.g. bigint). Instead, I think the opposite order would be more intuitive, e.g.:

@model("M")
class M extends Model({
  int: prop<bigint>().withTransform(bigintToStringTransform()),
  date: prop<Date>().withTransform(dateToTimestampTransform()),
  // ...
}) {
  // ...
}

What do you think?

[sisp]

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.:

@model("M")
class M extends Model({
  int: tProp(types.string).withTransform(stringToBigIntTransform()),
  date: tProp(types.number).withTransform(timestampToDateTransform()),
  // ...
}) {
  //
}

Nevertheless, this API feels not so intuitive, at least to me. :thinking:

[sisp]

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.:

@model("M")
class M extends Model({
  int: tProp(types.bigint).withTransform(bigintToStringTransform()), // -> tProp(types.string).withTransform(bigIntToStringTransform())
  date: tProp(types.date).withTransform(dateToTimestampTransform()), // -> tProp(types.number).withTransform(dateToTimestampTransform())
  // ...
}) {
  // ...
}

Do you know what I mean?

[sisp]

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 mean is: Property transforms in the general case are not a feature of model props but an encoder/decoder mechanism of runtime types/schemas. Similarly, as discussed in https://github.com/xaviergonz/mobx-keystone/issues/299, deeply nested optional fields with default values can only be expressed properly using a runtime schema. So I think the ultimate solution to this and the other topics may be building out the runtime types beyond mere type-checking.