technologiestiftung/giessdenkiez-de

How to type function signatures

ff6347 opened this issue · 8 comments

I'd like to ask a question/start a discussion about typing functions.
I saw that you (@vogelino) tend to write signatures like this:

const setVisibleMapLayer = (
  type: StoreProps['visibleMapLayer']
): { visibleMapLayer: StoreProps['visibleMapLayer'] } => {
  return {
    visibleMapLayer: type,
  };
};

const setVisibleMapLayer = (

Where I like to write them like this:

const setVisibleMapLayer: (
  type: StoreProps['visibleMapLayer']
) => { visibleMapLayer: StoreProps['visibleMapLayer'] } = (type) => {
  return {
    visibleMapLayer: type,
  };
};

Why do I prefer the one over the other?

If I would have to share this function signature with another function I just could do extract it by copying it into a type and I'm done.

type SetterFunc =  (
  type: StoreProps['visibleMapLayer']
) => { visibleMapLayer: StoreProps['visibleMapLayer'] };

const setVisibleMapLayer: SetterFunc= (type) => {
  return {
    visibleMapLayer: type,
  };
};

In your way of typing it the description of the types and the implementation are tightly coupled. Any reason why you write it your way?


Another thing I do often is use the function keyword on top level functions.

function(a: number): number {
return a;
}

So my rule is to only use const thing = () … if I'm in a closure and use function in the global scope. Any reason why you don't use function at all?

@lucasoeth @dnsos I'd also like to hear your opinion about this.

Signature typing

I think that both ways are valid but I prefer the tightly coupled way because:

  1. It doesn't contain the => twice, making the readability better (we avoid confusing the signature for the real function)
  2. It shares the way of typing it with functions written with the function keyword

If you wish to share signatures between multiple functions, prefer using a type. That makes its reusability explicit:

type ClickHandleSignature = (id: string) => void

const onClickHandler: ClickHandlerSignature = (id) => {
  // ...
}

I prefer not to makes things generic until really necessary. It is way simpler to refactor.

Function keyword

I don't use the function keyword in most cases for a few reasons:

  1. It is less verbose and can return without a return keyword, making it easy to write composable on-liners
  2. It makes it explicit that the this keyword isn't used here. You don't even think about it. Wit a function that has a function keyword, you never know.

It doesn't contain the => twice, making the readability better (we avoid confusing the signature for the real function)

Funny I find your way harder to digest then the one I prefer. :)

If you wish to share signatures between multiple functions, prefer using a type. That makes its reusability explicit:

That's what I said. :)

I prefer not to makes things generic until really necessary. It is way simpler to refactor.

Me too. But if I have to my way is faster 🚀

Funny I find your way harder to digest than the one I prefer. :)

Common, could we not talk about your way/ my way? An can you elaborate on why do you think it is easier to digest?

That's what I said. :)

Your suggestion included the signature as a prefix to the parameters, which as I said, has to risk to make the readability of the function more difficult as it contains two =>. The developer has to first identify which is the signature and which is the function declaration.

In my suggestion, the signature is external to the function declaration. I would only use that in the case it really is used multiple time.

Me too. But if I have to my way is faster 🚀

Coding with speed is only good if it doesn't compromise the readability of the code. But sure, you might save some milliseconds.

Let's move that to discussions.

Let's keep on in #297