Reconsider enforing arrow functions everywhere

[spike-rabbit]

We currently have https://www.npmjs.com/package/eslint-plugin-prefer-arrow configured which enforces the use of arrow functions everywhere. (This rule also appears to be unmaintained)

Enforcing this for anonymous functions and in cases where this is used makes sense as this avoids potential errors.

But in all other cases it is pointless and potentially even worsens code quality. See https://github.com/siemens/ngx-datatable/pull/283/files for the impact on the datatable.

There is an alternative eslint-rule available that covers the relevant cases mentioned above: https://eslint.org/docs/latest/rules/prefer-arrow-callback .

We should switch to this rule.

Any options?

[Killusions]

There are some reasons for this, first of all in most cases the behavior of arrow functions is more straightforward, especially when this is accessed, see: https://dmitripavlutin.com/differences-between-arrow-and-regular-functions/

But the main reason AFAIK is that we can bind it to a const, better preventing name conflicts or reassignments (yes I'm aware we have TS but this also makes it safer at runtime).

[kfenner]

@spike-rabbit Well, we completely switched our codebase to const funX => { }; as we previously had the classic js/ts style functions without const variables. Just from a style/readability perspective, I preferred the classic function definitions. However, I see some value in consistency and the arrow functions have some technical advantages, so I was fine with the change. I really doubt that we should now reverse this (partially).

[spike-rabbit]

This is not about reversing but just re-allow the function style.

As in my opinion readability is quite important and the only relevant technical aspect is the reassignment.
In other cases where the technical advantage are needed, we would still enforce arrows.

I don't like refactoring the datatable with no technical advantage in the relevant location but with decreasing readability.