-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in 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: