Get currently registered handlers

[fvanwijk]

Is your feature request related to a problem? Please describe.

I would like to have a method on the worker that returns the currently registered handlers.
I think it could be just this simple line of code in setupWorker.ts:

getHandlers() {
  return context.requestHandlers;
}

Additional context

The request is partly related to another issue I have: when refreshing the browser, the registered handlers are gone.
I expect this has something to do with the handlers being registered in the client instance and not in the service worker.
The client is part of the application and reinitialized from scratch when refreshing the page.

When this feature request is implemented, we can maybe store the handlers in the browser (sessionStorage?) to make the handlers more persistent.

[kettanaito]

Hey, @fvanwijk.

You can list the current request handlers using the .printHandlers() API:

worker.printHandlers()
// or
server.printHandlers()

• For setupWorker
• For setupServer

When called, this API will print the list of request handlers into the console, containing brief handler information and a stack trace pointing to the handler's declaration in your codebase.

[fvanwijk]

Hi @kettanaito, thanks for the quick reply.

I don't want to print the handlers in the console but I want to use the return value to develop the mentioned feature.
It could also be used to list the endpoints and their handlers in the browser page for example.

I managed to monkey patch console.log and intercept the handlers, but that is a quite smelly solution with all kinds of caveats.

[kettanaito]

You can take an approach I've suggested above: keep a map of id: handler and store the list of handler IDs you wish to re-apply when the client initializes. No changes on the library's side should be needed for that.

[kettanaito]

When this feature request is implemented, we can maybe store the handlers in the browser (sessionStorage?) to make the handlers more persistent.

The handler's nature is reproducible: they are applied when your runtime is instantiated. I see little practical use of persisting handlers—they don't hold an internal state to perstist.

[kettanaito]

When would you want to persist a handler and not have it added initially to setupWorker call?

You're de-facto using a handler consistently, and not appending it on runtime with .use() anymore. Prefer adding it to the initial list of request handlers then.

Otherwise, you can implement handlers persistency as a part of your development setup. I can recommend creating a map of handlers and storing which handlers are assigned by their ID in the localStorage, then hydrating them by reference and applying via .use(). You'd have to generate IDs by any means you find appropriate.

I interpret this as 'they are hard to serialize'.

They are hard to serialize, no doubt, but that wasn't the point I was making. What you wish to serialize is not a handler but a representation of what handlers are applied. The handlers themselves hold no state, so persisting them anywhere is redudant.

So maybe that could be an improvement. For example add a .toJSON method on the handler.

Apart from the lack of practical use for this, handlers cannot be reliably serialized, as they also contain a resolver function. You shouldn't serialize functions.

[fvanwijk]

I'm working on https://github.com/fvanwijk/msw-ui which allows you to change handlers on runtime.

So I have actually already implemented the solution you propose :)
I only still have to store the activated scenarios in localStorage so that everyting is restored after browser refresh.

The users of the library can still apply worker.use without letting MSW-UI and those handlers cannot be restored, but that's probably something I have to accept.

[kettanaito]

Given that the scenarios abstraction is managed by your library, it's only logical you should be responsible for the serialization of those scenarios. As long as you sufficiently persist those scenarios, you can apply them via worker.use() when your runtime starts and have the handlers in place.

Be cautious that serializing response resolvers isn't a good idea and you should ideally avoid that. Alternatively, you can introduce another abstraction over responses that breaks down resolvers into chunks like status/headers/body that you can interactively modify (and subsequently serialize into some JSON) in the UI. Then you map that abstraction to ctx function calls and can apply them this way. That'd be a serialization achieved by sacrificing flexibility, but it's up to you to weigh the gain/cost of it.

Overall an interesting idea, so good luck pursuing it 👍🏻

[fvanwijk]

Great. Thanks for the pointers!

[kettanaito]

Let us know if you feel we should extend the core API to make such integration easier. I'm always happy to discuss ideas.

[MartinJaskulla]

My use case is a little different, but related.

In my unit tests I want to figure out if I have outstanding (not called) one-time handlers which I added with server.use. If a test mocked 3 endpoints, but only 2 were called (1 outstanding), the test should fail.

I understand that server.printHandlers() prints these outstanding handlers. It would be nice if it would also return this list instead of just printing it (or if there would be a new method or property).

In the meantime @fvanwijk and I could use this to keep track of the handlers ourselves: https://mswjs.io/docs/extensions/life-cycle-events

[kettanaito]

I'm considering converting printHandlers into getHandlers on the condition that the returned array of handlers will be readonly. That is to prevent developers from changing the list of handlers directly instead of using server.use() or the initial list of handlers provided to setupServer.

I understand that server.printHandlers() prints these outstanding handlers.

printHandlers currently prints the list of all handlers to the console. This list includes both used and unused handlers. It serves primarily to inspect if the handlers you expect are in the list which MSW uses to resolve requests.