todo example problem?

[pbrito]

related to toggleAction #6

Video showing the problem: https://youtu.be/JDC13K6-OX0

[ioss]

Not a problem. Bei removing the action to add "dois", "tres" becomes the item with id:2, and the action to mark the item with id:2 is now marking the item "tres".

In other words: In your case, when you disable the action to enter "dois", the actions get replayed kind of like this: Enter "um" Enter "tres" Mark the second item (which this time is "tres").

This seems fine to me and is what I would expect when replaying the actions minus the one creating "dois".

If you don't want this to happen, your "mark reducer or with the help of its action" has to identify the item in another way, so that it is not "mark the second item", but "mark the item dois".

[pbrito]

No,I don't agree with you. If I have a "buy milk" and a "buy cigars" and mark "buy milk" as completed. After that I disable the entry "buy milk" then "buy cigars" appears as completed. What does that means?I never bought cigars....

Thus the correct default behavior of this tool should be to go back to particular time in the past, as in the talk of Dan Abramov at react-europe .

Disabling a random action only should be considered in very specific and controlled cases. Because it's very difficult to reason about and also highly dependent of the implementation and concepts of the application you are writing.

As an extreme example look at git, if you remove a past commit in the middle of the chain you go against the core concept of git.

Greg Young talks about CQRS ( was one of the inspirations behind Flux) are a good resource.

[danielkcz]

You are not right, @pbrito. It's like @ioss said. There is no identification of those items other than position in todo list. If you want to be more specific, the MARK_TODO action would need to have unique identifier for that line instead of simple position.

[ioss]

This seems to be more of a UX problem. A click in a devtool is a very specific and controlled case ;). It just did not result in what you expected: rewind to this action instead of toggle skip this action

You can write your own LogMonitor where you handle a UI interaction of your choice by "calling" jumpToState(index).

I am sure devtools or more likely custom implementations of the Monitor will get a better UX/UI. The redux-devtools main responsibility is (imho) to provide the functionality to create these kind of UIs.

[gaearon]

Disabling is useful for filtering out actions you're not interested in right now that clobber the few actions you're actually working on. At least that was the idea.

[gaearon]

Closing as inactive.