-
Notifications
You must be signed in to change notification settings - Fork 530
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
Semver Major Considerations #2722
Comments
onBodySent on onRequestSent are footguns that easily cause bugs when implementing logic will send multiple requests, e.g. redirect and retry. To achieve similar functionality wrap body into a stream and listen to 'data' and 'end' events. Refs: #2722
onBodySent on onRequestSent are footguns that easily cause bugs when implementing logic will send multiple requests, e.g. redirect and retry. To achieve similar functionality wrap body into a stream and listen to 'data' and 'end' events. Refs: #2722
SGTM, left some thoughts on the PR 👍
Agree, wrapping dispatches providers' full ergonomics. The interceptors feel like a half-baked feature sadly
What's the problem that surfaces from it?
Maybe we can refactor it to a base class and do something similar as we do already for the
I kind of remember this PR; I believe it is mostly around documenting what
Do you mean to implement them within each of the APIs or just export a new one? Do we have a timeline for the next major version? |
@metcoder95 do you think you could help me with a PR removing the interceptor stuff? |
onBodySent on onRequestSent are footguns that easily cause bugs when implementing logic will send multiple requests, e.g. redirect and retry. To achieve similar functionality wrap body into a stream and listen to 'data' and 'end' events. Refs: #2722
If we consider undici major version, than maybe target llhttp 9 upgrade to the next branch?! |
Sure, I can have something prepared for next week 👍 |
I believe that yes, but also with the considerations from @mcollina |
onBodySent on onRequestSent are footguns that easily cause bugs when implementing logic will send multiple requests, e.g. redirect and retry. To achieve similar functionality wrap body into a stream and listen to 'data' and 'end' events. Refs: #2722
onBodySent on onRequestSent are footguns that easily cause bugs when implementing logic will send multiple requests, e.g. redirect and retry. To achieve similar functionality wrap body into a stream and listen to 'data' and 'end' events. Refs: #2722
onBodySent on onRequestSent are footguns that easily cause bugs when implementing logic will send multiple requests, e.g. redirect and retry. To achieve similar functionality wrap body into a stream and listen to 'data' and 'end' events. Refs: #2722
Added |
Regarding to what to do instead of interceptors. See the following example for nxt-undici https://github.com/nxtedition/nxt-undici/blob/main/lib/index.js#L116-L132 |
Can you please target a |
onBodySent on onRequestSent are footguns that easily cause bugs when implementing logic will send multiple requests, e.g. redirect and retry. To achieve similar functionality wrap body into a stream and listen to 'data' and 'end' events. Refs: #2722
Regarding interceptors: how would you implement them instead? |
Changed target of the llhttp PR to next. |
Or some other way, but there is IMHO no reason for it to live in undici core. |
I'd like to drop FileLike and FileReader too. |
I'd like this to be documented to showcase possible use cases as alternatives to interceptors; after writing the |
Do you think you can add that with the or to remove interceptors? |
Yeah, I'll tackle it within that PR 👍 |
Once you are done with that I have some ideas I'd like to experiment to further simplify and improve the dispatch api. |
@metcoder95 another step we should do is to change the handlers (i.e. retry, redirect etc...) to export functions instead of classes, i.e. export const redirect = (dispatch) => ({ ...opts, redirect }, handler) => dispatch(opts, new RedirectHandler(opts, redirect, { dispatch., handler }) export const retry = (dispatch) => ({ ...opts, retry }, handler) => dispatch(opts, retry, new RetryHandler(opts, retryOpts, { dispatch., handler }) Or something like that. A little unsure how to exactly pass along options to a specific dispatcher. |
Hmm... We can draft something down the line while removing the interceptors. Like the idea, it is similar to what we have for |
what's the timeline for this release? Are we targeting Node.js v22, v23, or v24? |
I don't have a clear timeline atm. I don't think these changes should be noticable inside node. |
Yes, please. |
How about adding an easy way to implement different connectors? The current implementation does not allow the use of Dispatcher.connect to open a connection to the host, it uses the connector that is under the hood You need to think and decide how it will be more convenient to do this |
Do you have an example at hand? I think can provide a better idea of the usage. But on top of my mind, is this is something that can be implemented with |
Based on my experience working with undici through nxt-undici and building a more advanced client on top undici I have come to a few realizations that have semver major implications:
onBodySent
andonRequestSent
are huge footguns. Remove it. (just wrap the body)interceptors
are weird and overengineered. Remove it. (just wrap dispatchers)onConnect
is confusing and should be renamed or something to make it more intuitive. Possibly entirely removed.body
should support a factory method (important for retries and redirects).onResponseStarted
. Why is onHeaders insufficient?maxRedirections
andRedirectHandler
should not be part of core/dispatcher APi. Move to the api methods.The text was updated successfully, but these errors were encountered: