Naming is always challenging. We need meaning, abstraction, and brevity. I read a great article on event handler naming conventions and found it aligned with my own practice, but explained it better. I translated it here as a review and to help other developers.
Even though this is a translation, I still recommend reading the original:
Props
When defining prop names, I usually prefix with on, like onClick. This matches the JS event model and keeps event handlers consistent.
Function naming
For function names, I follow the same pattern but use handle** instead of on**, e.g., handleClick.
<MyComponent onClick={handleClick} />
on indicates the event binding, and handle indicates the handler.
I also keep the same verb like Click, so we can tell it’s a click event. Some people name it handleDismiss for an alert close, but I prefer matching the action. This mapping is clear. Semantic naming aligns with the JS event model.
More complex naming
It probably won’t get more complex than this, but imagine more events and more logic.
For example with alerts and forms:
onAlertClick={handleAlertClick}
onFormSubmit={handleFormSubmit}
I prefer noun first, then verb. It also groups nicely when sorted.
onAlertClick={handleAlertClick}
onAlertHover={handleAlertHover}
Component splitting
How to split components is a big topic and an art. From a naming perspective, if a module has many handlers, it lacks abstraction. We should split it for better encapsulation. Example:
onRegistrationSubmit
onLoginSubmit
After splitting, naming is simpler:
onSubmit in registration-form.js
onSubmit in login-form.js
Built-in event names
Some handlers are built-in, like onClick and onSubmit, which fire on button or form.
When passing these names into custom components, be careful. You might not want the component to be clickable.
Why? Because we might spread props.
function MyComponent(props) {
return <div {...props}>Stuff that might really need the onClick...</div>
}
If I pass an onClick prop to a component for internal use, but also spread all props, I must be careful with naming. I don’t want the div to be clickable.
Final Thoughts
- I agree with a point from Refactoring: variable naming needs thought and can evolve during refactoring. It is not random.
- The author’s naming ideas are excellent. After splitting components, the context allows simpler names, e.g., onRegistrationSubmit to onSubmit. Similarly, when iterating a country array, I don’t like naming the item variable
countrybecause context already provides that. Naming ititemis fine and aids reuse. If the array changes to users, you don’t need to rename the variable. - Be flexible. Code is like speech: don’t say redundant things.
- This article gave me a systematic naming approach for frontend event handlers. Still, apply flexibly.
