You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an idea that I had after something that came up recently on Marketplace Mobile.
In MMA, we are using custom TypeScript types to represent custom GraphQL scalar types in TS. Through this method, a DayString, for example, can be used in place of a plain string, but a plain string can't be used as a DayString.
However, when generating fake data for something that is type as one of these custom types, the default returned value from fake-eggs won't satisfy the type (since, for example, fake.day()'s return type is string), which then necessitates type casting the fake data before it can be used.
One way to avoid having to typecast in this situation would be to give the fake.day and similar methods a generic type, so that you could do something like:
constday: DayString=fake.day<DayString>();
to have fake.day return a DayString instead of a plain string.
string could still be the default type so that fake.day() could still be used without having to provide a type in most general cases.
The text was updated successfully, but these errors were encountered:
This is an idea that I had after something that came up recently on Marketplace Mobile.
In MMA, we are using custom TypeScript types to represent custom GraphQL scalar types in TS. Through this method, a
DayString
, for example, can be used in place of a plainstring
, but a plain string can't be used as aDayString
.However, when generating fake data for something that is type as one of these custom types, the default returned value from fake-eggs won't satisfy the type (since, for example,
fake.day()
's return type isstring
), which then necessitates type casting the fake data before it can be used.One way to avoid having to typecast in this situation would be to give the
fake.day
and similar methods a generic type, so that you could do something like:to have
fake.day
return aDayString
instead of a plainstring
.string
could still be the default type so thatfake.day()
could still be used without having to provide a type in most general cases.The text was updated successfully, but these errors were encountered: