Eg it’s more helpful for readability to do “onClick => updateDate()” rather than “onClick => handleClick()”
(Not the best example and I’ve seen far more egregious, but those examples are escaping me now)
EDIT: sorry meant to reply to the parent comment.
But this whole thread brings up something about coding that has always irked me, it's very opinion based. When two people strongly hold the opposite opinions on the same team, it can be a massive hassle for absolutely zero benefit.
It's good to know the difference and it gave them the space to challenge me on some of those methods, which in turn helped me write better code.
On teams, or in life in general, IMO when there is no consensus, or even an anti-consensus, the only rational global decision is not to make a global decision.
Solving an issue that is intractable via discussion is when you escalate. Probably to a tech lead, or even to a manager.
This sounds like exactly the kind of pre-mature optimization that leads to overly-abstract function names throughout the codebase. Your point is a good one, once the function does something more than `updateDate()`. But until then, just call it `updateDate()`. As a bonus, this way any time you do choose to use `handleClick()`, the name is conspicuous enough that you pause to see what side effects it might have.
Besides, there’ll be less work if the requirements do in fact change, and there’s nothing wrong with accounting for the possibility of change when you’re writing code because what you write now constrains what you can write in the future.
Also when you are reading the reverse, it’s not clear on what on what updates date. The worst scenario is when two listeners share a handler.
In your example, assuming we're looking at a React codebase (since this seems to square with React's style of events, etc), the resulting data being set into the updateDate function would be an event.
This, unfortunately, doesn't make any sense for a function by the name of updateDate to receive. I would expect to receive at least a new date to update with in the parameters, or ideally in a functional world, both the state to update and the new date we want applied to it. Anyone thinking they could simply reuse the updateDate function somewhere else is going to be woefully disappointed they largely cannot, since it would have been constructed around receiving an Event object.
In that case, I find the "handle" nomenclature to be very useful, as it appears to be largely shorthand for functions design to handle an _event_ (and we tend to see this pattern being used in various React libraries and documentation). React does have a few of these shorthands it tends to use (such as useEffect largely being short for useSideEffect).
Ultimately, I recommend using both functions. One, a handleClickUpdateDate function (notably not a hyper-generic handleClick function which conveys nothing) that receives the event and pulls out the necessary information out of that event to determine what the date is that the user has selected. It then will call the updateDate function with only that date, which creates a nice, reusable updateDate function if we need it anywhere else.
This roughly squares with the idea of having functions that handle the data transport layer (such as receiving data via HTTP or gRPC, etc) whose responsibility it is to receive those events, pull out the necessary information out of the package, route the request to the correct controller, and ultimately return the result in a shape that satisfies the original transport mechanism. In this case, our handle* function is responsible for receiving the original transport of data, then routes the request through to the appropriate controller which is entirely unaware of the means of data transport.
It also means we have a nice, easily testable unit of updateDate to verify our state modification is working to our liking without needing to assemble an entire Event object.
Anyhow, that's how I think of these things ;p
Microservices and JSON APIs.
Common library code (eg. common session handling) incorporated into dozens of microservices.
Monorepos (which actually make this problem somewhat easier).
I have a C# .net MVC web project. All of the JS, .cshtml templates and C# controllers are in the same visual studio solution. So it has complete vision into the code.
So the boundary is from cshtml template to javascript function and then another one from the js function (ajax call) to C# controller.
Visual studio has complete vision, but loses the connection at each boundary, so intellisense says that the C# controller function is never called.
I am not criticizing Visual Studio, it is a great tool, but this is a hard problem.
The downside is lots of little functions, the plus side is smaller behaviors. (Ie avoiding 5 levels of nesting in a single function.)
There’s nothing wrong with 5 levels of nesting. It’s much easier to follow than 5 separate functions.
In that case what I find preferable is onClick => handleClick()
handleClick = () => { stuff in handle click updateDate(); }
on edit: I see lots of others made same point one node lower.
updateDateCallback()
updateDateFromClick()
These show how it's used and what it's doing.
(actually, "up-date date" kind of irks me,)
handleDateChangeClick()
dateChangeModalClickEvent()
And what does this thing actually do? Is it updating data, or making the update UI visible? It's kind of unclear.
If you're showing/hiding UI rather than performing the model update,
showChangeDate[Field/Modal/...]()
beginChangeDateFlow()
...
Code should read kind of like a book.
When someone (or you) is reading the code later, you see a method call and know exactly what it does. This prevents you from having to click in or find it just to figure out what it does.
Frequently, if you click into a vaguely named method, it doesn't do the thing you were searching for and you wasted a little time and need to backtrack, only to repeat the cycle with other vaguely named methods.