Will jsx-handler-names provide suffixes ?

[leadq]

I am very happy using this plugin. However, I think suffixes should be included in naming conventions.

For example, we are trying to implement a pattern like this in our project:

handle{subjectName}{eventName}

or "handle" is replaced by "on" depending on the situation.

valid outputs:
onSwitchChange, handleSwitchChange
handleChange,
onMove,
onMouseMove
handleMouseMove,
handleSomeComponentSubmit etc.

We cannot require the event name to be at the end in the current plugin. I did not see a request for this in the issues. Is it impossible to achieve this or do you have any future plans?

For example, we can manually specify the eventNames in the array ["Click", "Change",.... => maybe 20 more] or if you can easily give the eventNames by default, that would be much nicer.

[ljharb]

It's certainly possible to achieve.

I'm not sure why you'd want it to be customizeable tho, i'd expect any onFoo to require the handler end in Foo when opting in to this style?

[leadq]

We have programmer friends from all levels in our projects, and we have about 20 microfrontend projects. We want each project to be within the same standards. So, the naming of handlers and callbacks should be done within certain limits. . Handler prefixes are really useful and solve most of our problems, but we want to set a standard as suffix(for us: eventNames), because some of our friends use it like below:

Example for callbacks in prop (eslint plugin enforces prefixes, which is super):
someone prefers: onChangeSwitch
someone else prefers: onSwitchChange

The situations above can be same for "handle" prefixed callbacks. Different people prefers different namings after "on" or "handle" prefixes by default.

These naming situations mostly occur if component is a little bit big, and handle different events in some components etc. Other hand, if the component is atomic level, it doesnt need to put suffix because it is very clear which event will be handled.

Since they both have the "on" prefix, it seems to comply with the current eslinte rule, but we are trying to singularize it by directing it as "put the events at the end". Or we wrote a documentation, there we try to get it by asking them to read it.

However, I think that if we had an option like "suffix", they could be arranged more effectively with less communication. But of course, I cannot fully answer the question of how you can make it available to the general public, and edge cases will definitely remain in the things I will suggest. However, the past experience of you and your teammates can interpret how this need can be implemented. So, does this need make sense to you?

[ljharb]

Certainly with a suffix style option, you could use eslint overrides to make one file require a prefix, and another a suffix - but why wouldn't you want "Change" to be there for the onChange examples?

[stevensacks]

I prefer the onVerbNoun / handleVerbNoun pattern because it makes it much easier to search in files for what you need if you don't remember the noun. As JS programmers, we've got almost all of the verbs memorized. Click, Change, Select, etc.

For example, if you remember that it was an onClick, you can search for onClick or handleClick and get results for all the potential noun matches such as onClickFoo or onClickBar. This is especially helpful when the noun is multiple words like onClickSomeRowItem vs onSomeRowItemClick.

Other people might prefer onNounVerb, and that's up them.

Either way, it would be great if there was a way to enforce the preferred naming convention.

It would also be cool if it included a way to make sure the handleXY name matches the onXY prop name so you don't get mismatches between verb and noun like:

onClickSomething={handleSomethingClick}

Thanks!