Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add failing test for forwarding element modifiers (execution order not affected by splattributes' location) #18167

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

cibernox
Copy link
Contributor

@cibernox cibernox commented Jul 2, 2019

Now that element modifiers are forwarded with the splattibutes, I was expecting to be able to decide in my components if my event handlers run before or after those provided by the users.

Example:

{{!-- my-component.hbs --}}
<div {{on "click" this.defaultHandler}} ...attributes>hello</div>
<MyComponent {{on "click" this.userProvidedHandler}} />

In this scenario I'd expect this.defaultHandler to always be called first, because the user-provided handler is applied with the ...attributes AFTER.

In this other scenario however:

{{!-- my-component.hbs --}}
<div ...attributes {{on "click" this.defaultHandler}}>hello</div>
<MyComponent {{on "click" this.userProvidedHandler}} />

I was expecting this.userProvidedHandler to be called first, and then this.defaultHandler, because the ...attributes is placed before in the div element.

Being able to decide the order of events is important to be able to call event.stopImmediatePropagation() and reliably know what handlers will not run.

That doesn't seem to be the case. Right regardless of where the ...attributes is placed, the user-provided event is invoked first.

@cibernox cibernox changed the title Add failing test for forwarding element modifiers (order is wrong) Add failing test for forwarding element modifiers (execution order not affected by splattributes' location) Jul 2, 2019
@cibernox
Copy link
Contributor Author

cibernox commented Jul 2, 2019

@chancancode You may have insight on this, IIRC you helped with RFC 435

@rwjblue
Copy link
Member

rwjblue commented Jul 3, 2019

I personally think these failing tests should be made to pass, but the first thing I'd like to confirm (with @chancancode / @wycats / @krisselden) is that this is the intended behavior.

@kategengler
Copy link
Member

Is this still relevant?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants