Plans to make the store state fully immutable?

[Drammy]

Hi,

First of all I want to say thanks for building and sharing Fluxor; we've found it easy to use in comparison to other redux models we've used.

Are there any plans to make the data stored in the stores immutable, so that it can only be altered by dispatching actions and thus running the stores' reducers?

I just inadvertently altered my state via the IState.Value property which I assumed would have thrown an exception.

[mrpmorris]

I don't understand what you mean. IState.Value only has a getter declared, no setter.

[Drammy]

Sorry for the lack of clarity - I was referring to the nested state properties accessible via IState.Value

Other libraries we've used (Angular's ngrx library mainly) would throw an exception if we accidentally attempted to change any property of any object stored in the state. This ensures the only means of updating the state is via the reducers.

To achieve the same effect with Fluxor, after retrieving a response from a 3rd party api, for example, we need to clone the response objects into immutable objects. I was just wondering if there were any plans for this to be handled by Fluxor?

It just helps enforce the pattern and prevent user error.

[mrpmorris]

Oh I see. It's your responsibility to ensure your state is immutable.

It's easier in JS, but in dotnet you'd have to do it by only referencing interfaces or making all members virtual and then use proxies. Considering you are talking about 3rd party classes, this is very unlikely - but wouldn't be a job for Fluxor anyway.

Maybe you can write a console app that references the 3rd party dll, opens it with Roslyn libraries, and generates read-only equivalent classes?

I don't know what your best option is. My feature states are view data, so I don't use API classes directly in there, I remap API classes to update relevant views.

[Drammy]

Thanks, makes sense.
Maybe that's the best way too in our use-case - remap the api classes into records; just a shame considering class re-use was one of the key points in making the decision to switch to web assembly.

[two-thirty-seven]

You can create your states using C# Record types and then you are sort of forced into an immutable situation where you reducers can only mutate state like this:

[FeatureState]
public record CounterState(int Count)
{
    public CounterState() : this(0){}
}

[ReducerMethod]
public static CounterState ReduceIncrementCounterAction(CounterState state, IncrementCounterAction action)
{
    return state with { Count = state.Count + 1 };
}