Suggestion: Type annotations and interfaces for function declarations

[mbrowne]

Currently in TypeScript, function declarations cannot be typed in the same way as function expressions, e.g. this function can implement the React.FC interface:

interface TestProps {
    message: string
}

const Test: React.FC<TestProps> = ({ message }) => {
    return <div>{message}</div>
}

But this function can't, at least not directly:

function Test({ message }: TestProps) {
    return <div>{message}</div>
}

This becomes more of an issue if you try to add properties to the function object:

Test.defaultProps = {
    message: 'hi'
}

It seems that currently the only way to specify the type for the function object in the second example is to create a new variable:

const AliasForTest: React.FC<TestProps> = Test
AliasForTest.defaultProps = {
    message: 'hi'
}

This seems like kind of an ugly workaround, so it seems that the current idiom is to just prefer arrow functions for cases like this. But this leads to inconsistency on teams that generally prefer function declarations over const expressions for top-level functions. Personally I find it more readable to see the word "function" for top-level functions rather than seeing "const", which is generally already all over the place in the code. There is even an ESLint rule for teams that share my preference (although I don't think it's been ported to TSLint yet): https://eslint.org/docs/rules/func-style. In any case, I have seen others express similar views and other codebases (including some from Facebook and Apollo, for example) that still prefer the "function" keyword for top-level functions.

However, stylistically it's also a problem if top-level functions are declared some places as declarations (using function) and in other places as expressions (using const). But for those who desire consistency, TypeScript is basically forcing the use of expressions, due to the issues described above.

This is far from being a top priority of course, but I was surprised to see that TypeScript didn't provide some equivalent typing syntax for function declarations. It would be great if this could be considered for a future version (even if far in the future). Thanks for reading!

[michaeljota]

I just was thinking about this. I would like to make a proposal to type functions declarations, by adding to the function keyword a generic param that can shape the function.

function<T extends (...V): R> // Maybe something like this

To be used like this:

function<ActionReducer<State>> reducer (state, action) {
  state // Type infers to State.
  action // Type infers to Action, as is its default value.
  return // Type infers to State.
}

Variadic types are currently being tracked at #5453, but maybe this isn't need for this to work, and this can be implemented somehow with the current union types, or the same way interfaces like this are being currently declared, but duplicating the amount of interfaces a having a any default to the nth interface.

---

Another proposal, should be supporting @type property of JSDocs. With this, we can be able to type functions.

/**
 * @type {ActionReducer<State, ActionType>}
 */
function reducer(state, action) {
  state // Type infers to State.
  action // Type infers to ActionType, as is its default value.
  return // Type infers to State.
}

[mbrowne]

Just curious if anyone on the TypeScript team is interested in working on this feature for some later release of 3.x? Where would this fit into the roadmap?

[rmolinamir]

Something like this would be amazing:

async function user: Resolvers.TQueryUser (_, { id }, context) {
  const user = await context.prisma.users.findOne({ where: { id: +id } });
  return user;  
}

My current alternative is to do:

const user: Resolvers.TQueryUser = async function user(_, { id }, context) {
  const user = await context.prisma.users.findOne({ where: { id: +id } });
  return user;  
}

But unfortunately, I wouldn't be able to type them, in say, within objects. E.g.:

{
    user: user: Resolvers.TQueryUser = async function user(_, { id }, context) {
      const user = await context.prisma.users.findOne({ where: { id: +id } });
      return user;  
    }
  }

Or:

{
    user: async function user: Resolvers.TQueryUser (_, { id }, context) {
      const user = await context.prisma.users.findOne({ where: { id: +id } });
      return user;  
    }
  }

---

I could also do:

interface IUserResolverMap {
  // Queries
  Query: {
    user: Beast.TQueryUser
    users: Beast.TQueryUsers
    me: Beast.TQueryUser
  }
  // Mutations
  Mutation: {
    newUser: Beast.TMutationNewUser
    authenticate: Beast.TQueryAuthenticate
  }
}

const resolvers: IUserResolverMap = {
  Query: {
    async user(_, { id }, context) {
      const user = await context.prisma.users.findOne({ where: { id: +id } });
      return user;  
    }
  }
  ...
}

But then I would get this complaint (some might not depending on your ESLint):

Missing return type on function.eslint(@typescript-eslint/explicit-function-return-type)

[dradetsky]

I realize this issue has been around for some time, but I just wanted to say: I still want this. When new to typescript, I had originally tried to write e.g.

type MyFn = (a: number, b: string) => number
declare function h: MyFn
function h(a, b) {
    return a
}

and was very disappointed when I found out you couldn't do this.

I just want to add that I personally would be happy with a much less slick syntax than the other commenters seem to be proposing. For example declare function f: T would be just fine. In addition to the other benefits proposed by the other commenters, this can be a great way to make your code easier to read since when I see

function g(a: number, b: string): number {
    return a
}

I'm trying to read the names of the parameters and follow then throught the function body, and the less busy the signature line is, the easier this is. For example, when I see

let e: (a: number, b: string) => number
e = (a, b) => {
    a
}

(NOTE: This is not what I actually want to read or write)

I can mentally separate the process of determining the types from following the variable names throught the function body. Although it's not obvious in this contrived example, I often read code (especially difficult-to-understand code) by going back and forth visually between the argument list and the function body to try to figure out what's going on. And being able to look up the types of the argument names separately from referring to the names themselves makes this easier.

[bodinsamuel]

+1 on this

This is really the most painful thing on Typescript right now (because everything else is quite perfect <3)
Especially when dealing with reusable express middleware, this is quickly getting out of hand, even a basic function declaration takes > 5 lines.
I would love some comments from maintainer (cc @RyanCavanaugh I know it's not on the roadmap for the moment)

// this simple js function
function myMiddleware(req, res, next);

// ... can become this monstrosity
function myMiddleware(
  req: express.request<
   MyParams, 
   MyBody
   MyQueries
  >, 
  res: express.response<MyBody>, 
  next: express.nextFunction
): Promise<void>;

Using const and anonymous function can "help" but you will reach 80colums quickly anyway, change the behavior (function and const has slight difference), and it still not as cool as having a proper way of doing it.

const middleware: Custom<MyParams, MyBody, MyQueries> = function(
  req, 
  res, 
  next
);

This could be something like this:

function: Custom<MyParams, MyBody, MyQueries> myMiddleware(req, res, next) ;

Note this is similar request as #39623

[ThaJay]

I agree with this issue. Function declarations are not the same as function expressions and arrow functions are not the same as normal functions. I would like to keep using function as the default and only use () => when this is required from the definition context like with callbacks fron instance.

In my opinion it makes the code a lot easier and faster to read because function doSomething (param) {} looks like one token plus name when skimming over the code and const doSomething = param => {} looks like 2 tokens plus name.

current form in TypeScript React:

const ComponentName: React.FC<{}> = props => {}

// would be sort of equivalent to:
function ComponentName (props: PropsWithChildren<{}>): React.ReactNode {
  this.propTypes: WeakValidationMap<P> = null
  this.contextTypes: ValidationMap<any> = undefined
  this.defaultProps: Partial<P> = undefined
  this.displayName: string = ''
}

So it would be really nice if we could do:

function ComponentName: React.FC<{}> (props) {}

What's so special about function vs var, let or const?

[chharvey]

If the function type annotation appears before the generic parameters, how will it be able to reference those parameters?

Say we have a generic function type:

type ProcessingFunction<DocT extends Document, DataT> = (doc: DocT, data: DataT) => void;

and we want to apply it to an instance:

function process<DType>(doc: Document, data: DType): void {
	...
}

This instance can be called with different generics:

process<{url: string, id: number, text: string}>(document, {url: '//example.com', id: 42, text: 'lorem ipsum…'});
process<{title: string, items: string[]}>(document, {title: 'Hello World', items: ['one', 'two']});

How would the function be annotated?

function: ProcessingFunction<Document, DType> process<DType>(doc: Document, data: DType): void {
//                                     ^ Error: Cannot find name 'DType'
	...
}

Note that as pointed out by someone else on Twitter, this problem already exists in the form of variable declaration:

let process: ProcessingFunction<Document, DType> = function <DType>(doc: Document, data: DType): void {
//                                        ^ Error: Cannot find name 'DType'
	...
};

But I guess my question still stands of if/how the issue will be addressed. It seems to me that this feature — annotating function declarations — should be able to handle generics.