-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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(attachment): don't return attachment builders from API #7852
refactor(attachment): don't return attachment builders from API #7852
Conversation
6fb2d85
to
a3592fb
Compare
There is already a similar pr #7813 |
This one is much more consistent with the current approach to builders and internally constructed classes. |
Should probably fix that then instead of completely ignoring the other guy's work and opening something on top of it... |
These PR's have some overlap but are mostly two different approaches to this. This doesn't modify /builders code while the other does, this only makes changes to discord.js code. And in addition, makes the API only return immutable attachment objects. |
So now we’re creating a builder in djs and not in the package that is literally called builders. Great! Inconsistencies! |
While I can understand why you'd think that, unlike other builders (components, embeds, commands), attachments are heavily implementation based and cannot be easily made agnostic due to their nature ( what would we be supporting? a Buffer/Blob? raw Uint8Arrays/ArrayBuffers? reading from the file system? all of the above?) and I for one don't see how we could create an agnostic builder. (btw, right now builders work on web too if you ever thought of using it, I'm sure someone has a use case for that 😄) Hope that clarifies it. If not, you can ask me on Discord. |
Co-authored-by: Almeida <almeidx@pm.me>
6bd2c44
to
1e187d3
Compare
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.
Actually, I noticed this bug. LGTM otherwise.
Co-authored-by: A. Román <kyradiscord@gmail.com>
Co-authored-by: SpaceEEC <spaceeec@yahoo.com>
87bf558
to
d9a58f9
Compare
Co-authored-by: SpaceEEC <spaceeec@yahoo.com>
d9a58f9
to
1b0c6fa
Compare
…ordjs#7852) Co-authored-by: Almeida <almeidx@pm.me> Co-authored-by: A. Román <kyradiscord@gmail.com> Co-authored-by: SpaceEEC <spaceeec@yahoo.com>
Please describe the changes this PR makes and why it should be merged:
This PR creates a seperate structure for attachments returned by the API. The builder structure has been renamed to
AttachmentBuilder
Status and versioning classification: