feat: allow user to choose which event or state change to be captured in the changeStack or not

[whowillcare]

Description

The current solution doesn't have a feature that allow user to specify which events to be added to the changeStack, and which ones are not, which will give user flexiblity to redo or undo specific states changes

Desired Solution

/// allow user to overwrite this method
  bool shouldChangeStack(State current, State next)=>true

@override
  void emit(State state) {
   if (shouldChangeStack(this.state,state)){
     _changeStack.add(
      _Change<State>(
        this.state,
        state,
        () {
          final event = _Redo();
          onEvent(event);
          onTransition(
            Transition(
              currentState: this.state,
              event: event,
              nextState: state,
            ),
          );
          // ignore: invalid_use_of_visible_for_testing_member
          super.emit(state);
        },
        (val) {
          final event = _Undo();
          onEvent(event);
          onTransition(
            Transition(
              currentState: this.state,
              event: event,
              nextState: val,
            ),
          );
          // ignore: invalid_use_of_visible_for_testing_member
          super.emit(val);
        },
      ),
    );
 }
    // ignore: invalid_use_of_visible_for_testing_member
    super.emit(state);
  }

Alternatives Considered

or keep the super.emit to an alternative method name, so the child class can always override the emit method for implementing the similar feature

Additional Context

which will save the resource and allow user to have more flexiblities

[felangel]

Hi @whowillcare 👋
Thanks for opening an issue!

Are you able to provide a bit more context around your use-case? ReplayBloc has a shouldReplay API which seems like it might be what you're looking for.

[whowillcare]

The simplest user case would be like: State: list: ['a','b','c'] currentIndex: 0 Event: add: 'd' # add an element to list remove: 'a' # remove 'a' from list Event: select: 1 # select to new index change the currentIndex to 1 So I would like the Undo or Redo events don't need to catch the select event, but still catch the add or remove event, which gives more flexibility by making certain changes are Replay-able, certains are not.

…

On Tue, Jun 4, 2024 at 1:08 AM Felix Angelov ***@***.***> wrote: Hi @whowillcare <https://github.com/whowillcare> 👋 Thanks for opening an issue! Are you able to provide a bit more context around your use-case? ReplayBloc has a shouldReplay <https://pub.dev/documentation/replay_bloc/latest/replay_bloc/ReplayBlocMixin/shouldReplay.html> API which seems like it might be what you're looking for. — Reply to this email directly, view it on GitHub <#4178 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUL3KF6XUGOSIEG4VRIIJLZFVDTJAVCNFSM6AAAAABIFVWRUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBWGYZDCNBRGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[onism0106]

I have the same requirement. For example, if a certain state is triggered by the PageEventStarted event (an event added when the page is started), this event should not be added to the changeStack.

Is it possible to determine shouldReplay based on the event itself, rather than just the state?

[felangel]

This should be possible to do already using shouldReplay. Since you're in full control of the state you can determine whether or not it should be replay-able.

Is it possible to determine shouldReplay based on the event itself, rather than just the state?

Generally, I don't recommend this because the thing that is being replayed is the state not the event so ideally all information that you need to determine whether a state should be replay-able should be encoded in the state itself. Furthermore, there's a ReplayCubit which doesn't support adding events at all and the ReplayBloc and ReplayCubit APIs should ideally be the same.

Closing this for now since this issue is quite old but if this is still an issue for folks I highly recommend filing a new issue with as much context as possible and ideally a minimal reproduction sample, thanks! 🙏