My personal opinion is that immutable state is vastly easier to reason about than mutable objects, and the pattern where we mutate an object then pass it into update() feels incredibly dirty to me. That said, an immutable data/functional approach is quite different to the object-oriented approach we have now. It would mean substantial rewrites of things like SubscriptionManager and even PCDCollection. Roughly speaking, this approach would mean having pure data objects with functions that create new objects rather than methods that mutate the existing ones. Instead of doing object encapsulation, you encapsulate all mutation in something like Redux reducers. I suppose I am just pining for ClojureScript here though.
If we're serious about evaluating some other options, I wonder if it's worth doing some brief hacking of example apps using some different state management frameworks, perhaps informed by some of the things we've found to be problematic in the past.
My personal opinion is that immutable state is vastly easier to reason about than mutable objects, and the pattern where we mutate an object then pass it into
update()feels incredibly dirty to me. That said, an immutable data/functional approach is quite different to the object-oriented approach we have now. It would mean substantial rewrites of things likeSubscriptionManagerand evenPCDCollection. Roughly speaking, this approach would mean having pure data objects with functions that create new objects rather than methods that mutate the existing ones. Instead of doing object encapsulation, you encapsulate all mutation in something like Redux reducers. I suppose I am just pining for ClojureScript here though.If we're serious about evaluating some other options, I wonder if it's worth doing some brief hacking of example apps using some different state management frameworks, perhaps informed by some of the things we've found to be problematic in the past.