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:
https://redux.js.org/faq/organizing-state#can-i-put-functions-promises-or-other-non-serializable-items-in-my-store-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.
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?
A non-serializable value is a complex object, like a class instance or a function. It is not an array, a plain serializable object, nor a primitive (like strings, numbers, booleans, null, etc.). Otherwise, it would be included in the list of the items that JSON supports.
Object serialization is the process of converting an object's state to a string from which it can later be restored. So, if you are trying to store a inside the Redux state, you need to serialize them before persisting. Storing functions inside redux state is not a best practice in general. So try to avoid it.
A store is an immutable object tree in Redux. A store is a state container which holds the application's state. Redux can have only a single store in your application. Whenever a store is created in Redux, you need to specify the reducer.
It natively supports BigInt , Date , Map , and Set , and you can easily add support for custom types. The package includes a Redux middleware that applies the serify transformation on the way into the store.
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 )
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With