What would be the best way to use ReduxDevTools with complex states and action?

[uhfath]

Suppose we have a state or action that contains some system types - an Exception or System.Type or even delegates. Stuff like that.
Since ReduxDevTools uses JSON serialization these are troublesome to "serialize".
And there is actually no need for this. A simple "key: value.ToString()" would be enough for most cases. Just to see that some properties are set without the details.
What would be the best approach for this?

Cluttering with ***JsonConverter for all the types just for debugging doesn't seem to fit. There are multiple types which are not supposed to be serialized in any way.

Marking actions and states with JsonIgnore won't work, since this will:

1. be against SOLID and will mix things up (debugging with main code, even when used with macros);
2. not serialize properties at all.

Are there any other ideas?
Perhaps something like a callback in FluxorOptions which might look something like Func<object, SerializationMode>. It will be called for each action and based on returned value will do the full serialization (usual one) or "light".
In this case we can decide based on each action what kind of serialization we want.

[mrpmorris]

My recommendation is to store your own representations of the original data.

[uhfath]

I'm not sure I follow. Could you please elaborate a bit?

For example, I have an action UpdateClient.
An effect for this action sends the edited data to backend and receives a result - OK or exception.
If it's "OK" the effect dispatches an action UpdateClientSuccess.
If it's an exception the effect dispatches an action UpdateClientFailed, with this exception in it.

Perhaps one way out of this would be to ditch all unserializeable types and replace them with simple DTOs.

[mrpmorris]

You shouldn't be returning Exceptions from your back-end.

And I wouldn't store them in state either. Your state should be simple objects holding only what information you need.

[uhfath]

These are not stored in state, but returned with actions.
The back-end returns some 4xx or 5xx codes and a client throws exceptions based on that. Exceptions are then propagated through actions to UI code to handle them.
But perhaps you are right and I should strip objects like these to bare minimum POCO classes and use those.