Repository navigation
Describe function signature using an interface #34319
Description
Activity
This also allows developers to define interfaces to design functions, without implementing them (meaning no empty un-implemented function blocks).
The developer could then use interfaces within tests or code before the implementation is available.
Right now I am defining interfaces and functions separately (but with same constraints), letting me design the constraints and having one of our developers who is new to typescript (and javascript) fill in the implementation. The implementation is then passed to a test that accepts a function with the interface's signature.
function name(first, second) implements Interface {}seems natural as well, and not jarring (maybe it is to some? Is there an alternative?), and also aligns with the usage withclassUsing this pattern also means the argument types or return type doesn't need to be defined, as the interface has already done this (this wasn't mentioned in the above issue, but is in the example)
I do have a concern though that
implementsmight not be the correct term here, but it also seems right.
An example of type gymnastics being resolved:
Function type interface:
interface SearchFunc { (source: string, subString: string): boolean; }
Current:
let mySearch: SearchFunc; mySearch = function(source: string, subString: string) { let result = source.search(subString); return result > -1; }
Proposed:
function mySearch(source, subString) implements SearchFunc { let result = source.search(subString); return result > -1; }
Current Source: https://www.typescriptlang.org/docs/handbook/izterfaces.html#function-types
This would also allow this pattern:
interface Dispatcher<T> { (value: T): boolean; } function dispatch<T>(value: T, fn?: Dispatcher<T>) implements Dispatcher<T> { if (fn) { return fn(value); } // Do something default return false; }
The alternative would be duplicating the types:
function dispatch<T>(value: T, fn?: Dispatcher<T>): boolean { if (fn) { return fn(value); } // Do something default return false; }
It may not be significant, but it reduces the surface area of where types are defined (e.g. I can change the return type on the interface and it would also change the return type of the function), which in my opinion is a bonus. In the example I have just used
boolean, but the return type could be a lot more involved (e.g. when we get into some complicated generics)This sneaked into this comment's examples as well, but any arguments not defined in the argument list of the interface would need to be optional, else the function couldn't match the defined interface, the alternative would be not to allow additional arguments, but this is avoidable
Regardless of the syntax (which I think is quite OK), it solves the problem of not being able to make function declarations implement anything, so now I have to write
const MyTemplate: Template<Prop> = (props) => ...One thing to bear in mind is that the type of the arguments can only be optional if the interface/interfaces declare one call signature. I think it's reasonable the function implements on or more interfaces without call signatures. With multiple call signatures, it becomes an overloaded function and should declare compatible arguments (which I believe is the current rule for implementing overloaded functions) .
Another issue is the hoisting and TDZ for the properties/methods. It would be great if we could preserve the current behaviour.
interface Something { value: number; } something.value; // should be illegal something.value = 42; // should be OK something.value; // should be OK function something() implements Something {}
Reacted by Fabian Cook, Chase Moskal, Brian Mortenson, Dimitris Karagiannis, Brian Stein, andrey and Applesto make function declarations implement anything
That is a great point, you aren't able to provide their complete type ahead of time using current syntax because you cannot define properties.
TypeScript is then maybe breaking the goal of
Preserve runtime behavior of all JavaScript code.without something similar to thisAs with your example, it would work the same as let:
let value: number; console.log(value); // should be illegal value = 42; // should be OK console.log(value); // should be OK
This could help me implement function property (like here https://www.bennadel.com/blog/3250-defining-functions-with-properties-using-typescript-declaration-merging-in-angular-2-4-9.htm) when using React.FunctionComponent.
Did this functionality ever get added to typescript? Or is there some kind of work around? I couldn't tell if there was a conclusion that was reached on this topic.
I came across this problem back a while ago and after a little research I found this thread.
I want to add that, this issue is super important when it comes to typing React components that have a generic type. because in that situation, there is no way to type the component using the arrow function + React.FC interface:const MyComponent: FC<Props<T>> = <T>(props) => { ... }
(in the above example, we don't have access to the function generic type at the point of declaring the MyComponent Type so the
FC<Props<T>>errors)So we have to use the function form, but by doing that, we won't be able to use the
FCinterface anymore so we have to do this:function <T>MyComponent(props: Parameters<FC<Props<T>>>[0]): ReturnType<FC<Props<T>>> { ... }
It isn't that beautiful, but it wouldn't matter if it worked. even with this syntax, we won't get proper type check for things like
Component.propTypesandComponent.defaultProps. So we also have to add the definitions manually for each one of them (we can't use the alias declaration trick in this case because that way there is no way to get the generic type).So after all, it would be great if typescript had first-class support for this kind of situation. I'd love to be able to do something like this:
function <T>MyComponent(props) implements FC<Props<T>> { ... }
Reacted by Ehsan Titish, Nerixyz, Jacob Weisenburger, Fabian Cook, AS, Jeff Bowman, FUJI Goro, tracy, Luka Maljic, Russell Dempsey and 9 moreis there some kind of work around for until this feature gets implemented?
Reacted by Jacob Weisenburger, Alex Arro and andreyRyan Cavanaugh (@RyanCavanaugh) any status update on this one?
Reacted by SancheZz, NahejL, Edward Banfa, Alex Arro, Jacob Weisenburger, Fujita Hitoshi, andrey, Apples and Jorge LuisReacted by Jacob WeisenburgerReacted by Jacob WeisenburgerReacted by Jacob WeisenburgerReacted by Jacob Weisenburger and Alex ArroRyan Cavanaugh (@RyanCavanaugh) Can we get something like this?
Hey folks, we've got a few thousand open suggestions to manage, and pings for "updates" are no-ops because we'll always post updates in-thread. Thanks!
Reacted by AlCalzone, Fabian Cook, Russell Dempsey, Jeremy Gollehon, Alex Arro, Fujita Hitoshi, Michael Landis, andrey, falfia falfiya, Alex Rattray and 3 moreIn addition to the above given syntax, if we completely forgot about the
classsyntax existing, and only utilisedfunction+implements, then gave a type forprototypeby utilisingnew:interface CoolPrototype { foo(): boolean } interface CoolConstructor { new (): CoolPrototype (): CoolPrototype } function coolConstructor() implements CoolConstructor { if (!(this instanceof coolConstructor)) return new coolConstructor() return this } coolConstructor.prototype = { foo() { return true } }
By dropping the TypeScript stuff, this works as I would expect, matching the types defined...
I originally mentioned the property to be optional, but by having it required, the type checker would/could need to see if there is assignment to that property (what happens if I wanted to do
this.foo = () => trueinstead?)Here is also a playground link with how you can achieve the same (constructor + normal function) with a type, with usage of
asin thereThis would also allow us to do to this...
let cached: CoolPrototype function coolConstructor() implements CoolConstructor { if (cached) return cached if (!(this instanceof coolConstructor)) return new coolConstructor(...arguments) cached = this return this } coolConstructor.prototype = { foo() { return true } } console.log(coolConstructor() === coolConstructor()) console.log(coolConstructor() === new coolConstructor())
Of course we could just remember the
classsyntax exists and instead use it, but, this could allowinterface+implementsto be written for code bases currently using this style of functionIt is so frustrating to me that I can define an interface for a function, and then it not get enforced. Doesn't that completely defeat the point of an interface? If I can just assign anything to a function with an interface, I might as well not have the interface at all.
Reacted by Ian Hunter
Search Terms
function implements interface
Suggestion
Allow functions to indicate interfaces that they implement, allowing usage of a function interface.
Properties defined on an interface would not be possible unless they are defined as optional
Use Cases
When using function overloads, the return type is defined as
any, this would allow the return type to be guarded and not useany. Referencing: https://www.typescriptlang.org/docs/handbook/functions.html#overloadsIt would also allow optional properties to be defined on a function without doing type gymnastics.
Examples
Checklist
My suggestion meets these guidelines: