Manifest V3

[mikecann]

Am I correct in thinking that this library will no longer work in Manifest v3 with persistant background pages going away?

Edit:

https://developer.chrome.com/extensions/migrating_to_manifest_v3

Basically background pages are going away being replaced with service workers.

Its not exactly univerally loved as an idea: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/0Af4aqQcY1Q

[tshaddix]

@mikecann Thanks for calling this out. I'll have to look into this.

I have tested using this on a non-persistent background page and it worked fine last time I checked. Mostly because chrome will keep the event page running if it is doing something (like connecting via a chrome port, which this package does on every injected page). Additionally, it saves it's state frequently, so it can handle reloads fairly well.

That said, I haven't explicitly tested this with the new v3 spec. We will need to do that. I'm pretty confident we can get it working without too much issue.

[mikecann]

@tshaddix ye I think service workers will randomly disconnect.. Not sure what happens with ports.. Its really annoying TBH

[tshaddix]

Alright I'm still working on testing this here: https://github.com/tshaddix/webext-redux-examples/tree/manifest-v3

As of now, it is not currently working. That said, I can't figure out if it's actually an issue with something in webext-redux or another issue with current Canary build. The current developer workflow for service worker based extensions is terrible IMHO.

I've read through quite a few write ups about the new v3 changes and I'm not seeing any reason this library should not work fine with it. The only major thing that I see changing is the recommended frequency of redux store saves to chrome storage.

I'll keep trying to debug this example extension...

[mikecann]

Ye, theres not that much love for the service worker background page at the moment.. Thanks for doing some research on this, let us know if you manage to get to the bottom of it. I think theres quite a few extensions relying on this lib :)

[tshaddix]

You got it! I'll keep messing with it.

[christospappas]

@tshaddix I checked out your branch linked above and tested it in Chrome 84.0.4147.21 dev. Clicks are registered and the counter updates across tabs. Is there something in particular that was broken when you were testing things or has the latest Chrome build fixed things?

[tshaddix]

@christospappas That's great to hear! It sounds like the latest Chrome build fixed things then. I tried the latest build about a month ago and was still running into issues.

I'll double check to make sure my local copy of the branch is good to go and then I guess we'll just continue to keep an eye on it as the Chrome dev builds progress.

Thank you for your help!

[mikecann]

I havent checked the code but does this account for random service worker disconnects?

[tshaddix]

So this package does not offer persistence at this point (maybe it should?), but you can set up a listener on store state changes to persist the store in memory, and then re-instate the store on extension load:

chrome.storage.local.get([
  'state'
], ({state}) => {
  // initiate redux store with saved state or new
  store = Store(state || {});

  // setup webext-redux
  wrapStore(store, {portName: PORT_NAME});

  /**
   * Save the current store state to local storage
   */
  const saveState = () => {
    if (!store) {
      return;
    }

    const state = store.getState();

    chrome.storage.local.set({
      state
    });
  };

  // On new state, persist to local storage (throttle function from lodash)
  const throttledSave = throttle(saveState, 1000, {trailing: true, leading: true});
  store.subscribe(throttledSave);
});

[Alino]

hi can you please tell me, where should we place this code to load the state from chrome.local.storage?
I have put it just in background page (I tried this, but it get's executed only once after the extension is reloaded) but I guess we should put it inside an "on extension load" listener? What's exactly that? Thank you

Edit: to make it clear why I am asking is because I have an issue that when I switch to other tab, my redux store get's overwritten with new rootReducer for the new tab.

For example here is a state when tab with id 1371 is active:

{
1371isInjected: false,
1371isPanelOpen: true
}

after switching to tab id 2334:

{
2334isInjected: false,
2334isPanelOpen: true
}

data about tab 1371 is gone. Should I load previous state every time a tab is switched from chrome.local.storage and merge it with current state? Or is there better solution, am I doing something wrong?

EDIT2:
so I found out that this disappearing state is happening because of dynamic keys due to tab id.
so I am rewriting my store to look like this:

{
    tabs: {
        2334: {
            isInjected: false,
            isPanelOpen: false
        },
        1371: {
            isInjected: true,
            isPanelOpen: true
        }
    }
}

now my store persists when switching tabs.

[anotherstarburst]

Just a heads up that I've managed to implement this (it took a bit of fiddling though). For anyone struggling I made use of the https://github.com/KELiON/redux-async-initial-state library as redux doesn't play nice out of the box with the promises that are returned from browser.storage.local.get('state'). The usage of the library in my case is something like:

const enhancers = [
  asyncInitialState.middleware(getInitialState),
  ...other enhancers e.g. saga
];

However, in my travels I have concluded that it's worth adding

browser.runtime.onSuspend.addListener(() => {
  saveState();
});

for non-persistent background scripts (which as I understand it is the way the future is looking in v3 as this thread discusses) to ensure the latest state is persisted before the background processes is suspended

[Techdojo]

@mikecann - thanks for opening this issue. I'm just starting to look in anger at rewriting my previous Chrome extension to be compliant with the new MV3 spec and I had exactly the same question as I used the previous version of this library to provide a react / redux framework in my popup page and it worked a treat and I was hoping to use the latest version as well.

FWIW - I'm happy to help out with testing or implementing any fixes to make sure that everything still works in a MV3 world 👍

[hindmost]

For those who still awaiting this library to work in Manifest V3: that will never happen, at least as long as it uses its current architecture. This architecture, let's call it client-server, assumes that the state of extension is permanently stored in a background script (server) and sending to other components (popup etc) by request. The trouble is that this approach is incompatible with event-based model used in Manifest V3. In this model background scripts do not live/run permanently and may be unloaded at any moment (that can't be known beforehand). So with this library, sooner or later, the state of extension will be lost - it's inevitable unless you save the state in chrome.storage every time it changes and load it from there every time it's needed.

Here the question arises: if we have to regularly save the state in chrome.storage anyway, then why do we need such intermediate as Webext Redux at all? Let's just store the state immediately in chrome.storage!

However, chrome.storage does not work in Redux way. So if you accustomed to thinking in Redux, you would like to somehow make chrome.storage compatible with it. That's why I wrote Reduxed Chrome Storage library. This is the only way to get Redux working in Manifest V3. And at the same time it is a unified way to use Redux in all modern browsers' extensions (as storage API has full cross-browser support).