RFC: possible useRefHistory API improvements

Hey @antfu! Thanks for all the work with the lib ❤️

Great to see you added a composable for ref history! We had to build one because the useUndo from vue-composable was not flexible enough for our use case. I was planning to submit a proposal for a similar one at one point. The API is not the same though, so I may release it as a separate lib since it has different tradeoffs. There are some API tweaks that could be useful in the current on in vueuse. If you like any of these changes, I could create PRs for them.

1. Add option to avoid flush: 'sync' I think the default should be for it not to be ‘sync’. We had several actions that were generating spurious history points because of this. An example could be to in a handler to change a size that is defined as {value,unit}, and you need to touch both. We could do this using pause/resume but it will be quite error prone in some apps.
2. Rename history, redoHistory to prev, next This is the way it is in vue-composable useUndo. I think they are more in line with the rest of the API (undo, redo, clear) and it reads better when you use an object for the composable return:

const history = useRefHistory(aRef)
if( history.prev.length > 0 ) { ... } // instead of history.history
if( history.next.length > 0 ) { ... } // instead of history.redoHistory

1. Expose batch(), commit() functions, that complements pause(), resume() (it can be discussed if we should have both pairs after adding batch and commit, IMO they both have different use cases) When doing real time changes, like dragging or playing with a slider, we want only one history point for the whole interaction. The code for this would be

history.batch()
// change state, across several user events (pointermove for example)

and when the interaction ends

history.commit()

If we want to do the same with pause(), resume(), we would need to add another set to the ref to trigger the history point after it is resumed. I also think that batch(), commit() is better suited for this cases because we can add a cancel() function, that will go back to the last history point, finish the batch and resume history (it can also be called revert() if we want to follow a git analogy). commit() can also let us build a manual history composable, with the same API, where the trigger is not automatic but the user is the one in charge of deciding when there is a history point. It also serves as a way to add a sync history point in case the user decides not to use flush: 'sync' but still needs it in a particular case.

I think the other differences with what I had in mind are more about extra features and configuration, and it is not clear to me that the gained flexibility will be enough to justify a more complex API in vueuse. This is why I think there could be space for another lib, with different tradeoffs (more options, but more time to learn it, and more verbose config). But the above proposals could be good for vueuse, and later if people migrate from vue-composable or to other libs, they would have a closer API.

[antfu]

Thanks for the PR. But let me think a bit more about 1 & 3.

[patak-dev]

I like it! For a change set across use events, I would use pause() when the interaction starts and resume(true) when it ends then. I assume that you would also leave async support as something that the user can built with these primitives, and not part of the API. Thanks again for your work, and thanks a lot for the discussion @antfu 🙌