Should event handlers be named using business actions or UI events?

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

Comments

[Jan Peterka]

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
onProductCreated as there was created product in database/somewhere, which may be misleading.
onProductCreateButtonClick describes 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.

[official_dulin]

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. onFormASubmit and onFormBSubmit are 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.

[Jan Peterka]

If this file has 1000 lines, we should split the file :D

[JoelBonetR 🥇]

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:

const NewProduct = () => {
  // business actions
  const onProductCreate = () => {
    showConfirmationToTheCustomer();
  };
  // Element event
  const onProductFormSubmit = () => {
    productService.create().then( res => res.dispatchEvent(onProductCreate);
  };
  return (
    <>
      <button type="button" onClick={onProductCreated}>
        Create
      </button>
    </>
  );
};

take it as a concept.

Also if the code

  const onProductFormSubmit = () => {
    productService.create().then( res => res.dispatchEvent(onProductCreate);
  };

is inside the form component itself there's no need on calling it onProductFormSubmit, you can call it onSubmit and 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 in components/productForm/ but this is an option and you need to check in your project whether is better to use a workaround or the other. 😁