I work as a front end developer in a company that makes big web applications for a large set of customers. Today, the back end came to me and showed the following scenario:
We have a portal, and this portal have a session that displays some products of its store. The portal is in our ecosystem, and is developed by us with an internal tool, that also makes the portal's management. But the Portal's product store is hosted by a completely different application in a completely different server, and we have no access to it. Anyway, this customer sand us a tiny requisition today, which seems pretty simple: "they wanted to track clicks on the products and show a hit count to any product inside the Portal's Admin", which is also in our application.
So, the task would be simplier if we had access to the stores's source code. Just put a kind of $hits++ somewhere in the back of the products page view, point it to a table, or whatever, and voilà. But we couldnt do that. So, the first solution was: lets perform an ajax with a $hits++ everytime a user clicks in a product link in the portal (we could use our source code). Note: the customer wasnt wanting to count the number of access to his product pages, but the number of clients that has arrived to the store thought the Portal. So, before to go to the third party store, we would track the link click, save it as a ++ in our database, and show the stats on a dashboard. Pretty simple, uhn? DONT DO THAT!
Heres the problem with use the click events to a task like that: this kind of event dont cover all the possible situations that a user could perform to go to the product page (or any other page depending on the situation). This kind of event only covers the CLICK (of course). But sometimes we can missunderstand it and consider more things like a click, or simply ignore that the user can:
- Use the context menu and open the link in a new tab
- Perfom a command or super + click
- Perform a drag and drop action to open the link
In any of this actions, the click event would be never triggered. We could predict metakeys, override context menu actions, etc, but would be a cannon to kill a fly. We knew this kind of things should not be done in the client side, but we tried to figure out a quick answer to a simple task and we just reinforce this conclusion: this kind of things should not be done in the client side.
So, a simple solution was: all the product links should point to a single url in our system. This url would act like a router: will receive params like the product id (or even the product url) and other stuff, perform the hit count (or whatever we want), and then - and only then - lead the user to the clicked product view. Like an "intermediary layer". A few modifications, a few milliseconds more (unfortunately), and no client side handle. Just change the product link on the product view and drops the params there.
This situation was in fact easy to solve, and we didnt invented anything new. To tell the truth, we take just a couple minutes to figure out a good solution to our task. But i thought it would be worth to talk about it, mainly considering the nature of the situation and the new devs. The point gave by the backend solution here is:
Always consider the many user's behaviors as possible (including the accessibility derivated behavior),
Always prioritize a good pattern instead a quick solution.
If spend more work will prevent future problems or needings, even if they're only in your mind for while, do it!