[whatwg] Fixing undo on the Web - UndoManager and Transaction

[Ryosuke Niwa]

I had a discussion with Jonas on IRC and we've come to a conclusion that we
should have both boolean argument and reapply.

The rationale is that if apply/reapply share most code and only requires
some work before/after the shared code, then reapply can simply call apply
inside. On the other hand if reapply needs to do extra work at multiple
points, then apply/reapply should be a single function and take a boolean.
 Thus, we'll have
void apply(in boolean isReapply)
void unapply()
void reapply()
as the interface for manual transactions. And we'll fallback to apply when
reapply is not supplied with isReapply=true.

Now, having automaticTransact and manualTransact will require callers of
those two functions to know the type of transaction and prevent use cases
such as:
var transaction = createMyTransaction(...); // Can return automatic or
manual transaction
undoManager.transact(transaction);

There are couple of alternatives here.

   1. Introduce new createAutomaticTransaction function or new
   AutomaticTransaction, which would create a new transaction object with
   unapply & reapply method given a function or an object with apply method.
   2. Introduce automatic/auto boolean attribute on the Transaction
   interface, and let it determine whether a given transaction is automatic or
   not.
   3. Rename apply to execute (or something else) in automatic transaction
   so that automatic and manual transactions can be differentiated by the
   function name for apply/execute.

Of the above 3 options, I like the 3rd one best since it also conveys
semantic difference between applying an automatic transaction and a manual
transaction. Any thoughts / opinions?

Best,
Ryosuke Niwa
Software Engineer
Google Inc.

On Thu, Sep 15, 2011 at 11:17 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Mon, Sep 12, 2011 at 6:06 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> > On Mon, Sep 12, 2011 at 5:19 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> >>
> >> Could you please supply an example where the apply/reapply split leads
> >> to cleaner or otherwise better code than using a boolean argument?
> >
> > apply: function() {
> >   // modify dom
> >   // send data back to server
> > },
> > unapply: function() {
> >   // ask server what I should do for undo
> >   // modify dom
> > },
> > reapply: function() {
> >   // ask sever what I should do for redo
> >   // modify dom
> > }
> > I can't give you a code from existing apps because such apps do not use
> > undoManager API.
>
> In what situations would you ask the server what to do for
> undo/reapply? I was under the impression that for collaborative
> editing the client still held the full list of modifications, but that
> you mutated that list as you got events regarding other peoples edits.
>
> This example does bring up an interesting question though. Is it ok
> that the undo interface is synchronous? If you have to ask the server
> how to do the undo/reapply, then you might be forced to use
> synchronous XHR which produces bad UI (since the page locks up for the
> duration of the request).
>
> >> Having slightly different signatures for the apply function on both
> >> transaction feels like a much smaller problem. Either we can rename
> >> 'apply' on automatic transactions, or we can give it a boolean
> >> argument too which is passed 'false'. It's easy enough to ignore
> >> arguments in JS, simply don't put them in your function signature.
> >
> > I'm fine with adding a boolean argument if we're splitting the interface
> for
> > automatic and manual transactions because then we don't need to have
> boolean
> > argument in automatic transaction's apply.
>
> Then I think we should go this route.
>
> Maybe rename the property to "execute" or "do" for automatic transactions?
>
> / Jonas
>