export type LocationQueryValueRaw = LocationQueryValue | number | undefined
export type LocationQueryRaw = Record<
string | number,
LocationQueryValueRaw | LocationQueryValueRaw[]
As mentioned in other issues this is fine as in JS you would write !query.foo rather than query.foo === null. Or given the possibility of the query being a string, typeof x === ‘string’
I think that in future versions we might stop using a Record to introduce the possibility of query param to be undefined but right now that would technically be a breaking change
If a value can be undefined, then undefined should be in its type. The type of an expression should be the set of all values it can be. In this case, this is clearly not true. Code that type-checks should work, but this requires the types to be actually correct,
null being in the type is not sufficient. There is a clear semantic difference between null and undefined. This is demonstrated by null and undefined being outputted for different reasons in your code (undefined for the key not being in the query, null for the key being in the query but not being given a value).
If a type includes null and not undefined, then your code should check for null rather than null and undefined. This is because undefined being added to the type at a later date would mean that different logic could be required for handling the value. Therefore, you want the code to no longer type-check, as programmer inspection is required in order to determine whether the code handling the null case can also handle the undefined case or if a new case should be added.
This would be a breaking change, as a developer's code would no longer type-check if it did not handle the undefined case. This is a good thing, since this code would not be safe.
