Dispatch compose

[ronag]

This relates to...

Rationale

Changes

Features

Bug Fixes

Breaking Changes and Deprecations

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Benchmarked (optional)
• Documented
• Review ready
• In review
• Merge ready

[ronag]

@mcollina @metcoder95 PTAL

[metcoder95]

Pretty much like the concept, it will be interesting as it allows chaining and executing the dispatching one after the other, sequentially.

Just left few comments, I'll give a second look and possibly start doing a review more of the actually implementation within Redirect and Retry handler.

Do you have an idea already for the TS types?

[metcoder95]

@mcollina Unfortunately this API conflicts with the mock API. I found a hack around it but not sure... wdyt? I believe we could probably re-writen the mock API to use the same intercept API but that's beyond me.

Although I agree it overlaps, I'm not 100% we sure change it, they share similar concepts but have different purposes. The mock simplifies the testing quite a lot, especially for simple scenarios; using the dispatcher.intercept might be cumbersome for that (but not essential bad).

[ronag]

As I see it we have 3 options.

1. Hacky compat where we check the arguments to decide which intercept the user intends.
2. Rename dispatcher.intercept (maybe compose?)
3. Rename mock.intercept

[ronag]

Some ideas:

dispatcher = dispatcher.intercept(redirect(redirectOpts), retry(retryOpts))
dispatcher = dispatcher.compose(redirect(redirectOpts), retry(retryOpts))
dispatcher = compose(redirect(redirectOpts), retry(retryOpts))(dispatcher)
dispatcher = intercept(redirect(redirectOpts), retry(retryOpts))(dispatcher)

dispatcher.dispatch(dispatchOpts)

[mcollina]

I would rename dispatcher.composer

[metcoder95]

+1 on dispatcher.compose

[ronag]

@mcollina @metcoder95 wdyt? Are we happy with this API? I'm going to leave documenting it as a TODO for merging next into main. I suspect we might iterate on this even further.

[ronag]

I really like how e.g. ProxyAgent nicely folds into this pattern.

const proxyAgent = new Agent().compose(proxyOpts)

[mcollina]

Can we have it on main instead? It would ease very well the transition.

[metcoder95]

LGTM 🚀

Happy to port this to main

[ronag]

Happy to port this to main

Can you open a separate PR for that and maybe add some documentation as well as update the existing interceptor documentation as deprecated?

[mcollina]

Having next and main having two different implementation of the same thing is a recepie for disaster in maintenance and release. I recommend this is reverted in next, implemented in next and ported to next.

I would need to merge main into next one day, and this will make things very hard.

[ronag]

. I recommend this is reverted in next, implemented in next and ported to next.

Sorry that's confusing?

Wouldn't cherry-picking this into main be the same thing?

[mcollina]

This is based on some other changes in the next branch and I think the end result would be a mess when we try to merge main into next, with main already having those changes landed by a different PR.

[ronag]

Reverted. @metcoder95 have fun with that 😄