Is converting values in the scope of this library ?

[antoinewdg]

A common use case when validating data from external APIs is to have dates encoded as strings.
Let's say I get the following data from a JSON API:

{ "date": "2015-10-12 12:00:00" }

I would want to represent it with the following Runtype:

Record({ date: InstanceOf(Date) })

Is there a simple way to go from the first to the second without having to use an intermediate Record({ date: String }) runtype, and doing the validation ?

I think that having a convertFrom method on the Runtype interface would help a lot.

interface Runtype<A> {
  // ...
  convertFrom<B> : (checkBefore: (x: any) => B) => Runtype<A>;
}

The returned Runtype would be exactly the same, but the check method would be changed to include the additional validation in checkBefore before the one from the initial Runtype.

I could then do:

const Input = Record({ 
  date: InstanceOf(Date).convertFrom(x => {
    const strX = String.check(x);
    const timestamp = Date.parse(strX);
    if(isNan(timestamp)) {
      throw new ValidationError('Invalid date string ' + strX);
    }
    return new Date(timestamp);
 })
});

Do you think it could be added to the library (I would be willing to do it)?

[pelotom]

It would be a departure from the invariant so far that runtypes never produce new values, they just validate existing ones. That said, I can't think of any specific reason that it's a bad idea.

However before you invest time in implementing it, I feel honor bound to mention that io-ts already has this feature, so it might be a better fit for your use case 🙂

[antoinewdg]

It would be a departure from the invariant so far that runtypes never produce new values, they just validate existing ones. That said, I can't think of any specific reason that it's a bad idea.

I completely agree, it would feel a little hacky given that this is not how it works everywhere else in the lib.

However before you invest time in implementing it, I feel honor bound to mention that io-ts already has this feature, so it might be a better fit for your use case

Thanks for mentioning it! I actually came here looking for an alternative to io-ts, and found I liked runtypes better (which is only my subjective opinion, io-ts also seems great).

Anyway, thanks for the awesome lib! :)

[danielo515]

I usually rely on validation libraries to attempt some conversions (Joi for example does this), and return a possible errors and the converted value.
However, if the target of this library is to only check if a type is valid or not, I can totally understand your position. However, I had to open the issues and search for this particular one, if you are already positioned about this I think it will be nice to include it on the readme.

Regards

[brandonkal]

This would be interesting for string => number conversion and 'false' => false conversion.

[MicahZoltu]

I gave io-ts a try, but its interface is much more verbose and (IMO) harder to read than runtypes. This is the one major feature that would make runtypes totally awesome and give me no desire to look for any other options. Ideal interface would look something like a withConverter function:

const Apple = Record({
	color: Union(Literal('red'), Literal('green'), Literal('yellow'), // 'red' | 'green' | 'yellow'
	seeds: String.withConverter(x => Number.parseFloat(x)), // number
})

This way when I'm working with an API that gives me numbers as strings, or byte arrays as hex strings, or any other non-native JSON serialization I can just throw a withConverter on it. Presumably if withConverter throws, that would be caught by runtypes and wrapped in a helpful error that tells me what property failed to convert.

Would it be possible to build this as an another library so this library doesn't have to get into the business of decoding?

[yuhr]

I gave io-ts a try, but its interface is much more verbose and (IMO) harder to read than runtypes. This is the one major feature that would make runtypes totally awesome and give me no desire to look for any other options.

Totally agree 🤣

I'm very interested in this feature and would love to start implementing.

[MicahZoltu]

@yuhr funtypes (a fork of runtypes) has this feature.

[yuhr]

Got it, here's that. It's excellent effort, but deprecating check in favor of parse makes me feel a bit pointless, and I don't understand why ParsedValue is taking duplicate logic such as parse and test, rather than taking just parse and leaving test to Constraint? Could someone explain these points?

[yuhr]

Let's compare, funtypes looks like this:

const TrimmedString = ParsedValue(String, {
  name: 'TrimmedString',
  parse(value) {
    return { success: true, value: value.trim() };
  },
  test: String.withConstraint(
    value =>
      value.trim() === value || `Expected the string to be trimmed, but this one has whitespace`,
  ),
});

TrimmedString.safeParse(' foo bar ')
// => 'foo bar'

With #191, the equivalent code in runtypes will look like this:

const TrimmedString = String.withTransform(value => value.trim(), { name: 'TrimmedString' });
TrimmedString.check(' foo bar ');
// => 'foo bar'

const AlreadyTrimmedString = String.withConstraint(
  value =>
    value.trim() === value || `Expected the string to be trimmed, but this one has whitespace`,
);

As illustrated above, I think the feature like test in funtypes (it guards the input is already conforming to TrimmedString) should be considered as a different matter than transformation. The same applies to inverse transformation (i.e. serialize in funtypes), obviously it can sufficiently achieved by having another runtype dedicated to perform inverse transformation.

[MicahZoltu]

You don't have to use a custom parser. In your example, it looks like you don't want a custom parser, you just want a constraint.

const TrimmedString = String.withConstraint(x => x.trim() === value)
TrimmedString.parse(' foo bar ') // throws error
TrimmedString.safeParse(' foo bar ') // returns error (IIRC, I never use this one so I forget how it surfaces errors exactly)

[yuhr]

I couldn't get the point of your comment. Apparently your code has no "transform", so it does not work the same way as mine. What I tried to illustrate by my example above is nothing else but the equivalent code corresponding to funtypes' code example. What I meant by the previous post is, I think we should follow the "separation of concerns" principle here.

By the way, the equivalent code to yours in runtypes should look like:

const TrimmedString = String.withConstraint(x => x.trim() === value)
TrimmedString.check(' foo bar ') // throws error
TrimmedString.validate(' foo bar ') // returns error

Or, if I reuse my example code, I can write it also:

AlreadyTrimmedString.check(' foo bar ') // throws error
AlreadyTrimmedString.validate(' foo bar ') // returns error

All these are the concern of "conformity after trimming", not the concern of "transformation of values".