Conversation
| ): Promise<any> { | ||
| const headers: IncomingHttpHeaders = {}; | ||
| if (this.options.token) headers["authorization"] = this.options.token; | ||
| if (this.options.token) headers["authorization"] = `Bearer ${this.options.token}`; |
There was a problem hiding this comment.
Would also change the current v0 implementation
There was a problem hiding this comment.
Oh v0 does not work with Bearer tokens? Damn
There was a problem hiding this comment.
Honestly, I don't remember. My bad. Resolved.
…ror to APIError, and describe weight property
|
Full diff between this and the commit prior to #91: 24a2ee1...null8626:node-sdk:master Tested with |
|
Not sure I agree with the concept of a separate class to denote a changing of versions. Either we should fit methods into the old class definition or we bump a major version. |
|
Veld explicitly proposed that newer endpoints use a separate Not only that, this is also supported by the fact that the |
|
@velddev mind weighing in on this? What's the aversion to a breaking major version bump? "Missing an update" doesn't really matter if things aren't changed to not break. E.g. most of the old methods still use the v0 endpoints, so if v0 gets shut off it won't matter if people updated to the new package version or not. I don't see any advantage for shying away from a breaking version here, and seems to break the line between service and library to change how the client is interacted with for an API change. |
|
The goal of these changes is to build the foundation for the v1 API. The legacy API is finished. Any change we introduce shouldn't cause users who use the v0 API to have to change their code and make the experience adding new functionality more cumbersome. A breaking change would dictate that we edit the current schema, and as long as the current API does not do that, we will not need to do this to the end user. What we instead should do is have a new client which is built for the v0 API so that the end user can gradually adopt new features without the weight of having to migrate their current code to a new arbitrary refactored client version. |
|
An example: how many times have you had to change your code because a library did a breaking change? Was it a good experience having to do that? Now imagine that the breaking change does not give you any benefits. Refactoring for the sake of it, while great for our code maintainability, is selfish towards the end user since every hour that is spent on refactoring, every user of the library will spend an equal amount of time figuring out how to fix their code |
|
I think the disconnect comes from the fact that we're transitioning to a V1 API without it being able to expose the same functionality as V0. I imagine this will add more refactoring for users than not. But if the V1 isn't going to able to do what V0 does then it is what it is. |
| * ```js | ||
| * // Discord.js: | ||
| * const commands = (await bot.application.commands.fetch()).map(cmd => cmd.toJSON()); | ||
| * | ||
| * // Eris: | ||
| * const commands = await bot.getCommands(); | ||
| * | ||
| * // Discordeno: | ||
| * import { getApplicationCommands } from "discordeno"; | ||
| * | ||
| * const commands = await getApplicationCommands(bot); |
velddev
left a comment
velddev
left a comment
There was a problem hiding this comment.
Assuming based on the PR, the two clients are split. LGTM.
src/utils/ApiError.ts
Outdated
| /** Possible response from Request */ | ||
| public response?: Dispatcher.ResponseData; | ||
| constructor(code: number, text: string, response: Dispatcher.ResponseData) { | ||
| export default class APIError extends Error { |
There was a problem hiding this comment.
pretty sure this would be a breaking change
There was a problem hiding this comment.
The response object is still missing, it's an accessible field
|
All functions related to API v0 are deleted. This pull request is now for version |
3 participants
The following pull request adapts the SDK to API v1.