-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Switch prop type and prop transform output type? #369
Comments
On the other hand, when using my suggestion with @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. 🤔 |
Perhaps @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? |
The more I think about it, the more it feels related to the other discussions about dropping 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 #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. |
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.:What do you think?
The text was updated successfully, but these errors were encountered: