Downsides of disabling serializableCheck for specifics actions

[rickstaa]

I want to store the MediaStream object in my redux store. As this is a class, it is clearly non-serializable. As a result, I get the following warning when I try to do this when using the default config:

index.js:1 A non-serializable value was detected in action, in the path: `payload`. Value: 

Based on #339 and the documentation I, therefore, changed my config to the following:

import { configureStore } from "@reduxjs/toolkit";
import callSlice from "./call-slice";

const store = configureStore({
  reducer: callSlice.reducer,
  middleware: (gDM) =>
    gDM({
      // Disable serializable checks for certain actions
      serializableCheck: {
        ignoredActions: [callSlice.actions.setLocalStream.type],
      },
    }),
});

export const callActions = callSlice.actions;

export default store;

After reading the documentation, I think this is the cleanest way to do this without encountering unexpected time travel bugs when working with the Redux DevTools. To my knowledge, the only downside is that I can not use the Redux DevTools time travel function to investigate the ignored actions.

Are there any other downsides of using the above method that I overlooked that require me to use the react context API or a custom hook better instead?

[todorone]

Another thing is the data, which is non-serializable, is not persistable...

[rickstaa]

@todorone Thanks, that is a good point which I missed. I found this article that explains that problem. Would you advise putting it on the global window object instead, using the react context API, a custom hook or a singleton to store non-serializable data?

[rickstaa]

After doing some reading and redoing several sections from the course, I came to the following conclusions. Please be free to add your 2 cents when you think something is wrong or missing?

• Redux (see section 19): Like stated above is great for storing data that can be serialized.

• Keep it local: First check if you really need to share it with other components.

• Translate to a serializable object: Best option if you only need part of the object state that is serializable.

• Pass it over props: Not ideal since an app can be layers deep.

• Put it on the global window object: Might be confusing and is not really react like.

• Use a singleton to share the data: Works, but might be unnecessarily complex and not really react.

• Put the logic related to the non-serialized object in a custom Redux middleware (see this issue): A good solution, but in this case we have to make sure that the non-serialized object doesn't reach the reducer.

• Use the React context API: This looks like a good solution, but should only be used when the variable you store doesn't change frequently.

• Use a custom hook: This is useful for sharing logic across several components, but each component has to contain its own state.

• Use a custom hook that contains a global state: This currently is my preferred solution for storing non-serializable objects that you want to share across several components.

As a result, I came to the following conclusion. First of all, you should not store non-serializable data using Redux if it can make it into your application state through a reducer. Instead, it would be best to use any of the above methods to share the non-serializable data. Which method you use depends on the data you want to store and your project.

What did I choose

In my project, I choose to use the Custom hook + global state solution, as calling the getUserMedia method multiple times creates multiple objects and therefore could lead to problems with some browsers (see this stack overflow post. Alternatively, the context API can also be used as requesting the media stream is a low-frequency event. I choose the custom hook solution as this leads to less code in the components.