Re: [UndoManager] Re-introduce DOMTransaction interface?

On Thu, Jul 12, 2012 at 2:07 AM, Yuval Sadan <sadan.yuval@gmail.com> wrote:
>> I think we need to realize that a lot of the APIs that have been
>> designed in the past aren't terribly good APIs.
>
> The IndexedDB API is rather new, and the manner in which it consistently
> uses event handlers on returned objects is rather innovative. The
> DOMTransaction object is more similar to that.

In IndexedDB events work out "ok" since we can take advantage of the
event bubbling mechanism. That's not the case here.

Likewise, in IndexedDB you generally only have to install a single
event handler, which means that you can write code like:
store.get(...).onsuccess = function(event) { ... };

or

store.get(...).onsuccess = obj.myhandler.bind(obj);

Neither of which is possible here.

Yet, in IndexedDB I would have strongly preferred to use promices
rather than DOM-Events based Request objects. The only reason we don't
is because there are no standardized promices that we can use.

>> In other words, I think it's more important to focus on what makes a
>> good API, than what is consistent with other DOM APIs.
>
> Consistency has its value. Even if some is lacking, fixing it in some places
> and not in others might cause a jumble. Which is my feeling actually about
> the IndexedDB API. Adding more syntactical variations can lead to hectic
> code.
> However, I agree that it's not the primary concern.

Indeed.

>> Something that I really liked about the old API was the fact that
>> using it created very intuitive code. Basically you just write a class
>> the way you normally would write a class, and then pass in your
>> object:
>>
>> x = {
>>   someState: 0,
>>   apply: function() { this.someState++; this.modifyDOM(); },
>>   unapply: function() { this.subState--; this.modifyDOMOtherWay(); },
>>   ...
>> };
>> undoManager.transact(x);
>>
>>
>> You can even do things like
>>
>> undoManager.transact(createParagraphTransaction(params));
>
> How's that different from:
> function createParagrahTransaction(params) {
>   x = new DOMTransaction("Create paragraph");
>   x.apply = function() { ... use params... };
>   x.onundo = function() { ... use params ... };
>   return x;
> }

Ah, you can, but that still doesn't give you nice "class" syntax.

What I actually meant to say was that you can't do something like:

undoManager.transact(new ParagraphTransaction(params));

> Also, in your example, I think that in the JS-object proposal you won't be
> able to reference the original object's properties -- it will be lost, and
> 'this' is window.

Only if you use a dictionary, which I don't think we should. We should
use an interface annotated with 'callback'.

>> The fact that we have to choose between creating APIs that feel like
>> "DOM APIs" or "JS APIs" I think is an indication that "DOM APIs" are
>> doing things wrong. There should be no difference between "DOM APIs"
>> and "JS APIs".
>
> It is a problem. But WebIDL and JS aren't two of the same.

I agree. I don't believe I was arguing that it was. All solutions
debated here can be described using WebIDL.

/ Jonas

Received on Thursday, 12 July 2012 19:39:13 UTC