Open mcmire opened 11 months ago
Edge case for consideration:
The const F: (arg: T) => U
syntax for typing functions is only supported by const
function declarations, and it can be used for conveniently defining and typing higher-order constructs e.g.
const printCoordinates: (x: number) => (y: number) => `(${string}, ${string})`
= (x) => (y) => `(${x}, ${y})`;
console.log(printCoordinates(1)(-1));
// "(1, -1)"
If we stick to the function
keyword for this, the type annotations become a lot more spread apart and redundant.
function printCoordinates(x: number): (y: number) => `(${string}, ${string})` {
return function printCoordinatesForGivenX(y: number): `(${string}, ${string})` {
return `(${x}, ${y})`
}
}
But for most cases I agree with preferring the function
keyword for the same reasons given in the post.
I'm assuming the rule won't be applied for things like props, or functions passed in objects? For example if a function has an argument that is an object, and one of those keys can be a function should we be enforcing declaration of the function outside the object?
callSiteExample({
prop1: 'foo',
prop2: () => console.log('bar'),
})
versus
function prop2() {
console.log('bar');
}
callSiteExample({ prop1: 'foo', prop2 });
There's definitely some cleanliness to the second example, just curious what your thoughts are here.
@MajorLift Ah yes, thanks for mentioning that edge case. It would make sense that we'd use const
in that case.
@brad-decker Good point! Yes, my thinking was that this rule would only apply to function declarations and not function expressions. I guess a function defined via const
is a function expression, though. So perhaps this rule would be difficult to enforce fully. But to answer your question directly, no, I think we wouldn't need to enforce this rule for functions created on the fly like in your example.
There are two ways to declare functions:
I propose that we add a rule which enforces that declared functions use the first style rather the second. There are a couple of issues with using an arrow function that I think
function
solves:function
pops out more visually.=>
is a bit overloaded, as it's used to indicate the return value for a function type in TypeScript. When usingfunction
, however, you don't have to deal with the ambiguity of=>
nor do you have extra characters in the way.:
always separates the arguments from the return value, and the return value always goes before the{
.There are also some benefits for using
function
:function
functions are JSDoc'd, whereas we don't do that forconst
functions. We could certainly add another rule, but it would be nice if we didn't have to.function
functions are hoisted; when defined at the top level, this means they are automatically available anywhere in the file no matter where they're defined. This comes in handy when writing tests. If you want to define test helpers for tests, you can put them below thedescribe
to hide them, thereby makingdescribe
the first thing that readers see when reading the file.