DEV Community

official_dulin
official_dulin

Posted on

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

#react #naming #frontend #discuss

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>
  );
};
Enter fullscreen mode Exit fullscreen mode

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>
    </>
  );
};
Enter fullscreen mode Exit fullscreen mode

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)

Collapse
 
janmpeterka profile image
Jan Peterka • • Edited

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.

Collapse
 
mrdulin profile image
official_dulin • • Edited

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.

Collapse
 
janmpeterka profile image
Jan Peterka •

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

Collapse
 
joelbonetr profile image
JoelBonetR 🥇 • • Edited

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>
    </>
  );
};
Enter fullscreen mode Exit fullscreen mode

take it as a concept.

Also if the code

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

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. 😁

Read next

dsychin profile image

Lessons Learned Migrating from React CRA & Jest to Vite & Vitest

Desmond Chin -

danrot90 profile image

Writing high quality tests

Daniel Rotter -

bitbyprogress profile image

Diving Back into React: A Software Engineer’s Learning Journey

Progress Eze -

574n13y profile image

Disaster Recovery and Backup Strategies

Vivesh -