DEV Community

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

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