WIP: Fetch support

[bradjones1]

This PR is very much WIP, but I'm trying to push the ball forward for #801 and #2141

Type: enhancement
Notes: Breaking change: Transition from deprecated/unsupported request library to fetch

---

Here's what your changelog entry will look like:

🚨 BREAKING CHANGES

• Breaking change (#2166). Contributed by @bradjones1.

[bradjones1]

So I spent a few hours hacking away on this and it seems to be a heavier lift than the initial work that was done in #797, which was before this library's move to TypeScript. There is quite a bit of logic that follows the callback pattern from request rather than a promise-based approach a la fetch. I've pushed my latest efforts to this branch, but it's not usable and I have reached the limits of my TS knowledge (which is not saying much.)

I think we should really move away from request, but this would likely be a significant breaking change and I'm not sure the maintainers' plan for handling those.

[t3chguy]

Might be worth investigating but this package uses whatwg-fetch (browser polyfill) which may create downstream issues in Element Web inflating bundle size with a polyfill which we never care about as all compatible browsers already support fetch.

[t3chguy]

I think maybe instead of depending on cross-fetch we could just have the caller pass their favourite fetch, as for typing a shim in /@types/ would be fine

[t3chguy]

imports not requires please

[bradjones1]

@t3chguy thank you very much for the look.

As I hope was clear, this is very much POC/WIP and I do not have any working code leveraging this yet. As explained in some of the linked issues, my personal motivation here is to be able to support refresh tokens via a fetch middleware, similar to what I can do with OAuth2 services for other purposes.

Anyway, I'm curious your thoughts on what this change would mean re: backwards compatibility, particularly as it seems all of the callers to the HTTP client's public methods should change away from the request-style callback functions to use a promise. There's also the question of where the JSON serialization can/should happen, as well as handling for query strings, which had a lot of special-casing in play.

For the moment I have backed out of this rabbit trail for my project and am working on shimming in fetch as a custom function that can be used with the same signature... we'll see how that works out!

[t3chguy]

support refresh tokens via a fetch middleware, similar to what I can do with OAuth2 services for other purposes.

I think it won't be that simple, I think @turt2live is also working on refresh tokens, but the issue is if you have multiple tabs open then they will compete with each other and all battle for refreshing so you need a more resilient way to make sure it only gets done by a single tab.

[turt2live]

refresh tokens are sufficiently complicated where they cannot be handled by fetch middleware. The concern isn't that they'll overwrite each other (ultimately it's not bad if they do) - it's that both the old and new token have a strong likelihood of being used, which will trigger the server to do a proper logout.

The code on my end already exists. It's just undergoing polish and cleanup before going up for review.

[bradjones1]

Thanks for the feedback.

the issue is if you have multiple tabs open then they will compete with each other and all battle for refreshing so you need a more resilient way to make sure it only gets done by a single tab.

In my case I'm working so far in a React Native context, so I don't have to worry about coordinating multiple tabs... but I will have a web version and this is indeed an issue, there. Thanks for helping me better understand the trade-offs.

@turt2live looking forward to seeing your work on refresh tokens.

Beyond this question of course is changing away from request due to its maintenance status, but that's a broader question/refactor.

[bradjones1]

The code on my end already exists. It's just undergoing polish and cleanup before going up for review.

@turt2live, did your work on refresh tokens ever land anywhere? My shim is kinda-sorta doing the trick in React Native but I'd like to move along to something less janky if it will land in the core SDK. Let me know how I can help.

[bradjones1]

Ah, ok... I noted the related commits at #2141 (comment) - looks like functions to help perform refresh were added in the SDK and then the implementation was added then reverted in the react implementation.

I'm going to close this since my code is very half-baked and I'm not actively working on this. Switching to fetch or something similar would be good, but that's already open on #801.