Whenever I store a non serializable value in a Redux store, I get the following warning:
In this following example I was storing a Firestore.Timestamp in Redux state. It also happens with the Date object.
A non-serializable value was detected in the state, in the path: blogPost.createdAt. Value: t {seconds: 1583488258, nanoseconds: 805000000}
Take a look at the reducer(s) handling this action type: LOAD_BLOGPOST_SUCCESS. (See https://redux.js.org/faq/organizing-state#can-i-put-functions-promises-or-other-non-serializable-items-in-my-store-state)
And this is what the doc says about it:
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.
I didn't understand much from the doc excerpt above. I think it's a bit vague. Could anybody give a more detailed explanation of what exactly we might/will lose by adding non-serializable data to Redux state?
Does the result differ for different data types? For example: a Promise, a function (ex: a React component) and a Date will cause different problems? Will it cause problems for sure? Or is it something that may or may not happen?
What does ability to persist and rehydrate the contents of a store mean? Does it mean that it could break my app's code or we are talking about devtools debugging only?
UPDATE
Just found out this other piece of doc from Redux Toolkit: Working With Non-Serializable Data.
Working with Non-Serializable Data
One of the core usage principles for Redux is that you should not put non-serializable values in state or actions.
However, like most rules, there are exceptions. There may be occasions when you have to deal with actions that need to accept non-serializable data. This should be done very rarely and only if necessary, and these non-serializable payloads shouldn't ever make it into your application state through a reducer.
The serializability dev check middleware will automatically warn anytime it detects non-serializable values in your actions or state. We encourage you to leave this middleware active to help avoid accidentally making mistakes. However, if you do need to turnoff those warnings, you can customize the middleware by configuring it to ignore specific action types, or fields in actions and state:
It seems that this sections teaches you how to ignore the warning for working with non-serializable values inside the actions, but it also says that it should not go into state, right?
What does ability to persist and rehydrate the contents of a store mean? Does it mean that it could break my app's code or we are talking about devtools debugging only?
Serializable data, mean that you convert data to textual reprensentation and then reload it from textual representation to Actual type;
ability to persist and rehydrate the contents of a store mean
Persist and rehydrate app are a technique used to store current app store state, to reaload in later time. Suppose your user is working on some complex form, when he close the browser and reopen it, you want to have your form filled with what user have entered in his last session, but without the data been stored in your backend server. so you persist your react store when webpage close, and reload it (rehydrate from locastorage) when user reopen the webpage
What it actually happen is that when you want to hydrate you app state from data saved earlier, the non-seriazable fields will not be parsed and converted to the correct type ( may work sometime even if non serializable )
So if you do not plan to persist and rehydrate state, you can ignore the message, but you can also implement a custom serializer for your type ( convert your timestamp to string for example )