FAQ: this.props - handleEvent, onEvent, and this.props.onEvent

Community%20FAQs%20on%20Codecademy%20Exercises

This community-built FAQ covers the “handleEvent, onEvent, and this.props.onEvent” exercise from the lesson “this.props”.

Paths and Courses
This exercise can be found in the following Codecademy content:

Web Development

Learn ReactJS: Part I

FAQs on the exercise handleEvent, onEvent, and this.props.onEvent

Join the Discussion. Help a fellow learner on their journey.

Ask or answer a question about this exercise by clicking reply (reply) below!

Agree with a comment or answer? Like (like) to up-vote the contribution!

Need broader help or resources? Head here.

Looking for motivation to keep learning? Join our wider discussions.

Learn more about how to use this guide.

Found a bug? Report it!

Have a question about your account or billing? Reach out to our customer support team!

None of the above? Find out where to ask other questions here!

Why didn’t we just add a method to the Button component class and directly set the onClick of the html to that method via {this.handleClick}? It seems confusing to me to have another component class contain the method and go through all that trouble to pass this method to another component class.

2 Likes

I agree this is very confusing. I’m guessing that we are doing it this way so that we understand how to pass event handlers from one component to the props of another componet with a listener.

If we directly set the onClick in the Button.js file by writing the handleClick method within the component, then we would get too specific and limit the usefulness of the Button component. If we want different buttons with different onClick methods, we would have to create many duplicate Button components each with its onClick method defined in the respective file (Button1.js, Button2.js, …). This would cause unnecessary duplication of code and we would have to browse through all the Button files to find which file serves our purpose. However, by keeping things a bit abstract and using the more general statement <button onClick={this.props.onClick} > without directly specifying onClick method within the Button component, we have the flexibility to reuse the Button component. In this specific exercise, we define the event handler in the Talker component and then pass it to the Button component. If we had another component (let us say Talker2) with a different click handler, we could easily define the event handler in Talker2.js and yet still use the same Button component.

2 Likes

When passing an event handler function to a child component as a prop, would it not be less confusing to avoid giving that prop the same name as the eventListener of the child that will call that function and instead use the name of the function you are passing?

For example, in the case of click events, why not just pass the handleClick function down to the child component as a prop called handleClick? Like this…

class Talker extends React.Component {
  handleClick() {
    let speech = '';
    for (let i = 0; i < 10000; i++) {
      speech += 'blah ';
    }
    alert(speech);
  }
  
  render() {
    return <Button handleClick={this.handleClick}/>;
  }
}

Then inside the Button class we can do this…

export class Button extends React.Component {
  render() {
    return (
      <button onClick={this.props.handleClick}>
        Click me!
      </button>
    );
  }
}

This way we are reducing confusion by doing two things:

  1. We are reserving ‘onClick’ to only apply to the actual onClick event listener of the calling child component.
  2. We are not renaming the function when passing it down from the parent component, which means we are less likely to have to go to the parent to see what the original function was called and does.

This seems more logical to me…?

7 Likes

My impressions after completing this exercise is maybe though don’t use HTML-like sounding prop names? Like what was wrong with the previous iteration of Talk and Talker… But even that sounds like it could cause confusion ?? I think its an excellent point of interest to choose very distinct/exact variable names to not only avoid features as bugs but also make your code more readable ??

The first name that you have to choose is the name of the event handler itself.

Look at Talker.js , lines 6 through 12. This is our event handler. We chose to name it talk .

The second name that you have to choose is the name of the prop that you will use to pass the event handler. This is the same thing as your attribute name.

For our prop name, we also chose talk , as shown on line 15:

return <Button talk={this.talk} />;

These two names can be whatever you want.

I find this part (in bold) of the lesson confusing and somewhat in contradiction with the previous exercises. Ok for the attribute name that can be whatever we want. But my understanding was that the name of the props value has be the same as the name of the event handler. And it doesn’t have to match the attribute name necessarily. So, to speak properly, we cannot choose whatever we want, we had to choose talk as it is the name of the event handler we defined.

Probably the lesson was just meant to be written relative to the talk example, but one could extrapolate it as “this is how you should name all your props”.

As for the naming convention described in this lesson - heck, I’m also super puzzled as to why we would complicate things like that, using an attribute name that is written exactly as an event listener. Not only it’s super confusing but also it makes it even more vague as to what handleClick() does imo.

I think these lessons were very poorly worded. Too many things were named ‘talk’ and it is quite confusing at times what they are actually referring to. I don’t know why there are so many name changes (from foo bar to talk /talk and then to onClick). It is just really confusing and doesn’t make sense.