fix(guildChannel): better channel editing #11072
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
| ); | ||
| } | ||
|
|
||
| if (snakeCaseBody.default_reaction_emoji?.id) { |
There was a problem hiding this comment.
Any reason for checking id specifically here? Passing name wouldn't work this way.
| if (snakeCaseBody.default_reaction_emoji?.id) { | |
| if (snakeCaseBody.default_reaction_emoji) { |
If there is a reason for the id check then we must also check for name.
There was a problem hiding this comment.
sorry, I could be completely off base here since I haven't read everything/the types, but wouldn't your diff cause trouble if {} was passed?
There was a problem hiding this comment.
good callout, I forgot emoji's can be name only. I'll add || name to it.
and @didinele no, {} would pass through in the body. Though speaking of types, I didn't add a | RESTPatchAPIChannelJSONBody to the types for this method, but I theoretically could at this point....should I?
There was a problem hiding this comment.
Is that the direction we foresee the discord.js library going in (i.e., allowing passing raw payloads everywhere appropriate)?
There was a problem hiding this comment.
I think we should allow it (to better support new features that don't have real support yet), but I don't know that we should actually document it that way. It might be something we mention somewhere once, but I don't think we should specifically call it out except maybe types...my opinion will probably change once the lib is actually ts native and the underlying support for raw data is way better.
github-project-automation
bot
moved this from Review Approved
to Review in Progress
in discord.js
ckohen
force-pushed
the
refactor/channel-edit
branch
from
ce45fd2 to
077462f
Compare
| toSnakeCase(options), | ||
| ); | ||
|
|
||
| // This overwrites a passed snake_case version if a camelCase version OR `parent` is passed |
There was a problem hiding this comment.
BTW, seems that in toSnakeCase(), if there are conflicting keys, the last one (by key order) takes precedence. i.e., if both snake case and camel case versions of a key are passed, the later one overwrites the earlier.
This won't be the case for these ones, where camel case will take precedence. Not sure if we should do something about it (maybe tweaking toSnakeCase to prefer the camel case version?..) or just let it be
There was a problem hiding this comment.
I think I had set a precedent somewhere to prefer camel case when passsed which is why I did it this way.
I'm not exactly sure if I want to change that function in this PR, but I think it would make sense to because it would be more deterministic that way.
7 participants
Please describe the changes this PR makes and why it should be merged:
Changes how channel edits are handled to allow sublimits to be handled properly within /rest.
Byproduct is channel editing is much more robust, allows raw api data, and can edit uncached channels now.
Supercedes #11000
Status and versioning classification: