CreateSlice serializability enforcement – missing constraint

CreateSlice serializability enforcement – missing constraint

When building a Redux Toolkit store, the createSlice API accepts any JavaScript value as initialState and reducer logic, yet it does not automatically verify that those values are serializable. This omission can lead to silent failures in dev‑tools logging, persistence layers, and production builds where the optional serializableCheck middleware is disabled.

The goal is to guarantee that a slice’s state remains fully serializable, preventing subtle bugs that arise when non‑serializable objects (e.g., Date, Map, Set) are stored. The constraints are: 1) the slice definition itself should expose a clear contract about value serializability; 2) any violation should be reported or blocked at the slice level, not merely at middleware runtime; 3) the solution must remain compatible with existing Redux Toolkit tooling.

What is currently unclear is whether createSlice can be extended to enforce this contract, and how such enforcement would interact with dev‑tools, persistence (e.g., redux‑persist), and production builds that omit the serializability middleware.

• Does createSlice provide a built‑in mechanism to reject non‑serializable state values?
• If not, can we augment the slice API to perform a serializability check during slice creation or action dispatch?
• What are the side‑effects on dev‑tools logging, persistence, and production builds when the serializableCheck middleware is disabled?