RFC: Fallback mode

Description

Fallback mode is an alternative request interception mechanism applied in a browser. Fallback mode is automatically enabled by the library when either of the following conditions is met:

• The browser doesn’t support the Service Worker API;
• The user has navigator.cookieEnabled set to false that forbids access to the worker;
• The application is loaded using the file:// protocol.

Motivation

Fallback mode is aimed at improving the browser support and enabling the library in static builds of various tools (i.e. Storybook).

Statements

1. Fallback mode is enabled automatically by the library.
2. There is no way to opt-out of the fallback mode.
3. There is no way to enable the fallback mode when the worker can be used instead.
4. Requests intercepted via the fallback mode do not appear in the “Network” tab and don’t actually happen (see technical details).

Technical details

Fallback mode is powered by the recent addition of the fetch and XMLHttpRequest interceptors to the @mswjs/interceptors library. Under the hood, fallback mode patches window.fetch and window.XMLHttpRequest to provision the interception of requests.

Fallback mode is similar to the way most other API mocking solutions work: patching the in-browser request modules. In Mock Service Worker fallback mode will only affect the library’s behavior in the environments where Service Worker API cannot be otherwise used.

Pre-requisites

• https://github.com/mswjs/interceptors/pull/93
• https://github.com/mswjs/msw/pull/660

Public API

There are no changes to the public API related to this feature. Fallback mode is enabled automatically, when necessary.

The only user-facing change would be the change of the library’s activation message:

[MSW] Mocking enabled (fallback-mode).

In addition to the activation message change, the library should print the warning message indicating that the worker couldn’t be registered in the current environment:

[MSW] Cannot register a Service Worker in the current environment. Using the fallback mode instead.

Read more about the fallback mode: <DOCS_LINK>

[otaciliolacerda]

Hi @kettanaito,

Another condition could be to check navigator.cookieEnabled. I was trying to test a scenario on my app where the cookies where disabled but I could not use the mock service due to the error: The user denied permission to use Service Worker. The fallback mode would be nice on this case.

[kettanaito]

Hey, @catch99. Yes, you’ve understood correctly. Insecure contexts, such as serving an app over HTTP or an untrusted HTTPS, are where a Service Worker cannot register per spec. Instead of leaving you with a broken state, MSW falls back to a more conventional fetch/XHR patching to still keep the mocking functional.