This problem is not specific to a framework, But I demonstrate questions in React.
Example 1. Suppose the following is a user registration page component
const Register = () => {
// business actions
const onUserRegistered = () => {
userService.register();
};
// Element event
const onUserRegisteredFormSubmit = () => {
userService.register();
};
return (
<form onSubmit={onUserRegistered}>
<button type="submit">Register</button>
</form>
);
};
Example 2. Suppose the following is a product create page component.
const NewProduct = () => {
// business actions
const onProductCreated = () => {
productService.create();
};
// Element event
const onProductCreateButtonClick = () => {
productService.create();
};
return (
<>
<button type="button" onClick={onProductCreated}>
Create
</button>
</>
);
};
As you can see, I am hesitant to use business actions, or elements events to name event handlers. I prefer element events to name the event handler because this is the presentation layer, the presentation layer should not care about business actions. The service layer contains business actions. Please advice.
Business action name composed by: on + BusinessAction
UI event name composed by: on + WhichElement + Event
Top comments (4)
Oh, naming. Naming is difficult. (There's for sure some xkcd strip for this, too lazy to find it)
I'm in no position to say what's good practice.
Coming from Python and recently heavily influenced by Ruby, I try to ask
what reads well- what makes understanding what's happening easiest (with minimum cognition) a fastest.But that depends on how I think vs how others think, on rest of code (consistency can be make good name not that good), and code context.
In case you show here, I would heavily incline to
Element event.On Example 2, I read
onProductCreatedasthere was created product in database/somewhere, which may be misleading.onProductCreateButtonClickdescribes what really happened.Same in first example - submitting form doesn't mean user was registered - backend form verification could stop registration, there could be some reason user wasn't really created in database. But we know that form was submitted.
Hope this helps.
That's what exact I mean. UI event handler name should NOT be equal with the method name of the service layer. Event handlers should clearly represent elements and their events. Consider that there are multiple forms on the page, they all have submit event handlers.
onFormASubmitandonFormBSubmitare clear. We should distinguish UI events and service method names. If this file has a 1000-line code, we don't have to scroll or copy the search, you can know which form of this is the submission event.If this file has 1000 lines, we should split the file :D
I think that an event should be named after its trigger.
The trigger can be a user action or a success of actions and sure the functional design on the frontend has to be aligned with the business processes, thus you'll need (probably) both.
You are effectively showing two different situations that can be a group of events, let me exemplify:
take it as a concept.
Also if the code
is inside the form component itself there's no need on calling it
onProductFormSubmit, you can call itonSubmitand attach it to the form in context instead. As your component will be a function, it's content (including it's constants, will be scoped). And while seeking for it, it will be incomponents/productForm/but this is an option and you need to check in your project whether is better to use a workaround or the other. 😁