-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
feat(medusa-react,medusa-js): Allow custom headers #4409
feat(medusa-react,medusa-js): Allow custom headers #4409
Conversation
🦋 Changeset detectedLatest commit: 7ac40bd The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@pevey is attempting to deploy a commit to the medusajs Team on Vercel. A member of the Team first needs to authorize it. |
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.
think this makes sense - thank you for the contribution!
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.
LGTM with comment
packages/medusa-js/src/request.ts
Outdated
@@ -199,6 +200,9 @@ class Client { | |||
options: RequestOptions = {}, | |||
customHeaders: Record<string, any> = {} | |||
): Promise<any> { | |||
|
|||
customHeaders = { ...customHeaders, ...this.config.customHeaders } |
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.
suggestion: I think that we should invert the sense here, the custom headers from the config first and if some custom headers are provided when calling it then it should take priority. wdyt?
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.
Good point. Think it makes sense to allow developers to overwrite custom headers on a per-request basis.
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.
The intention is to allow override, but the order needs to be what was initially proposed for an override to work. The second element overrides the first.
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.
The idea with the customHeaders
configuration is global headers - headers shared among all requests - right? Wouldn't allowing overrides on a per-request basis make sense, which I think is what Adrien proposes?
the order needs to be what was initially proposed for an override to work.
Update: I may be misinterpreting this comment. Can you elaborate? ^
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.
Yes, this is what I proposed, so the config headers are applied but overridden by the request custom headers. With the current approach, if someone wants to change the custom headers from the config they won't be able to as they are applied at last
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.
Either way is fine for my use case. The headers I'll be using won't conflict. I defer to you guys on what should override.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
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.
LGTM!
Adds support for passing custom headers to backend through medusa-js and medusa-react.
This is something I needed to be able to easily access the server behind Cloudflare Access using service tokens, so I thought I would propose it upstream. It can be helpful in a number of deployment situations to be able to pass custom headers in requests to the backend.