Breaking changes after updating extension to v3

[j-dowell]

After updating the Redux Dev Tools extension (Chrome) to v3 this weekend, our app is no longer working when the extension is enabled. Still works on Firefox as the add on hasn't been updated yet.

We use redux-most as middleware, like so:

import { createStore, compose, combineReducers } from 'redux'
import { combineEpics, createEpicMiddleware, createStateStreamEnhancer } from 'redux-most'

const composeEnhancers = window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ || compose

const epicMiddleware = createEpicMiddleware(
    combineEpics([
        appEpic,
        ... // other epics here
    ])
)

const store = createStore(
    combineReducers({
        appReducer,
        ... // other reducers here
    }),
    composeEnhancers(createStateStreamEnhancer(epicMiddleware))
)

export default store

And now when accessing state (using withState), instead of the regular state object being returned it looks something like this:

{
    actionsById: {...},  
    committedState: undefined, 
    computedStates: [{...}],
    currentStateIndex: 1,
    isLocked: false,
    isPaused: false,
    monitorState: {},
    nextActionId: 2,
    skippedActionIds: [],  
    stagedActionIds: [0, 1, ...],
}

Where the actual state object can be located at the last index of computedStates

Does anyone have any ideas as to what happened here and how it could be resolved? Thanks

[markerikson]

Oh dear.

A couple quick questions to get a sense of what's going on:

• What happens if you just console.log(store.getState())? Is it also this "lifted state" value from the DevTools?
• What happens if you skip the composeWithEnhancers part?
• Finally, what about using composeWithEnhancers and skipping the middleware?

[Methuselah96]

I'm able to reproduce the issue with the example project for redux-most, looking into it.

[Methuselah96]

@j-dowell I believe I have a solution. There was an observable property leaking through the Redux DevTools store that was exposing the lifted state.

However if I release the fix, I'm concerned that your app will break even worse. In my testing it seemed that redux-most could not handle Redux versions >=4.1.0 due to the changes in how the observable symbol was ponyfilled. In those cases, the app white-screens and the same thing would happen if I released the fix.

What version of Redux are you currently on? If you're on a version less than 4.1.0 can you try updating and see if breaks your app?

[markerikson]

Huh. What's the observable ponyfill issue, specifically?

[Methuselah96]

The issue is:
Redux 4.0.5 depends on symbol-observable as does most. symbol-observable polyfills Symbol.observable and so it doesn't matter which one calls symbol-observable first, because the first one to access will do the polyfill and therefore both libraries will share the same symbol.

Redux 4.1.0 does not depend on symbol-observable and is instead just doing a ponyfill for the observable symbol. Therefore if redux is imported first, it sees that Symbol.observable is not set and decides to use '@@observable' as the ponyfill. However when symbol-observable is imported later, it polyfills Symbol.observable and that is what is used by most. Because of that the ponyfill and polyfill observable symbol properties don't match up and most crashes because it was expecting the Redux store to have the Symbol.observable polyfill property.

So it seems like Redux should polyfill Symbol.observable if it wants to remain compatibility with libraries that use symbol-observable (perhaps add back the dependency on symbol-observable for simplicity?).

[markerikson]

Grrr. We specifically removed that dependency in 4.1.0 specifically because it was a lousy 1-line dependency and I didn't want to have to rely on it.

Could we just advise users to import the polyfill first if it's a thing they need to depend on?

[Methuselah96]

Was the dependency causing any specific problems? It seems like adding a few bytes to the bundle size is easily worth it in this case in order to avoid the special instructions of having to import the polyfill first, any complications that arise from that, as well as any developer time spent trying to figure out why it's broken. It's a pretty bad gotcha and easily solved on the Redux side of things. I like getting rid of dependencies as much as the next person, but this one seems like a net positive.

[markerikson]

No specific problems, but it seemed unnecessary to have a dependency for that one-line polyfill, and I've been advocating for years that the JS ecosystem should cut down on tiny dependencies to help consolidate and improve installation. So, I was trying to follow my own advice there.

I don't want to re-add that dependency, but I'm open to discussion on it.

[sorinpav]

Hi! Is there a way to downgrade to a previous version? We're having issues as well, and I'm not sure what to do to make it work again. It seems drastic to force us to update our code, when an extension is updated without our consent. I magically found the latest version of the extension on my system, without purposefully upgrading.

[Methuselah96]

@sorinpav Unfortunately Chrome Extensions automatically updates extensions without consent and doesn't have a way to downgrade which is a severe limitation of Chrome Extensions. For now the best way to work around it is to download the extension.zip artifact from the most recent release and load it unpacked. Hopefully we can get this resolved as soon as possible.

Another possible workaround would be to try to import $$observable from 'symbol-observable'; as the first import in your app. What version of Redux are you using?

[sorinpav]

Thank you so much! That sorted our redux devtools extension. It's really frustrating to see breaking changes like that, hopefully it gets sorted out soon.

The redux version I'm using is 4.1.2.

[j-dowell]

@j-dowell I believe I have a solution. There was an observable property leaking through the Redux DevTools store that was exposing the lifted state.

However if I release the fix, I'm concerned that your app will break even worse. In my testing it seemed that redux-most could not handle Redux versions >=4.1.0 due to the changes in how the observable symbol was ponyfilled. In those cases, the app white-screens and the same thing would happen if I released the fix.

What version of Redux are you currently on? If you're on a version less than 4.1.0 can you try updating and see if breaks your app?

@Methuselah96 Thanks for looking into it. But our app is already using 4.1.1 of redux with no issues.

[Methuselah96]

Thanks for the info. My guess is that the reason it breaks with the extension but not with plain Redux is because the order of import is the Redux DevTools extension, most/RxJS, and then Redux. I have a fix in mind that I'll try to get out today.