Skip to content

fix: update API code to use Axios instances #13029

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

Merged
merged 7 commits into from
Apr 24, 2024
Merged

Conversation

Parkreiner
Copy link
Member

@Parkreiner Parkreiner commented Apr 22, 2024

Addresses part of #13013

Changes made

  • Updated all references to the global Axios instance to a new axiosInstance value
  • Updated the note about all the other codebases that we're importing the API file from

Notes

  • I still need to do some prodding to figure out the best way to improve test isolation for the Axios file. I'm 90% sure I'll have to refactor the file into a class, but there should be a way to abstract that detail away from anybody who isn't directly working with the api.ts file
    • This would be in a separate PR, though

@Parkreiner Parkreiner self-assigned this Apr 22, 2024
Copy link
Member Author

@Parkreiner Parkreiner Apr 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most of the file changes are here, but you can probably ignore everything past the first couple of lines. Main changes to the overall file:

  1. Updated the comment to list what exactly is importing the API file
  2. Updated all references for the global axios instance to coderAxiosInstance
  3. Exported coderAxiosInstance
  4. Updated some of the calls to axios.isAxiosError to just isAxiosError

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that coderAxiosInstance should never be exported or exposed. If we want to modify it, we should export custom functions for that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BrunoQuaresma it needs to be. The VS Code extension mutates it for request stuff.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is interesting, I would not expect to see other packages/projects accessing the api/api.ts directly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's ideal long-term. Replicate the codersdk in Go

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@code-asher Any preferences as for whether we have an optional throwOnError property that determines how the client resolves errors? I feel like it'd be good to default to false

Most of the time, I would like to do things the Go way, and expose the errors as values, but React Query is built on the assumption that if something fails, you just throw the error directly, and RQ will be the one to catch/sanitize it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ohhh yeah good point, I forgot about how React Query does it. A throwOnError property sounds like a good idea, but will that make the types difficult? Maybe we default to throwing for now, since that is the status quo anyway.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So my thinking was that if you set up the client with throwOnError = false, the usage looks like this:

const { err, data } = await client.getWorkspaces();

And if the client is set up to be true, it looks like this:

// err no longer exists in the return type
const { data } = await client.getWorkspaces();

We'd have to get a bit in the weeds of TypeScript's type system, and might have to do some type assertions for our own sanity, but I want to say it wouldn't be that bad

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the types seem chill then I am in support!

@Parkreiner Parkreiner marked this pull request as ready for review April 22, 2024 17:02
@Parkreiner
Copy link
Member Author

Also want to ping you @code-asher so that you're aware of the changes for the VS Code plugin

@Parkreiner
Copy link
Member Author

Anything I need to change to get this through? The Axios instance variable has already been renamed?

Copy link
Member

@code-asher code-asher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

@code-asher
Copy link
Member

Oh one comment, there is an example API call in frontend.md, idk if it really matters but we could update that to use axiosInstance as well.

@Parkreiner
Copy link
Member Author

Parkreiner commented Apr 23, 2024

Oh one comment, there is an example API call in frontend.md, idk if it really matters but we could update that to use axiosInstance as well.

Oh, good shout. Let me get that fixed

@Parkreiner Parkreiner enabled auto-merge (squash) April 24, 2024 16:56
@Parkreiner Parkreiner merged commit 3f21cb8 into main Apr 24, 2024
26 of 27 checks passed
@Parkreiner Parkreiner deleted the mes/axios-instances branch April 24, 2024 17:01
@github-actions github-actions bot locked and limited conversation to collaborators Apr 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants