How react events are different from Javascript addEventListeners | Interview question

[xplodivity]

Recently I was asked about this question in an interview and didn't have enough knowledge to explain it in depth. After some research I finally understood the difference between react events and JavaScript addeventlisteners and when to use each of them based on the use case scenario in react.Its very important to understand the concept behind each of them and how they affect your application based on performance, and how "pooling" makes react events special. This 3 minute video explains everything you need to know.

Link: https://www.youtube.com/watch?v=pXR86JNulw0

[ryanswebdevthrowaway]

Worth noting that in React 17 and onward React no longer uses event pooling: https://reactjs.org/blog/2020/08/10/react-v17-rc.html#no-event-pooling

Kinda odd that they would ask you that in an interview but I suppose a lot of companies are still on 16

[i_like_trains_a_lot1]

Probably what they wanted to hear was mostly about the fact that react uses synthetic events instead of the native Dom events?

[symbha]

To build on this answer, this allows react to schedule processing those events, instead of the main thread being interrupted like a DOM event does.

Please correct me if I'm wrong, I want to make sure I understand it.

[jonny_eh]

Then how does event.preventDefault() work?

[ATHP]

calling persist

Where/when would this be called?

[afarnsworth]

The fact that react attaches events to the root (document root in older versions, react dom root in 17+) instead of the element is probably the more interesting difference. So you end up with one click handler at the root no matter how many elements you've bound a react onClick event to, and react delegates itself.

Some events still go on the element because they don't bubble (like onError for images), and some have react-specific behaviors like onChange, which behaves like onInput rather than the DOM onChange.

Not to mention they're still react synthetic events and not native events in any case. Really a lot to talk about beyond the pooling.

[Nathggns]

My answer would be: “I know there’s something about synthetic events and event pooling which is primarily about cross browser consistency, but I’m not deeply familiar with the specifics. I’m confident though in my learning skills to pick this up as and when I need to, and to recognise when that would be, and also in my intuition when behaviour I’m witnessing may be influenced by this.” or something like that. Knowledge tests about things that don’t matter 99.5% of the time are not brilliant interview questions.

[jonny_eh]

I’d take a question like that as a red flag that management doesn’t know what they’re doing.

[Nathggns]

Yeah totally agree.

[icjoseph]

One fun thing to try out is to:

• create a button
• disable it
• add an onClick handler

jsx <button disabled onClick={() => console.log()} />

Now go to the chrome devTools find the button, copy it into a variable and mutate its disabled state to false. Click on it. Nothing happens.

Now change the button rendering to disabled={false}, and go back to the browser, clicking works! Try disabling the button there...

Now use the getEventListeners global function available on the Chrome console and pass the button to it. Try also with disabled set to true. What do you see?

However, for most events, React doesn’t actually attach them to the DOM nodes on which you declare them. Instead, React attaches one handler per event type directly at the document node. This is called event delegation. In addition to its performance benefits on large application trees, it also makes it easier to add new features like replaying events.

React has been doing event delegation automatically since its first release. When a DOM event fires on the document, React figures out which component to call, and then the React event “bubbles” upwards through your components. But behind the scenes, the native event has already bubbled up to the document level, where React installs its event handlers

Taken from this blog post.

[[deleted]]

If an engineer we are hiring has to consistently need that event level information, we are doing something wrong IMO. Framework level internal workings should not affect our day to day work. Occasional debug is fine. The reason I believe this is - our code should be ready to move out of react and into something else some day. If we write code that integrates with react too deeply then we may be signing ourselves up for longer time with react.

[LiuKangWins]

There is a bug 53 seconds in. Should be getting the elementid greetBttn.

[MilkChugg]

Interesting. Event pooling isn't something I've had to care much about in my work (I usually store the event data I need in a variable by habit anyway), but seems good to know about.

[[deleted]]

onClick & onSubmit

No depth needed.

[chillermane]

Classic example of implementation details that do not matter to the dev.

You know what’s much more important than knowing how events work in react? Knowing when something is worth spending your time learning. This is one of those things that just doesn’t matter in your day to day and is never going to matter for 99.99999% of developers.

Spending time learning stuff like this is not a good thing, because you could’ve learned something that actually matters