A Lean Redux

When I’ve written React apps I have found it valuable to make use of the Redux pattern for any state management above a certain complexity. That is, I typically won’t use it to manage state in an isolated form, but as soon as that form begins to interact with other state, and particularly across components, it becomes a suitable pattern.

I do, however, think Redux has issues, particularly in the amount of boilerplate required, and the use of strings as the reference to mutations on state. Passing anything other than the action itself to mutate state leads to seemingly unnecessary code:

function reducer(state, action) {
    switch (action.type) {
    case 'increment':
        return {count: state.count + 1};
    case 'decrement':
        return {count: state.count - 1};
    default:
        throw new Error();
    }
}

The problem with the above, taken from the React docs, is that in a sufficiently complex case, this switch statement would become unreadable. This solution does not scale, yet Redux is supposed to be a scaling solution.

Now some of this may be limitations of Javascript, which Redux is written for, but even in a strongly-typed language like C#, not passing the action itself increases boilerplate:

public static int Execute(int previousState, IAction action)
{
    if (action is IncrementAction)
    {
	return previousState + 1;
    }

    if (action is DecrementAction)
    {
	return previousState - 1;
    }

    return previousState;
}

Or, more succinctly:

public static int Execute(int previousState, IAction action)
{
    return action switch
    {
	IncrementAction => previousState + 1,
	DecrementAction => previousState - 1,
	_ => previousState
    };
}

Every time a new action is required, one has to modify Execute and create a new implementation of IAction. IAction implementations are completely empty, which I think violates the principle of least astonishment: an implementation of an IAction would be expected to define the behaviour of the interface, not some isolated method called Execute. We also effectively cannot seal Execute, marking it as closed for modification, because new state mutations will always be required.

The above example is taken from the no longer maintained Redux.NET project, and are not meant as criticisms of that project, but as a criticism of how Redux centralises state mutations, but then has you reference them indirectly. I don’t think the above issues can be resolved with a different language.

I guess I’m asking Redux to be more direct, to not have to skirt around the topic of mutating state. After all, as the caller, I’m the one making the command to do what I say, in which case It’d be better to pass what I want to have happen directly.

Perhaps I am just asking for React’s useState, with lambdas to setState defined in a central place.

const actions = {
    increment: _ => _ + 1,
    decrement: _ => _ - 1
};

const [state, setState] = useState(0);

setState(actions.increment);

This would work within a component, but it doesn’t solve the issue of state managed outside of the components. We’d need to wrap setState into a new hook to achieve that, but it is perhaps worth playing around with.

For MAUI I could make use of C#’s Func and Action types to allow callers to pass delegates to the state manager.

sealed class State<T>
{
    private T _state;

    public void Dispatch(Mutator<T> action)
    {
	_state = action(_state);
    }
}

Dispatch mutates the internal state by reassigning it. We can then implement IObservable to allow observers to react to changes.

// inside State<T>
private IImmutableList<IObserver<T>> _observers = ImmutableList.Create<IObserver<T>>();

public void Dispatch(Mutator<T> action)
{
    try
    {
	_state = action(_state);
	_observers.ForEach(_ => _.OnNext(_state));
    }
    catch (Exception ex)
    {
	_observers.ForEach(_ => _.OnError(ex));
	throw;
    }
}

As the underlying T value is not accessible outside State, Dispatch is the only way to mutate and ensure changes propagate to subscribers. This is not completely encapsulated: we can’t avoid that T may be a reference type, but we can constrain how callers mutate state in a way to alert subscribers. If a caller mutates the reference type instance directly, no subscribers will know about such a change. The change could therefore be considered invalid.