State = object from DB
Reducers = Strategies invoked by the subscriber to the SB queue
[Feature(name: "Counter", getInitialStateMethodName: nameof(GetInitialState))]
public class CounterState
{
public int ClickCount { get; }
private static CounterState GetInitialState() => new CounterState(0);
public CounterState(int clickCount)
{
ClickCount = clickCount;
}
}https://freeonlinesurveys.com/s/2L2pYIod#/0
Fluxor was perfect for that use case, I mostly moved away from it after introducing mutability
I'd expect it should work fine, since the library doesn't do any magic to my knowledge
- Immutable data structures all the way (trees, immutable dicts etc...) -> very nice to reason about, but too slow
- Using intermediate mutable data structures and only rebuilding the immutable collections at the end of a full action. That may be fast enough, but it adds complexity to the algorithmically hard part of the code, which kinda ruins the purpose of immutability in this case
- Mutable arrays for the hot path, which make the code much smaller and easier to understand
This is a bit more technical but: the app is basically a high-powered spreadsheet for numerical models - except that users are working with actual variables in their formulas, instead of individual cells. Variables are nodes in a computation graph, determined by the formulas.
Each variable can contain many values (they're small N-dimensional arrays, largest ones are ~200-2000 values). Common workflows also get higher level abstractions, that take care of creating multiple variables in the model for the user.
Which means some actions can result in a few dozen variables being created, each requiring graph maintenance, flagging of observers + other conditional stuff like recompiling a chain of nodes (for dimension propagation). At the end, there is a final linear pass that sorts the graph, performs cycle detection, flags invalid nodes and evaluates out-of-date nodes
I agree. We could copy the whole graph state into a mutable form, perform all the computations and then copy it again into immutable state.
The tradeoff is against a memory allocation cost of roughly 2x the graph state size + additional cost of copying + additional code complexity, since you have two versions of the same data structure (one mutable, one immutable) that you have to convert between.
Overall, that's a tradeoff we decided not to take, accepting localized mutation and strict conventions regarding how that state is changed instead
I have a similar use case to @erwinkn, and although my data set is much smaller it still didn't feel correct to keep recreating a set of nested collections every time something changed. I ended up creating a service which warps my mutable state, exposing methods to modify and read only properties for access. Calls to the service to modify the mutable state originate from Fluxor, which also include dispatching an action that describes the change. Components have a dependency on the service (only using the read-only properties) and Fluxor (subscribe to action if needed). So far it works ok, but I havn't really tried to push it to the limits.
I have a love/hate relationship with Rx, but honestly, had not even considered using it for this.