New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Homogenise null and undefined typings within djs APIs #9829
Comments
👎 Most of those type choices are deliberate, especially when it comes to patching data. I suppose there are cases and structures where this isn't necessarily a problem, but I feel like all things considered, it'd be a downgrade to change it in specific areas and cause an inconsistency all together. |
I know that and completely agree, but i don't think that (generally speaking from the patterns i could see) returning The single source of truth with the deliberate choices you are talking about could still be the docs or dapi-types, but the user-facing API could be polished by abstracting the null/undefined differences away. |
It's unclear to me how much we can improve this without compromising functionality regardless, but returning |
Which application or package is this feature request for?
discord.js
Feature
Often when using discord.js APIs together, types are incompatible because of undefined/null discrepancies. This is very irritating and hurts DX because you would expect that using discord.js APIs together would "just work" and would not require you to resort to hacks.
Examples
Probably many other ones. Those were just examples, the main problem is that for class properties
| null
is mainly used, but for option objectsprop?: type
is mainly used, which makes itundefined | type
.This is a problem because it results in a Typescript compiler error.
Ideal solution or implementation
The easiest option would be to have all Options objects with optional properties to also accept nulls, which afaict wouldn't be breaking (?) because you don't explicitly check for undefined values.
I haven't looked in other places, but at least accepting nulls in option objects would probably remove 95% of the problems (or of the common problems) faced by djs users.
Alternative solutions or implementations
You could also just ignore this problem as it is easily fixable by asserting not-null (
!
) to make Typescript happy, or by adding?? undefined
which would also fix the problem by making Typescript happy with a solution that makes it through runtime and not just compile time.Other context
Debates over the use of null / undefined:
Utilities from Sapphire to handle both undefined/null together (aka Nullish) :
isNullish
andNullish type alias
The text was updated successfully, but these errors were encountered: