-
-
Notifications
You must be signed in to change notification settings - Fork 144
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
Feature Request: typia.transform - delayed type specification #968
Labels
Comments
seo-rii
changed the title
Feature Request: typia.transform
Feature Request: typia.transform - delayed type specification
Feb 17, 2024
I think By the way, I'm sorry but cannot sure when to develop it. export function prepare<T>(): Feature<T>;
interface Feature<T> {
is: (input: unknown): input is T;
assert: (input: unknown) => T;
protobuf: {
assertEncode: (input: T): Uint8Array;
};
} |
can I work on this issue? |
Of course why not? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
One of the limitations of
typia
is the inability to set types as generics. This creates a number of constraints, which are unfortunately difficult to resolve. To mitigate some of these constraints, I propose the introduction of atypia.transform
function.typia.transform
takes a single functionf: (x: any) => any
as its argument. The returned value is promisified as the basetypia
module, and data is processed through the argument function and awaited before being passed on. In other words,await typia.transform(f).is<Data>(x)
is equivalent totypia.is<Data>(await f(x))
. This function will allow for wrappingtypia
without using generics, which is currently impossible due to the aforementioned limitations, forcing us to return the functions as they are.Consider the following scenario: We wish to create a wrapper function for
typia.assert
that takes a numeric ID, calls an API, and asserts the type of the response. Using the proposed method, we could create a wrapper function as follows:Currently, to achieve similar functionality, we must pass a checker function to each function as mentioned in issue #125, which is less convenient than the example provided.
If there are existing solutions that I have overlooked, I would greatly appreciate your input.
The text was updated successfully, but these errors were encountered: