state reset when opening a second context

[yegor211]

Hello there guys,

This issue is driving me crazy and messes up the extension flow by a margin. It was acting slightly different before, but I’ll start with the current behavior (shows up in @4.0.0) and then describe how it used to behave — feels like the same root issue, just slightly different outcome.

So, we’ve got two contexts using proxyStore (new Store()): side panel and options page (background acts as SSOT). But this isn’t tied to just those — anything creating a proxyStore triggers it. For example: open options page → duplicate tab → the original options page gets wiped. Same thing happens if you open any other extension page (like /test.html) — same result.

To rule out any weirdness from our code, I trimmed both the side panel and options page down to just rendering a <Test /> component that displays part of the state (user data). Nothing else is running in either context during repro.

Repro steps:

• Open options page
• Then open side panel
  → options page gets reset (state goes back to initial)

Same thing if you flip it:

• Open side panel
• Then open options
  → side panel state gets wiped

I’ve tried pretty much everything I can think of. Latest attempt is patching the package and dropping in some logs to see what’s going on.

Here’s a screenshot of the options page logs after opening the side panel:

You can see the user data is empty, and there’s a state replacement action happening. No idea why it logs twice (might be a separate thing), but both messages carry the initial state within the payload. I don’t think these messages even fire when just opening the options page — they only pop up when you open the side panel (or whatever with the proxyStore) afterward.

I thought maybe it’s related to outdated react / react-redux / react-dom versions (... just in case?) — updated everything to the latest (fixed what broke along the way) — had zero effect.

If this isn’t enough context, I can explain the setup/etc further. I wasn’t the original dev, and the setup is pretty gnarly (way too much going on under the hood). Webpack is the bundler.

REALLY looking forward for the help - this is affecting a lot of customers and raises questions...

PS: For the previous behavior when we were running something around @2.x.x version - it was kinda the opposite. Open options page -> open side panel -> side panel gets wiped almost instantly. And vice versa.
PSS: I was trying with/without persist. If I persist ALL the keys, the bug will still take place, but the state will get picked up after a quick blink of an empty (initial) state (it is quite visible in our case because it's a login view). Without persist at all, it always breaks.

[SidneyNemzer]

Thanks for creating an issue. Unfortunately I don't have time to work on this library at the moment, but hopefully I will in the next few weeks. This behavior sounds a little bit like #312, are you using a custom serializer or deserializer? If you could create a small example extension that shows the issue, that would really help me debug this.

[yegor211]

@SidneyNemzer Thanks a lot for your response (and THAT quick). Cheers, mate. It seems I tracked down the issue (very surprisingly). And it seems that it is NOT a bug in the library.

The store gets recreated whenever anything is imported from the Background in the affected context. And it seems it's being recreated within that context. So there are multiple references, single channel and conflicts arise. I added a small check to the store.js file (where it is created, wrapped, etc) to check if the current context is a background service worker and it seems to fix it. However, it seems more like a workaround for the actual problem.

While this appears to be not related to the webext-redux, I would still love to hear a couple of thoughts on fixing this. There is a lot of stuff that lives within the Background. For sure, webpack only "re-inits" stuff once even if there is a ton of imports within different layers. But that is quite enough to rise a problem.

Just wondering what are "general" approaches about it -> seems I (and previous devs) am doing this in a wrong way (or webpack is configured in a wrong way, etc).

[yegor211]

Me again.

Sorry, seems that it's not "anything" from Background, just the spaghetti code has lots of interconnections/re-imports, which eventually lead to imports from the Background/store.js.

I assume the behavior is kinda expected considering this flow and store re-creation?

[SidneyNemzer]

Ahh glad you found the issue! That problem has popped up in our extension(s) too. Or more generally, the problem of importing code indirectly.

To avoid this, we organize our extensions like this:

• src/background/
• src/ui/page1/
• src/ui/page2/
• etc

We avoid importing anything from src/background in other contexts. For better or for worse, webext-redux makes this tricky because the UI needs to import actions which are probably in src/background/ somewhere. We further split the store like this:

• src/background/store/index.ts

  • export const createStore(): Store => {
      const store = configureStore(...)
    
      // ... omitting logic for restoring state ...
      
      const wrapStore = createWrapStore();
      wrapStore(store);
    
      return store
    }
    

• src/background/chat.component.ts
  • export const chatSlice = createSlice(...)
  • export { myAction } = chatSlice.actions

Each 'component' file has its own slice which helps organize the logic. (Slices and configureStore come from Redux Toolkit in case you're not familiar). Then the store/index.ts imports all the components to create the root reducer. This means:

1. We can import from chat.component.ts in the UI without importing the whole store.
2. The store itself is created inside a function, so if it does get imported by accident it doesn't do anything.

We have a lot of slices but for an app that just needs one slice, it could possibly be placed in store/index.ts. As long as the store is created inside a function (called only in background/index.ts) the UI can import the actions without accidentally creating a store too.

Hope this isn't too confusing! I can't share the whole app since it's proprietary of course.

[yegor211]

Thanks a lot. That makes sense. The issue with all the spaghetti code I deal with is (was) an extremely unclear flow and overall structure of the codebase/imports/etc. It seems that something "in-deep" was importing directly from the store module. For some reason I thought that this case would be handled, while I forgot that it's actually also intended to create multiple stores/etc, so there would be no way it could be handled out of the box.

Closing this and - again - thanks a lot. I spent a couple of days tracking it down, really a surprise I caught it right after I became frustrated to the point where I went to create an issue here.

Cheers.