Dev/listener multiplexer

[bakape]

Description

Reduces the overhead of creating and dropping event listeners on each patch by registering them inside a global multiplexer. Also provides opt-in callback flags to additionally increase performance at the user's discretion.

Features:

• Multiplexer core functionality
• Callback API extensions
• Listener module porting
• Passive listeners
• Deferred listeners
• Event bubbling
  • Synchronous listeners
  • Passive listeners
  • Deferred listeners
  • Event bubbling
  • Input listeners
  • Change listeners

The core functionality is done, so making this ahead of completion to potentially speed up the review.

Fixes #943

Breaking change

Handling bubbled events by default is expensive. This is the current behaviour in yew. With this PR events do not bubble by default and instead users have to either make a small change to their code or opt into a global deoptimization for that specific event kind.

Example:

<a onclick=self.link.callback(|| ())>
    <span></span>
</a>

becomes

let cb = self.link.callback(|| ());
<a onclick=cb.clone()>
    <span onclick=cb></span>
</a>

Or, in case the user really wants event bubbling:

<a onclick=self.link.callback_with_flags(HANDLE_BUBBLING, || ())>
    <span>
	<span></span>
    	<span></span>	
    </span>
    <span></span>
    <span></span>
    <span></span>
    <span></span>
</a>

This causes all click events globally to perform upward DOM tree traversal to find any other listeners to call.

Checklist:

• I have opened a PR against https://github.com/yewstack/js-framework-benchmark: Dev/listener multiplexer js-framework-benchmark#12

[siku2]

Will take a closer look at the code itself, here are just a few things I noticed.

[jstarry]

Handling bubbled events by default is expensive. This is the current behaviour in yew. With this PR events do not bubble by default and instead users have to either make a small change to their code or opt into a global deoptimization for that specific event kind.

I feel that enabling event bubbling is a better dev experience. I would prefer it to be the default, but devs can choose to optimize for performance and disable if it needed.

I just ran perf benchmarks. The partial update improvements are great and expected! I'm curious what made row creation slow down though, any ideas?

[bakape]

I feel that enabling event bubbling is a better dev experience. I would prefer it to be the default, but devs can choose to optimize for performance and disable if it needed.

So a feature to not add HANDLE_BUBBLED to the callback flags by default?

I just ran perf benchmarks. The partial update improvements are great and expected! I'm curious what made row creation slow down though, any idea?

I'd bet it's the listener equality check. I'm not too familiar with the VTag lifecycle yet. Does a diff on the exact same VTag (same view() call) ever happen? As far as I understand, that is the only scenario, when listeners can be equal. I have a feeling it's actually faster to never check listener equality and always replace them.

[bakape]

@jstarry Listener registration optimized.

[bakape]

@siku2 @jstarry Resolved all mentioned issues, reduced the amount of features, API changes and cognitive load due to configuration variations. Benchmark results still look good.

@mc1098 I see this conflicts with some of your PRs, so you might want to take a look as well.

[mc1098]

The conflicts are fine :)

• Remove InputData & ChangeData #2000 is pretty small and the conflicts would be pretty easy to fix
• Add custom event support  #1991 still needs a good bit of bike shedding anyway
  Haven't reviewed all of this PR yet, but thought I'd just address the conflicts notes so it doesn't prevent this PR from being merged :D

Pull request has been modified.

[bakape]

@siku2 Master merged and all issues/comments addressed.

[bakape]

Right, Components v2. I'll push a fix for benchmarks a bit later. This can be merged as is.