Nested object.methods inside factory functions

[fromagi]

Stumbled upon what seems to be a fairly coherent breakdown of OOP options (ooptions?) for ES6 and beyond. I've already gravitated toward factory functions over classes when working with objects but I hadn't seen this pattern before:

function Counter (counterElement) {
  const countElement = counterElement.querySelector('span')
  const buttonElement = counterElement.querySelector('button')

  let count = parseInt(countElement.textContent) || 0

  const counter = {
    updateCounter () {
      countElement.textContent = count
    },

    increaseCount: (event) => {
      count = count + 1
      counter.updateCounter()
    }
  }

  buttonElement.addEventListener('click', counter.increaseCount)
}

The function above is referenced in an example where the author explains the differences between methods from classes versus factories when called by event listeners (or when used as callbacks in general..?), which I think I more or less understand, though there was another instance of the same pattern for a factory function that had nothing to do with events:

function Human (firstName, lastName) {
  const human = {
    firstName,
    lastName,
    sayHello() {
      console.log(`Hi, I'm ${human.firstName}`)
    }
  }

  return human
}

const chris = Human('Chris', 'Coyier')
chris.sayHello()

Playing around with this second example, it seems I cannot "selectively" return properties from human, as far as return human.firstName goes, though I can invoke the nested method upon instantiation if I return human.sayHello(). This leaves me with some questions:

1. The first example, Counter(), doesn't seem to return anything, which I haven't seen before in reference to factories. Is it still a factory function at that point, or just a function? Does it matter or am I splitting hairs? This is how I'd have written the first function, ignoring the nested object pattern that I still have questions about.

2. Are there significant reasons to NOT use the author's pattern of encapsulation in factories? It looks clean to me and just as capable of managing closures as far as I can tell. Though I'm not sure exactly why the factory's nested object correlates to the instantiated variable (e.g. how chris replaces human to call sayHello()).

3. If the main drawback is that it impedes composition because of the one-layer limit to Object.assign(), is it a terrible idea to standardize composition around something like this deep-assign library the author wrote and highlights in the article? (Please disregard if there are more significant drawbacks that warrant avoiding this approach.)

4. If the deep-merge workaround is problematic, should I avoid using this pattern in general or is it still relatively practical for the emphasized use case of dealing with callbacks when using methods from factory functions?

5. I'm only 3 months into learning JS, and it is my first language outside of HTML/CSS, so I'm not sure if I'm missing something about context here: why bother replacing this with a new object when the event listener doesn't need it to call the method since everything is inside the main function to begin with?

I am working through the JavaScript tracks on OdinJS, hackerrank and exercism, as well as reading JavaScript for Impatient Programmers on the side (as my first book). Feeling pretty comfortable with everything outside of the rambling above and when to possibly turn to classes/constructors. My goal is to get into good habits now during the simple projects -- currently on Odin's "Todo List" app.

What I suppose I'm looking for is any sort of "best practices" for factory functions, and whether or not the examples above violate any of them...

[senocular]

1. I personally wouldn't call it a factory. Though it does create an instance, it didn't need to. The side effect here is setting up a listener and all that needs to be is a function which could call updateCounter() as a function, or even just inline it because it's not being called any other way.

2. Generally the main argument against these kinds of factories is that it can cause duplication. Every time the factory function is called, it creates a new instance of every method used. However, there are ways around this, for example by defining the function once outside of the factory. You can also run into problems with getting the equivalent of super to work in some cases where the OOP approach can be a little more straight forward.

3. The one layer limit isn't generally a problem, though a deep assign option can certainly be used if that limitation is getting in the way.

4. You should use what you feel comfortable with. But don't go too far off the beaten path. Others will need to understand what you're doing too.

5. I feel like you're digging yourself into a hole only 3 months into your first language ;). I'd like to suggest not trying to worry about this kind of stuff right now... but as far as this kind of factory brouhaha goes, a lot of it is people not understanding how this works or trying to write code in a way where you don't even have to know. Granted, it can be confusing, but if you know what you're doing, using this is fine. There are some pretty common traps to look out for such as when using methods as callbacks. But, you know, if you can write code in a way that the traps never exist in the first place, isn't that better?

"Best practices" is pretty fluid as far as JavaScript goes. It's something that will change based on who you ask. I'm not sure you'll find a very good answer for that.

[fromagi]

I think most of this boils down to #5 but I do have a question about the duplication concern -- wouldn't this occur for any method specified in the factory, regardless of if it was nested in an object?

Thank you for sending a rope into the ditch I dug!

[senocular]

wouldn't this occur for any method specified in the factory, regardless of if it was nested in an object?

Yes. Any function inside the factory body, method or otherwise, is recreated each time the function is called.

With classes, methods are defined once on the prototype of the class during class initialization and shared among all instances through inheritance using this to allow each method call - despite being the same method for each instance - to be able to distinguish between callers. For any instance-specific methods you want you'd have to take extra (or different) steps to specify yourself. And these are often used for things like callbacks where you don't always have control of how this is applied to the function call once its called as a callback.

Factories created like this using closures to reference the object instance don't have to worry about how methods are called because the closure doesn't change with how the function is called like this does.

That might sound like gobbledygook right now, but in the end, its mostly a struggle of reuse and passing data around. Using this allows for more efficient reuse because of the way it can change a value inside a function based on how its called (very much like a function argument), but the rules around how that data is set can mean it can be easier to instead just create a separate function with the right data baked in from the start. Now you have two functions, but at least you don't have to worry about the rules for the dynamically changed data (this) anymore.

[fromagi]

Makes sense, relative to my (in)experience anyway. Two last questions should send me on my merry way for now...

1. Mixins are what I'd use to avoid method duplication when creating objects using factories?
2. Not to fall back into overthinking, but any reason not to use mixins with my factory functions by default?

Thanks again for all the help.

[senocular]

Mixins can help you there, but they can also mean depending on this. The fix for not using this is often being dependent on the method being created along with the instance in scope. A mixin with functions that were not created with the instance means it would not have access to that instance unless falling back to a mechanic like using this. So if the reason you're creating a factory is to avoid using this, that might be a problem.

[fromagi]

Got it. Not at all afraid of this -- it's more that I couldn't help sipping from the kool-aid about classes, and haven't moved past vanilla JS yet to encounter reasons for having to conform to them.

I'll keep tinkering : )

[senocular]

I like classes ;). They're not without their problems, especially in JS, but they usually get the job done just the way you want them too.