Why do you say that's the right way? Is there something intrinsically better about having the state modelled as a stream of changes? Is that really getting rid of mutable state? [EventA, EventB] is a mutation of [EventA], sure it's a WAL style, but the combined final state is a mutated version of the original state.
Presumably the concrete state model (like MobX) is a realisation of the event stream at a moment in time. As far as the user is concerned, the only moment in time that really matters is now.
I've done plenty of work with immutable data, and I tend to code in a way that minimizes the amount of state I have to manage.
I guess that's what I was saying about mobx though - I can have a much smaller set of core data and then pure functions for the layers of derived data. And it's a) easy to reason about and b) super performant at managing the calculations.
Aliasing bugs don't really apply in JS, unless there's some variation of the term? Stale caching is also not an issue with calculated derived data.
Saying about "aliasing bug" I meant something like this:
var my_data = {"foo": null}
function innocuous(input) {
var data = {"one": input, "two": something()};
data.input.foo = data.input.foo || "foo" // set a default value
// do something with data
}
var result = innocuous(my_data)
// Oops, now my_data.foo has changed.
I'm saying its the right way to get rid of it, not that its right to get rid of it :)
MobX does really, really well in minimising the complexity of mutable state. Its the best there is out there.
Where MobX does worse is when there is more complexity then a simple direct map function to calculate derivations: debouncing key input, doing async requests, creating animated transitions, etc. Its a great model, but it needs some more work to be truly amazing.
The user does care about the past. For example if the state of the input box changed too many times during the last second, they don't want every change to cause a slowdown in response time due to too many requests being sent to the server, and they want only results from the last request they sent, not the last one that was processed.
I think the reverse criticism applies for cyclejs: while it can do everything thanks to RxJS, it needs a better component composition model. The current one is too tedious and alien for my taste. (For example, why isn't the same DOM selector syntax used for component-event selection?)
Presumably the concrete state model (like MobX) is a realisation of the event stream at a moment in time. As far as the user is concerned, the only moment in time that really matters is now.