Buffer of previous values & Rollback signals

[Solido]

Here I share some feedback or potential features around Previous values.

First I found it is a great feature and useful in many case.
My first concern is that since I'm using a lot of signal in means I have (n*2) instances of my signals in memory. So came the idea to not have it mandatory but configurable.

Let's imagine a configurable Buffer of N previous. But default T previousValue return the current value because the buffer is empty thus no memory used.

We can then configure a buffer to have N memory of previous values.

I can then have T previousValues Iterable<T> previousValues I can access previousValue(2)

Finally we can try to imagine a rollback() mechanic where value <- previousValue and imagine we can chain signals together to rollback.

[rodydavis]

Oh I love this idea! By default it would be set to 1 but if you set to 0 it would prevent tracking and also would throw an error on accessing previous value.

The other value stored is the initial value for reset and disposal. Should something be done with that? Maybe I could include in buffer.

Should the int.infinity or similar be used for no limit? Maybe null too

[Solido]

We may have to create an array of all the possible behaviours :)

My expectation would be 0 by default and previousValue => value, other option like you said is throwing an Ex. I would not change reset and disposal but let's think about what can be done maybe?

Can you explain why putting to 0 would prevent tracking? I do not see the connection here.

I prefer int.infinity as I rather avoid null and consider it an conception error.

As you can see this ticket is linked to Option #57 too :D

[rodydavis]

My thinking is:

final s1 = signal(0, buffer: 1); // Also default case if not specified
final s2 = signal(0, buffer: 0);
final s3 = signal(0, buffer: 5);
final s4 = signal(0, buffer: null);  // or 1 / 0 since dart doesnt have int.infinity but this returns it

For s1 it would track the previous value and when updated it would overwrite the buffer with the new value.

For s2 it would throw an error if previousValue is called but also not create any additional memory. When value is updated it skips the buffer.

For s3 it will keep a buffer of 5 items and when rollback is called it would undo the item and remove it from the buffer while setting the value. Thinking about using a Queue for this.

For s4 it would not have a fixed size and would allow unlimited items to be tracked. This is the worse for memory but might be needed.

The other option I have been thinking about is moving this logic to a trackedSignal that would have undo/redo features.

Maybe a tracked signal could be created by any other signal and contain the logic for previous/next value.

I think it is still nice to have previousValue in signal base though.

[Solido]

I'm curious about the TrackedSignal as this is still a important but rare case.
Most signals will not use this features but providing it help in a lot of cases.

[rodydavis]

Yeah that's why I didn't add TrackedSignal yet and if anything would make a signals_timetravel package if I did.

And agreed I do think most people would want the previous value which is why I would have it as 1 by default