|
|
|
|
|
|
by dragonwriter
1880 days ago
|
|
|
> Make your line for registering an event listener look like this: `this.button.addEventListener("click", this)`, and change the name of your `addSum` method to `handleEvent`. (Read it aloud. The object that we're dealing with (`this`) is something that we need to be able to respond to clicks, so we have it listen for them. Gee, what a concept.) In other words, the real fix is to make sure that the thing we're passing in to `addEventListener` is... actually an event listener. Eh, show me an object that both owns a button and is an event listener attached to that button, and I’ll bet you just showed me an object that violates the SRP. OO event listeners make sense to encapsulate state narrowly associated with handling the events being listened for. But, having been doing OOP since I was a teenager in the late 1980s (and even that after programming for more than half a decade), I don’t prefer to do as much JS as possible in a functional style because I don’t get interfaces
or other OO concepts, but because I understand the limits of their utility and managed not to be one of the one-paradigm-to-rule-them-all programmers that came out of the excessively OO-focussed pedagogy of much of the 90s and 00s. |
|
|
Sounds like a veiled criticism towards an implied target (of me), which would be interesting, considering the retort is an appeal to "SRP" (referred to only with shorthand, even), and indeed, the first mention of OO(P) is your comment. The shape of your foe isn't what you think it is.
> OO event listeners make sense to encapsulate state narrowly associated with handling the events being listened for
For this defense to be valid, you have to ignore the preconditions that got us here. The entire context here is making sure that `this` refers to the correct thing at the time that the event listener is executed. Either you want that, or you don't—pick one.
(And as with, like, 90% of mainstream applications of the label "functional programming", look at what people are actually talking about when they use those words, and it's immediately apparent that theirs is a style of programming where the label is unjustifiable, considering it's fundamentally at odds with what functional programming actually is. Again, pick one: you either intend to do FP and do so through the use of functions, or you want your state baggage. Modern appeals to FP by JS programmers in the mainstream and the practices that get smuggled in under that brand are just as bankrupt as arguments for modern JS practitioners' best practices regarding anything else—ones that are entirely self-defeating or fail to hold up under scrutiny otherwise.)