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

What's the official opinion on attaching one event to table vs events to each tr a? #706

Closed
utkarshkukreti opened this issue Mar 4, 2020 · 4 comments

Comments

@utkarshkukreti
Copy link
Contributor

I'm working on finalizing a submission for Draco, my Rust + Wasm framework and I don't know which path I should choose.

There are currently 3 keyed and 4 non-keyed Rust entries. After a quick glance at the code, it seems like stdweb, wasm-bindgen, simi attach one event while the rest attach to every <a>.

(I personally prefer the second one, as it would be a more "real-world"ish approach.)

@ryansolid
Copy link
Contributor

ryansolid commented Mar 4, 2020

Event delegation is super common in the JavaScript world. By that I mean using a single event handler applied to a parent to handle child row events. jQuery popularized this approach in the late 2000s and for different reasons React implemented it under the hood (on the document) for their Synthetic Event system to normalize event behavior across browsers which notoriously behaved differently.

It actually has considerable performance impact in a test like this where you are inserting 1000s of rows. The use of explicit Event Delegation has been considered a divisive topic since some people do believe that it is a hack. However, those arguments have never gone far since they are made by the same library authors and implementors use the technique internally in their VDOM implementations. So essentially a good chunk of the field does it, between implicit libraries that feel it should be part of their normalization efforts and those that deal closer with DOM nodes and consider it just a standard technique.

But I mean it has been a long going argument. #430 and that traces back to half a dozen earlier threads and several after.

So it's fallen into a grayer area as there has been no consensus, given the argument isn't whether or not to delegate but whether Explicit (ie not part of the library) should be considered a hack. From that perspective, any lower level vanilla implementation probably should use it as that's the way to make it equivalent. Higher-level implementations have to make a choice of how they want to represent their library. These conversations lead me to implement implicit delegation in my library, Solid, but even to this day I sometimes wonder if it was necessary. But it is no secret I'm heavily on the pro explicit event delegation camp. @leeoniya or @localvoid and others probably have a different take.

Some people might think otherwise (and they are a good chunk of the heavier contributors of this repo) but using delegation won't get your submission rejected historically speaking. And while it might bring with it a stigma, it is no different than what anyone else is actually doing technically. So all I can say is do what feels right for the library and you. I attempted to add event delegation to Svelte and didn't have community support so I withdrew it as I felt it wasn't my decision to make. Since you are the author that is a much simpler as the decision is up to you.

@leeoniya
Copy link
Contributor

leeoniya commented Mar 4, 2020

So all I can say is do what feels right for the library and you

that's a fair summary of the situation. my view is, when you see a vdom lib that is able to handle delegation implicitly, and another vdom lib that requires you to do it explicitly in user-land to attain similar perf, the latter certainly feels like a workaround for a lib deficiency. i can't speak for non-vdom paradigms.

everything that could be said on this topic has already been said :D

@krausest
Copy link
Owner

krausest commented Mar 5, 2020

@utkarshkukreti Is your question answered?

@utkarshkukreti
Copy link
Contributor Author

@ryansolid @leeoniya thanks for the replies! @krausest yes if you agree with Ryan and Leon. I'll close the issue.

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

No branches or pull requests

4 participants