HNHacker News
TopNewBestAskShowJobs

ziga-miklic

74 karma · joined September 9, 2014

submissionscomments
ziga-miklic··on Why, oh why was this added?
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!

ziga-miklic··on A Short Cautionary Tale About Refactoring
The author here: Thank you for reading my post. I think it is a valid use case as this is a React application and the inlined image is inside JSX. It is also a part of the main app file. So when the user goes offline, the function with the inlined image is run and the image is rendered. As the image source is inlined, the browser does not need to make a request for the image.
ziga-miklic··on A Short Cautionary Tale About Refactoring
That was such a great read. Thank you both for sharing!
ziga-miklic··on A Short Cautionary Tale About Refactoring
The author here: I agree with @Gupie, having unit tests ensures that you have correctly refactored the code and have not introduced new bugs. Checking the unit tests can also help you better understand what problems the code is solving and the edge cases you may be missing.

Normally, if unit tests were missing, I would add them before starting refactoring. In this case, to be honest, I'm not sure how I could have written a unit test to catch the issue. An E2E test is the only one that comes to mind. Please let me know if I am missing an easy way to test for a 404 image when offline. Thank you!

ziga-miklic··on A Short Cautionary Tale About Refactoring
The author here: Thank you for reading my post! You are correct - I should have. I missed adding a comment when creating the commits, but did include it in my recommendations in the paragraph just below the one you quoted:

> ...if there is a good reason for the current approach, document it. Add a more descriptive name or a comment to avoid confusion in the future.

ziga-miklic··on A Short Cautionary Tale About Refactoring
The author here: I completely agree! When I wrote the post I did come to the same conclusion. I recommended adding a comment or changing the naming to make the inline image obvious, but I missed it when I committed the changes. So I definitely need to practice what I preach.