This is the kind of type that Microsoft should have created in the beginning, but never did. I like TS but always hated that it can only use nested ternaries to express switch cases. At least with this type buddy, the syntax looks so much cleaner. Thank you so much! 😊
2:26 I'd suggest you to consider "early returns" here as an option. This would make it even easier to understand. You don't really need to use "else" if given option doesn't pass the execution further (which is seemingly always the case here).
@@Typed-Rocks Yes, something like: function Find(A) { if (A extends string | number | boolean) { return StringOrNever; } if (A extends Array) { return Find; } if (A extends Date) { return object; } return never; } function StringOrNever (T) { if (T extends string) { return string; } return never; } Or even more simplified version (however i doubt it withstand more sophisticated cases): function Find(A) { if (A extends string | number | boolean) return StringOrNever; if (A extends Array) return Find; if (A extends Date) return object; return never; } function StringOrNever (T) { if (T extends string) return string; return never; }
really like the idea. maybe typescript team can add a new keyword "typefunction" which dev can write a type function. typefunction Maybe(T) { if (T extends string) return string; else return T; }
Is there a scenario in TS rn where it makes sense to write "type function"? because if not, it seems like a cool idea to just make that a "composite" keyword as it is in this "proposal". It'd fit right in and make so much sense!
Buds, can we all agree thats should work in .ts files without any IDE extensions? I'm thinking of a babel plugin to do it in the background, what do u think?
Amazing thing, a suggestion though, can we write it like this instead: functype Find {} That way it’s more consistant between the definition and the call, and is compatible with the current TypeScript syntax. And can you make a proposal to the TypeScript team to add such a feature to the TypeScript itself?
I don‘t think that the team will approve of it, as it‘s a huge change to the current state. Because of the functype, currently this would stop proper syntax highlighting. But I will look into it
This is actually a great idea. Will try the web version after my holiday vacation. Question: would it be possible for you to abstract the "infer" syntax with something of your own? Like "getInnerType" or something. I see people always having problems with the "extends" in combination with "infer" all the time.
Let me know what you think about the web version. Currently I‘m not planning in adding „own“ syntax to the functional style as it makes it really hard to have proper syntax highlighting etc
In my case I don't use nesting like that, but instead I use () brackets to group types. While it does not change anything meaningful, it make it readable to me.
Having regular runtime functions use parens for their value parameters, and type functions use angle brackets for their type parameters? that's actually such a good way to differentiate them!
@@w01dnick well yeah, that's why I said the input type parameters should also be written in angle brackets! Because "FindType" is just how the syntax works, making that "FindType(Inner)" specifically in type functions would be illogical… but if you instead write "type function FindType {" above, it's consistent internally AND with the existing notation!
I was excited when I thought this might enable passing generics without arguments to other generic to use within. I don't really like the if/else chain either, but to each their own there. I think TypeScript would benefit from a terse pattern matching syntax.
@Typed-Rocks Well yeah but you see, even in that case, .d.ts types get treated in a different way and should never be used for actual types in your codebase.
Can you also fix the “this ridiculously complex and nested object type has some minute error but I’m only going to show you the first 100 lines of the error which doesn’t show the actual error because it’s 200 lines”? Because that would be great 😂 I get the “type is not assignable to type ” but it’s just a wall of truncated red text 😢
just a note. writing Find or StringOrNever in typebuddy is somehow wrong. you should use normal brackets like Find(Inner) or StringOrNever(A) especially since that is how you define the type itself in your first line. makes no sense to use () there and then use later on. bad syntax. beside of that good idea
can this do anything other than if/else branches? variables maybe? switch statements would be cool. because avoiding ternaries by writing a whole meta language just feels like working around the problem instead of fixing it. i understand where youre coming from, ternaries were never meant to be chained a lot, so the problem lies mostly in the language design of typescript itself, tho in that position i would try to reconsider how i write my types, or better yet choose a language with a reasonable type system that wasnt hacked on another without one tbf i have the luck of not being a typescript developer, im sure there are valid reasons youre masochistic
Unfortunately I don't think we collectively as the web dev community can just "choose a different language", even if it WAS objectively better than JS/TS. That's sadly not how the ecosystem works anymore. And honestly, TS's type system isn't that bad, you can do some fancy things with it even if it's just if-else branches or foreach mappings. ...just unfortunately it can't do EVERYTHING you'd expect a proper type function syntax to allow you to do. Private type parameters would be kinda like variables, but they don't exist. Default type parameters are too inflexible currently to be used analogous to actual default function parameters. And I'm not even mentioning the many scenarios where one might accidentally say "regular functions can do THIS so type functions should too!" without realizing the domains are probably just too different to offer full parity or even interoperability! I feel like the only real solution for making type functions a thing is for the type system to implement them natively. Just call the user code as a blackbox to produce a type calculation… except I don't think the type checker's inference is that simple, so there may still be unexpected restrictions, or differences in how type functions are "executed". This seems like a NIGHTMARE level problem to solve in general, but damn would it be cool if someone did.
This is a minor and stupid nitpick, so feel free to ignore it, but can you add a space between the word "if" and the opening parenthesis? It's triggering my OCD lol
Wow This is an instant must have plugin. Thank you very much!
Glad you like it 😁
I've been wondering every time why there's no way to write types like normal functions, and here it is!
You are welcome 🤘. Let me know how if like it.
It looks like this just replaces ternary with if else. So it doesn't fully allow us to write types with functions.
@@EverRusting yes, but if we will use it more and more it could improvements
This is the kind of type that Microsoft should have created in the beginning, but never did. I like TS but always hated that it can only use nested ternaries to express switch cases. At least with this type buddy, the syntax looks so much cleaner. Thank you so much! 😊
That means much to me 😁👍. Let me know what you think
2:26 I'd suggest you to consider "early returns" here as an option. This would make it even easier to understand. You don't really need to use "else" if given option doesn't pass the execution further (which is seemingly always the case here).
Could you give me an example using code? Then I can maybe implement it
@@Typed-Rocks
Yes, something like:
function Find(A) {
if (A extends string | number | boolean) {
return StringOrNever;
}
if (A extends Array) {
return Find;
}
if (A extends Date) {
return object;
}
return never;
}
function StringOrNever (T) {
if (T extends string) {
return string;
}
return never;
}
Or even more simplified version (however i doubt it withstand more sophisticated cases):
function Find(A) {
if (A extends string | number | boolean) return StringOrNever;
if (A extends Array) return Find;
if (A extends Date) return object;
return never;
}
function StringOrNever (T) {
if (T extends string) return string;
return never;
}
@@The14Some1 I prefer the term Guard Clause instead of early return but yeah, I had the exact same suggestion, you were simply quicker. :)
God bless you for this man, would really aid my creativity when solving type problems
Glad you like it 👍😁
Definitely a great spell for ts wizard 😂
really like the idea. maybe typescript team can add a new keyword "typefunction" which dev can write a type function.
typefunction Maybe(T) { if (T extends string) return string; else return T; }
That would be awesome.
Is there a scenario in TS rn where it makes sense to write "type function"? because if not, it seems like a cool idea to just make that a "composite" keyword as it is in this "proposal". It'd fit right in and make so much sense!
i think it should be official feature. ternary ops is disgusting.
I also think to support a different way of writing types would be nice 🤘
That’s why I like zig meta programming
Interesting. I have to look into it. Looks cool
This looks amazing!!
Thanks man. Looking forward for your feedback👍
What a hidden gem this is. Thank you
Glad you like it :)
Buds, can we all agree thats should work in .ts files without any IDE extensions? I'm thinking of a babel plugin to do it in the background, what do u think?
Amazing thing, a suggestion though, can we write it like this instead:
functype Find {}
That way it’s more consistant between the definition and the call, and is compatible with the current TypeScript syntax.
And can you make a proposal to the TypeScript team to add such a feature to the TypeScript itself?
I don‘t think that the team will approve of it, as it‘s a huge change to the current state. Because of the functype, currently this would stop proper syntax highlighting. But I will look into it
I would even pay to have this plugin for Webstorm too.
I will try my best to create it 🤘
You are a god, thank a lot!
Glad you like it 🤘👍
This is actually a great idea. Will try the web version after my holiday vacation.
Question: would it be possible for you to abstract the "infer" syntax with something of your own? Like "getInnerType" or something. I see people always having problems with the "extends" in combination with "infer" all the time.
Let me know what you think about the web version. Currently I‘m not planning in adding „own“ syntax to the functional style as it makes it really hard to have proper syntax highlighting etc
wow, this seems really nice!
Thank you. Let me know how you like it when you‘ve tried it :)
In my case I don't use nesting like that, but instead I use () brackets to group types. While it does not change anything meaningful, it make it readable to me.
Some illogical step, that you define type as function, but use it still with angle brackets, not like function call.
Having regular runtime functions use parens for their value parameters, and type functions use angle brackets for their type parameters? that's actually such a good way to differentiate them!
@@ilonachan he uses parentheses for type function in declaration but angle brackets in recursive return. That part is illogical
@@ilonachan
function FindType(A)
but
return FindType
Using
return FindType(Inner)
Would be more consistent.
@@w01dnick well yeah, that's why I said the input type parameters should also be written in angle brackets! Because "FindType" is just how the syntax works, making that "FindType(Inner)" specifically in type functions would be illogical… but if you instead write "type function FindType {" above, it's consistent internally AND with the existing notation!
I will think about changing it 👍
I was excited when I thought this might enable passing generics without arguments to other generic to use within. I don't really like the if/else chain either, but to each their own there.
I think TypeScript would benefit from a terse pattern matching syntax.
I suggested author to replace if/else chain with early returns, which seems always possible to apply to the logic of ternaries.
The outfile should probably be .ts not .d.ts
I wanted that it only contains types. Because from the typebuddy file, only types get generated.
@Typed-Rocks Well yeah but you see, even in that case, .d.ts types get treated in a different way and should never be used for actual types in your codebase.
Can you also fix the “this ridiculously complex and nested object type has some minute error but I’m only going to show you the first 100 lines of the error which doesn’t show the actual error because it’s 200 lines”? Because that would be great 😂
I get the “type is not assignable to type ” but it’s just a wall of truncated red text 😢
I will look into it 😁
@ thanks! I think if anybody can solve it it’s you 😅
the VS Code extension "Pretty TypeScript Errors" might work for you
just a note. writing Find or StringOrNever in typebuddy is somehow wrong. you should use normal brackets like Find(Inner) or StringOrNever(A) especially since that is how you define the type itself in your first line. makes no sense to use () there and then use later on. bad syntax.
beside of that good idea
looks interesting, gotta give it a try
Let me know what you think 👍
can this do anything other than if/else branches? variables maybe? switch statements would be cool.
because avoiding ternaries by writing a whole meta language just feels like working around the problem instead of fixing it.
i understand where youre coming from, ternaries were never meant to be chained a lot, so the problem lies mostly in the language design of typescript itself, tho in that position i would try to reconsider how i write my types, or better yet choose a language with a reasonable type system that wasnt hacked on another without one
tbf i have the luck of not being a typescript developer, im sure there are valid reasons youre masochistic
Currently it only allows if else as its really hard to do anything else
Unfortunately I don't think we collectively as the web dev community can just "choose a different language", even if it WAS objectively better than JS/TS. That's sadly not how the ecosystem works anymore. And honestly, TS's type system isn't that bad, you can do some fancy things with it even if it's just if-else branches or foreach mappings.
...just unfortunately it can't do EVERYTHING you'd expect a proper type function syntax to allow you to do. Private type parameters would be kinda like variables, but they don't exist. Default type parameters are too inflexible currently to be used analogous to actual default function parameters. And I'm not even mentioning the many scenarios where one might accidentally say "regular functions can do THIS so type functions should too!" without realizing the domains are probably just too different to offer full parity or even interoperability!
I feel like the only real solution for making type functions a thing is for the type system to implement them natively. Just call the user code as a blackbox to produce a type calculation… except I don't think the type checker's inference is that simple, so there may still be unexpected restrictions, or differences in how type functions are "executed". This seems like a NIGHTMARE level problem to solve in general, but damn would it be cool if someone did.
I think creating d.ts is not ideal since d.ts types are global
I will think about it 👍
This is a minor and stupid nitpick, so feel free to ignore it, but can you add a space between the word "if" and the opening parenthesis? It's triggering my OCD lol
Will add highest priority to fix that 😁
It's done. you can update extension :)
Amazing
Thanks. Really appreciate it 🤘🙏
Great plugin! Thanks.
Would it be possible to remove de "tb" from the .d.ts filename?
Like typebuddy.tb -> typebuddy.d.ts
I will make it configurable :)