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
refactor: new node features #5132
Conversation
actually, these methods should return
fixed
can you leave review comments on these lines? because the links you provided don't take me to them
i think every structure has |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks mostly fine, only nit I would have is that you switched some for loops where you set into a collection to .reduce
but left others intact. Should decide on one pattern over the other, but not mix-match so much.
ill switch for loops to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can also replace all EventEmitter#removeListener
with the newer EventEmitter#off
, since we use EventEmitter#on
over EventEmitter#addListener
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can also replace all EventEmitter#removeListener
with the newer EventEmitter#off
, since we use EventEmitter#on
over EventEmitter#addListener
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are many cases where Array#reduce was used to fill an array of the same size, Array#map should be used instead.
I also found a lot of inconsistencies from existing code (not from this PR) regarding permissions:
In most cases, we assume permissionsFor(this.client.user)
will always return a non-null value, which it indeed will, more than 99.99% of cases (when the GUILD intent is used (which discord.js needs to operate), Discord always sends the client's member, as such, guild.me
is always available, even without the members or the presence intents).
The only case at which it can be null, is when a user sweeps discord.js's caches to save memory, (a practice that was discouraged, but was quite common regardless) but did not account for re-adding guild.me
back, which lack breaks most of the library.
We need to consolidate this and decide what should we do in this regard, since in regular conditions this code will always work, it's the user's interference in discord.js's cache what makes it break.
Returning (not null
, but undefined
) in the getters is something I don't really agree with, and should be discussed.
dfc885e
to
4633bda
Compare
its already being used there |
8c3085f
to
57a340d
Compare
This needs a rebase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#5132 (comment) and #5132 (comment), not to mention that, and you won't believe it, this needs another rebase
reeeebased |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small thing, otherwise LGTM
Co-authored-by: Antonio Román <kyradiscord@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Three tiny nits left, otherwise LGTM.
Please describe the changes this PR makes and why it should be merged:
This PR makes use of optional chaining and the nullish coalescing operator in various places, added in node v14,
aswell as a couple logic changes to use
&&
instead of a tenary likex ? y : null
where x can be nullStatus
||
to??
may cause some unintended behaviourSemantic versioning classification: