[HN Gopher] Why, oh why was this added?
___________________________________________________________________
Why, oh why was this added?
Author : ziga-miklic
Score : 36 points
Date : 2022-05-27 06:08 UTC (16 hours ago)
(HTM) web link (zigamiklic.com)
(TXT) w3m dump (zigamiklic.com)
| bombcar wrote:
| Whenever you have to modify code _elsewhere_ because of a side
| effect in the current function /file - it should be cross-
| referenced commented (in both places) because of things like
| this.
|
| Just because Chesterton's Fence is a thing doesn't mean you have
| to build new ones without signs on them.
| noduerme wrote:
| There are really few times I find stopPropagation() necessary,
| and try to use it as little as possible. Usually it's something
| right there in a parent. Even so, the larger point here is that
| events are very hard to trace through code. This is why I always
| use enums or static variables to define the names (event types)
| of events any given class will emit within the class definition.
| It makes it a lot easier to see what other code references that
| static name than it does to find every instance of "click" in a
| huge codebase.
|
| If you only add stopPropagation() when there's a reason, then at
| least later you know there had to be a reason.
| ziga-miklic wrote:
| I completely agree. stopPropagation() should be used only as a
| last resort. I have removed a lot of unneeded use cases with
| this task, but because of the size of our codebase, many still
| remain. But at least now they include a comment as to why they
| exist :)
|
| With enums/static variables are you referring to custom events
| or also DOM events? For custom-based events we use that
| approach but not for DOM events. If you do use it for DOM
| events, I'm curious to know more about it. Thank you!
| [deleted]
| tetha wrote:
| > To make sure you don't forget, you quickly add a comment
| explaining why event.stopPropagation() is there. You are hopeful
| that it will help save time for someone in the future. That
| future someone might even be you.
|
| This is something I've been training and forcing myself to do. If
| I spend 10 - 15 minutes thinking about some piece of code or
| infrastructure to understand why it's here and what it does...
| add whatever you learned and found out as a comment. Even, or
| especially if it wasn't fruitful, and your only answer is "the
| system is being weird here in the following way, and this mess is
| here to fix it, kind of, in most cases - and since you're here, I
| guess not in this case".
| hvs wrote:
| I admit that I'm a terrible (descriptive) code commenter and
| that is after 25+ years as a professional programmer, BUT I
| always try to add a comment when I add some weird code to fix
| an odd bug or add some special case.
|
| And I can confidently say that pretty much every descriptive
| comment I've ever written was out-of-date shortly after it was
| written, but the "hey, this weird because of X and if you think
| you are going to optimize or fix something you need to be aware
| of this special case" have saved me numerous times.
| pcthrowaway wrote:
| Actually wanting events to bubble past a handler is rare enough
| that I sometimes just through e.stopPropagation() in without
| thinking too much about it. It's much more common to be bitten by
| _allowing_ events to continue bubbling IMO
| layer8 wrote:
| This is one of the most important skills to learn as a developer:
| when to add a comment explaining the reason for some non-obvious
| code -- and also how to write it so that enough context is given
| for the future reader, who may not have the same understanding
| that you have of the rest of the codebase and the business
| requirements.
___________________________________________________________________
(page generated 2022-05-27 23:00 UTC)