Support re-usable factory functions

[janvanbouwel]

Summary

Passing is<> as an argument does not get transformed, and there is no alternative like createIs<>(). In case this is intended behaviour, the error message is unhelpful.

• Version: "typescript-json": "^3.3.12" (also on dev version)

Code example

import { is } from "typescript-json";

const verifier = is<string>;
console.log(verifier("abc"));

function test(verifier: (x: unknown) => x is string) {
    console.log(verifier("abc"));
}

try {
    test(verifier);
} catch (error) { console.log(error); }

try {
    test(is<string>)
} catch (error) { console.log(error); }

try {
    // ugly fix, especially with more complex types
    test((x): x is string => is<string>(x))
} catch (error) { console.log(error); }

• Expected behavior:

true
true
true
true

• Actual behavior:

true
Error: Error on TSON.is(): no transform has been configured. Configure the "tsconfig.json" file following the [README.md#setup](https://github.com/samchon/typescript-json#setup) at [...]
Error: [...]
true

[samchon]

It is possible to converting such is<T> statement without function call. Just by activating below code.

• https://github.com/samchon/typescript-json/blob/master/src/transformers/ExpressionWithArgumentTransformer.ts

However, I head that such statement is sometimes dangerous because even mistaken code could be transpiled. Therefore, I need to get hear many users' ideas about this issue. Before listening and accepting or rejecting this issue, I recommend you to define function variable like below instead.

For reference, below hoisting function does not reduce performance when comparing with your suggestion.

import TSON from "typescript-json";
const verifier = (input: string) => TSON.is<string>(input);

[janvanbouwel]

Thanks for the quick response! Although it works for now, my main issue with that solution is not performance but ugliness of having to write the type twice, making the code less readable and more annoying to change. I can't comment on the potential dangers, as I do not have experience with implementing transformations.

Solutions could be:

• Reintroducing createIs<>()
• Enabling that transformation with an extra transformation property, like functional and numeric (but disabled by default)

[samchon]

I couldn't understand why typescript-is is providing such vulnerable functions like createIs() and createAssert().

However, listening your suggestion, I understood that why those functions are provided.

How do you think about in this case? Whether introducing making hoisting function would be better or creating those new functions like createIs() or createAssertType() would be better?

[janvanbouwel]

I don't know what makes createIs() vulnerable. To me, using is<Type> directly feels more intuitive than having to use createIs<Type>() but if you want to avoid the former createIs() would work. (In this case the error message above could include "Error on TSON.is(), did you mean createIs()".)

Having to wrap is in an anonymous function each time (is that what you mean by hoisting?) is cumbersome and something I'd like to avoid.

[samchon]

Okay, I will consider better solution and it would be published at this Sunday, maybe.

Thanks for suggestion.

[samchon]

I agree with you that such statement is right const checker = is<T>; checker(input).

However, there're some people who've migrated from typescript-is to typescript-json and the new functions should be same with the typescript-is for them. Therefore, below functions are newly added. Now, only writing README content is left, but if you wanna use it early, then install next tag:

npm install --save typescript-json@next

• TSON.createAssertType()
• TSON.createIs()
• TSON.createValidate()
• TSON.createAssertEquals()
• TSON.createEquals()
• TSON.createVallidateEquals()
• TSON.createStringify()

[samchon]

@janvanbouwel Now, update to v3.3.13, then you can use those above functions.

[janvanbouwel]

Works like a charm, thanks a lot!