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
typeRequest={// Feature: convert strings to numbers.quantity: number,// Feature: convert datetime strings (v.dateTime) or numeric timestamps to Dates.sessionTime: Date,};constRequestType=(reify: Type<Request>);// One possibility for a conversion decoration API. flow-runtime ingests the explicit// type on the input parameter to determine how to widen the type.RequestType.getProperty('quantity').addConversion((raw: string)=>{constvalue=parseInt(raw,10);if(isNaN(value)){thrownewTypeError('expected a base-10 integer');}returnvalue;});// The convert method is a modified assert that expands the supported types to include// types that can be casted.constvalue=RequestType.convert({// value.quantity could become 12, or this behavior could be customized like in// the constraint model by mutating a PermissiveNumber type.quantity: '12.0',// value.sessionTime becomes Date(2019-11-19T01:53:00.000Z)sessionTime: '2019-11-19T01:53:00Z',});
A v1 here might be to just decorate all Types with convert methods and conversion arrays that we can extend with addConversion. This would mostly be trying to solve the same use-cases as joi's convert option.
A v2 might be to support a conversion where the types in and the types out are entirely disjoint - e.g. convert(input: string | number): Date but via a declarative syntax
A v3 might be to include default conversion functionality like string -> number, but that'd require a bit more exploration.
I'm open to working on this; just curious if y'all have thoughts on the API/concerns about the implementation.
The text was updated successfully, but these errors were encountered:
I'm tempted to say that some of this functionality shouldn't be in the flow-runtime core; I think this pattern might be possible with type introspection/or a visitor pattern #5.
This is a:
Which concerns:
No affordance for
convert
behavior:A v1 here might be to just decorate all
Type
s withconvert
methods andconversion
arrays that we can extend withaddConversion
. This would mostly be trying to solve the same use-cases as joi'sconvert
option.A v2 might be to support a conversion where the types in and the types out are entirely disjoint - e.g.
convert(input: string | number): Date
but via a declarative syntaxA v3 might be to include default conversion functionality like
string
->number
, but that'd require a bit more exploration.I'm open to working on this; just curious if y'all have thoughts on the API/concerns about the implementation.
The text was updated successfully, but these errors were encountered: