lukemorales
commented
1 year ago @Kamahl19 I guess this is a more subjective topic than an objective one. Even in the discussion you've shared, there are a lot of arguments for both sides. I've also worked on some codebases that used the unicorn plugin and disabled many of the proposed rules (and that happens with almost every ESLint plugin), so it's pretty hard to make decisions based on someone's opinion.
MDN's definition of null says:
The null value represents the intentional absence of any object value. It is one of JavaScript's primitive values and is treated as falsy for boolean operations.
Which is exactly the point of declaring null when you don't want a queryKey to add properties to the inferred value: we are saying "this value exists, but it's empty". That's why I implemented with null and not undefined.
The reason an empty array [] was not used, is because the type system inference would suffer from it and it would become more complex to handle allowed values for queryKeys (all arrays are tuples in order to be able to infer the values inside each index ~ [string, number, string] vs (string | number)[] ~ so, if we pass an empty array, there's a conflict where Typescript might think you're missing at least one value in order for the value to be the expected tuple).
Every decision comes with a tradeoff, I think it's less burden to disable an ESLint rule for a specific file than to have to refactor the type system
Kamahl19
Many projects use sindresorhus's eslint-plugin-unicorn. It's recommended config includes the no-null rule. Here is the reasoning behind not using null 1, 2, 3.
I suppose it would make sense to replace it with an empty array
[].