Is storing Non-Serializable Values into a Redux store a bad idea?
Redux has the following recommendation as Essentials.
Do Not Put Non-Serializable Values in State or Actions
Avoid putting non-serializable values such as Promises, Symbols, Maps/Sets, functions, or class instances into the Redux store state or dispatched actions. This ensures that capabilities such as debugging via the Redux DevTools will work as expected. It also ensures that the UI will update as expected.
Yeah, I think it makes sense so that it enables us to store data in a WebStorage or send the store data to a server. Time-travel debugging is also a great feature even though I have never use the feature in production applications 😅
But, it imposes us on a constraint that we must use data structures that are possible to be serialized as JSON, which means we can only use “String”, “Number”, “Boolean”, “Array”, and “Object”. For me, the constraint makes our implementation difficult and complex.
I wrote an entry to describe a pattern to use Map/Set for data stored in a Redux store before.
This makes some operations for a list easy because of the APIs that Map/Set has. For example, you can use “Map#get()” and “Map#has()”, instead of “Array#find”, to get an element from a list, which is very straightforward.
Actually, I don’t like the APIs of Map/Set because those are based on mutability and are lack of APIs. The Iterator Helpers proposal would solve the problem of the lack of APIs, so I’m looking forward to seeing that it reaches stage 4.
In addition to Map/Set, I’m also looking forward to the proposal of Records/Tuples (Stage2).
The data structures are based on immutability, so they are very suitable for React applications and Redux applications. Records/Tulples can be serialized with JSON.stringify, but can not be deserialized with JSON.parse even though the proposal has a proposal of JSON.parseImmutable to deserialize Objects and Arrays as Records and Tulples respectively. Does the style guide allows us to use Records/Tulples for data stored in a Redux store? Records/Tulples would become serializable and deseriablizable data structures if an application treats all data as immutable. I think it makes sense to add using Records/Tulples for all data in a Redux application to the style guide because immutability is important to make applications predictable.
I think the recommendation is a trade-off. As the style guide mentioned, we might have a problem with using non-serializable data structures, but if we can accept the risk, we can get the full power of data structures that JavaScript has. The data store often has complex operations and domain logic, so I think it’s important to pick the most suitable data structure in each case. I’ve seen code that uses Object and Array instead of a proper data structure like Map/Set. However, JavaScript has been evolving, so it’s important to take advantage of the power of evolution.
