Docs: document that ReactiveFetchManager requires registerGlobally() to patch global fetch

[jeswr]

Summary

The README has no API documentation for ReactiveFetchManager, and the patching model is easy to get wrong. In the published 0.1.3, constructing the manager does not patch globalThis.fetch — you must call registerGlobally():

const manager = new ReactiveFetchManager([provider]);
manager.registerGlobally(); // <-- without this, globalThis.fetch is never patched

Without registerGlobally(), plain fetch() (and libraries built on it, e.g. @jeswr/fetch-rdf) never upgrade on 401, so authenticated requests silently fail and the login popup never opens. This is a non-obvious trap when building against the published package.

Request

A short README/API note stating that registerGlobally() is required to install the global fetch patch (and that the constructor alone does not), ideally with the two-line snippet above.

Context

This bit us while building a Solid app; we corrected the downstream guide that had wrongly stated construction patches fetch:
jeswr/solid-ai-coding@ad05301

Happy to open a small README PR if that's welcome.

[langsamu]

Absolutely. I wanted to react quickly to @NoelDeMartin's point about monkey patching.
I will write it up.

[jeswr]

@langsamu rather than requiring this method, why not do the registration during the construction of the ReactiveFetchManager?

I believe that should address Noel's concern around monkey patching without requiring users to manually call a method for global regsitration.

[langsamu]

@langsamu rather than requiring this method, why not do the registration during the construction of the ReactiveFetchManager?

I believe that should address Noel's concern around monkey patching without requiring users to manually call a method for global regsitration.

That is how I had written it in the first place (patch in constructor) but I agree with Noel that it is better to leave that decision to library users. This is why it is now opt in an extra method call.

I say let's leave it as it is and I'll document it.
Later I was thinking about static methods on the manager class that encapsulate some of the patterns:

• Just give me a fetch based on these providers.
• Just patch fetch based on these providers.

[NoelDeMartin]

Yeah, also from an OOP point of view, it's very unexpected that calling a constructor has side-effects as drastic as monkey-patching a global variable. So if that's going to happen, even from a non-default config option, I think it'd be better to encapsulate the construction of the object in a function call.