Are non-serializable objects in the store really that bad?

[srmagura]

Hello! I've recently switched from vanilla Redux to Redux Toolkit and I've started getting warnings about non-serializable objects in my Redux state.

It turns out I've been keeping certain non-serializable objects in Redux for years, across multiple projects, and never encountered any issues with it. Specifically, I keep Error objects and Moment instances in Redux, though this would also apply to standard Date objects as well. This hasn't caused any problems because I never mutate the Errors or Moments.

I see two options for resolving the warning:

1. Put "dehydrated", serializable versions of Errors and Moments in my store. For Moments, this would probably be the result of myMoment.toISOString(). Then when I need to use the Moment object, I rehydrate it from the ISO string. This seems like the officially-recommended approach but it less convenient than what I'm used to.
2. Disable the warning by passing a custom isSerializable function when configuring the serializability middleware. This function would return true for Errors and Moments.

Which option should I go with?

By the way, I do use the Redux DevTools and have used redux-persist on one project. For redux-persist, I wrote a transform that converted between Moment objects and their ISO string representation. I do not use time travel debugging so I'm not sure if the non-serializable objects would work with it.

[markerikson]

This is covered in the Redux FAQ entry https://redux.js.org/faq/organizing-state#can-i-put-functions-promises-or-other-non-serializable-items-in-my-store-state :

It is highly recommended that you only put plain serializable objects, arrays, and primitives into your store. It's technically possible to insert non-serializable items into the store, but doing so can break the ability to persist and rehydrate the contents of a store, as well as interfere with time-travel debugging.

If you are okay with things like persistence and time-travel debugging potentially not working as intended, then you are totally welcome to put non-serializable items into your Redux store. Ultimately, it's your application, and how you implement it is up to you. As with many other things about Redux, just be sure you understand what tradeoffs are involved.

The other potential issue is that non-serializable values like classes or Dates are typically updated mutably. If you have selectors that directly return those values, and you happen to mutate them, your components likely won't re-render because useSelector sees the same reference and thinks nothing has change.

So, long story short: yes you can get away with it, but it's definitely going against our recommended patterns because it has the potential to cause issues.

I personally would prefer to keep date in the state as ISO strings for readability and serializability.

[srmagura]

Thank you @markerikson for being helpful as always. I'll weigh the pros and cons of each option and make a decision. Regarding storing the ISO strings in the Redux store:

1. It is a bit less convenient for me because now I have to parse the ISO string into a Moment when accessing data from the store.
2. This parsing (ISO string → Moment) could negatively affect performance if the selectors & components are coded such that the parsing occurs on every render. Regardless, it's likely not something I should be worrying about. (A quick & dirty test indicates that parsing an ISO string with Moment takes an average of 13 μs on my PC....)