.once doesn't go well with .self

[powelski]

Consider following element:

<div @click.self.once="eat">Eat <span>me</span></div>

If we click on "Eat" word, everything works as expected. The event is being fired once and we are happy.

But if we click on "me", which is child node, and then we click on "Eat", the event will never be fired! It seems like .once is too easy on judging an event as fired.

I think .once should mark it as done only if it has been fired in fact.

[yyx990803]

Thanks for filing the issue. Please follow the Issue Reporting Guidelines and provide a minimal JSFiddle or JSBin containing a set of reproducible steps that can lead to the behavior you described.

Why is this required?

[ghost]

Hi,

I am not the OP but I think I managed to reproduce the issue he was referring to. I attached a JSFiddle below for illustration.

JSFiddle

1. Clicking on the word 'Eat' works as expected: the event is fired and the fruit data is updated.

2. If we reload the JSFiddle and click on the span child element 'me', and then on 'Eat', the fruit data is not updated.

Hope this helps.

[powelski]

@boristhuy Thank you for providing JSFiddle. This is exactly what I meant.

[defcc]

This should be a bug. Currently the event handle will be removed once it enters, in fact it is not invoked indeed because of the modifiers check.

Maybe we need to update the once code to support it.

like

(function(){
  var called = false;
  return function($events){
    // modifiers check
    // called check
    if (called)return;
    called = true;
    // handler code
  }
})()

[defcc]

As for once used in render function, it would bring a breaking change. I'm trying to find a way to fix this issue.

1. [wip] update once genCode for template.
2. [done] for once used in render function on: {'~click': handle}, keep the old strategy.
3. [done] there exists a bug in updateListeners for the case bellow:
   old: '~click': handle
   new: 'click': handle2

[yyx990803]

@defcc I fixed it by returning a special value from handlers that are prevented from execution. This may not address the (3) bug you mentioned, but let's handle that in a separate PR if necessary.