[Q/A] How to use redux in background.ts?

[Mis-tian]

What happened?

A bug happened!

Hi, using redux in background.ts, I found the problem as shown above, because the related dependency package references window (there is no window in Service Worker)

For example, the situation is that a custom axios is introduced in the createAsyncThunk method, and the axios wrapper internally introduces antd's message component to handle some generic error alerts. Currently it works fine after I clear the message component code.

Also tell us, what did you expect to happen?
This is probably not a bug, more like an optimization。
Is there any suggestion to avoid this problem, and is it possible to consider a package build of background.ts that excludes window related code.

Version

Latest

What OS are you seeing the problem on?

No response

What browsers are you seeing the problem on?

No response

Relevant log output

var webpackHMR = false;
function useDevHMR() {
    return webpackHMR;
}
exports.default = useDevHMR; // Webpack `module.hot.accept` do not support any deps update trigger
// We have to hack handler to force mark as HRM
if (module && module.hot) {
    var win = window;
    if (typeof win.webpackHotUpdate === "function") {
        var originWebpackHotUpdate = win.webpackHotUpdate;
        win.webpackHotUpdate = function() {
            webpackHMR = true;
            setTimeout(function() {
                webpackHMR = false;
            }, 0);
            return originWebpackHotUpdate.apply(void 0, arguments);
        };
    }
}

},{"@parcel/transformer-js/src/esmodule-helpers.js":"hCtEe"}],

(OPTIONAL) Contact Details

No response

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate problems.

[louisgv]

BGSW cannot consume redux dependency that targets web as noted in your question. To hydrate the redux state tree on the bgsw side, you will need to use something that's built for service worker runtime - basically headless redux.

If you are trying to consume a dependency, that in turn consume another dependency that exposes react code to show error <- this is the issue with that dependency not targeting SW when compiled. The idea is similar to WASM - the dependency must target the runtime or if needed, be reimplemented for such runtime.