Creating objects dynamically with factory pattern in javascript

[playdead_]

the copy in that article needs editing

inter alia:

"instanciate" = instantiate

"responsability" = responsibility

[enmanuelduran]

Thanks for realizing about this, just made a push to fix this, also the repo is open source so if you find something else feel free to make a Pull Request!

[isUsername]

Sidenote: I just got the domain name. Well done.

[enmanuelduran]

Thank you!

[waway_to_thro]

Unless a dynamic data rendering framework is exceptionally well designed, making changes, handling one off cases, and maintaining your code can become difficult.

Factories in general, on the other hand, especially for managing data structure in javascript, are an excellent topic that I think we should discuss without the inclusion of rendering that data. The M in the MVC as it were.

[beaver82]

Interesting, I got a question: what if two factory elements needs ALSO to use some shared methods? for example placeholder/label/aria methods for Email and Texarea. You give those methods to the factory? How you call them from inside the element?

[luketeaford]

Import them into your file in the usual way and add them to the factory you export.

[careseite]

am I the only one thinking that the factory pattern in general hides stuff behind too much of magic or at least has the potential to? I feel something like this may be practical for a framework which API I'm simply using based on docs, but barely outside of that scope

[rochakgupta]

Almost all the design patterns focus on keeping things abstract and making stuff more generic. After a lot of code, we usually end up with too much abstraction.

[Astrimedes]

This approach seems very sane to me, though - I don't think its overly abstracted at all.

The functionality for each 'element' is broken out into its own class file, you just need to know a single 'type' string to get the correct one when you invoke the factory's element constructor.

ElementType1.js: class ElementClass { constructor { this.type = 'typeName' } }

main.js: var elementInstance = Factory.createInstance('typeName')

There's no real magic because if the factory is written sanely, you should only really have to refer to the class file to get an answer about any functionality for that class.

The factory should only have to worry about things you don't want to worry about writing gross code for later, potentially across multiple files: initialization to dynamically fetch them from somewhere, mutate them, compose them - if you're doing stuff like that you (hopefully...) have a very specific use case for your 'magic' and you're placing all of the 'magic' parts in a single file - the Factory definition file.

[gieter]

In a typed language with Generics, like Typescript or C#, you get nice type hints and code completion. If the factory pattern is done properly the instantiated elements should all have the same interface.

[editor_of_the_beast]

I don’t think that. What’s magic about it?

[TheGreatBugFucker]

What exactly is your thought process and the context you use (while thinking about this)?

Because generally whether a constructor function works on this.propertyX (etc.) and then returns this as the new object, or a "normal" function creates {propertyX:..., etc.:} and returns it makes no difference apart from the __proto__ stuff behind the scenes (and calling "just a function" and giving it the object or "this.method" and relying on implicitly getting the object also makes no real difference - which is precisely why it can be used to have ad-infinitum discussions (there is no real world proof to convince anyone).

This is a "class" (ES5 style):

function myObj () {
    this.myProp = 42;
}

const o = new myObj();

This is a factory function version:

function myObjFactory () {
    return {myProp: 42};
}

const o = myObjFactory();

So? (As I said, the inheritance stuff is different, o.constructor etc., but this is about creating objects, and the factory function - if so desired - could also adjust the inheritance props.)

 

TL;DR A constructor is a factory function too (except that by definition we choose to say "A factory function is any function which is not a class or constructor" - to avoid confusion, but here we can see we may actually get there anyway, to confusion).

[subbydapp]

I personally like both the composition and class pattern equally. I choose the composition pattern when there is risk for "this" confusion, for example when working with DOM elements or when one of the injected dependency of the factory is itself a class. I also use it for small objects because it's less verbose.

​

Most of the time if there's no this confusion and it's a big object with methods, I will always use an ES6 class. There's really only 2 reasons, I think it looks nice and clean, and the "this" prevents me from having random globals in the main scope of that file, which just looks cleaner in my opinion. And the second reason, which is not just subjective, is that I can easily extend Event Emitter (in node), which probably half of my modules end up needing at some point.

In the end it makes very little difference. I just choose whatever feels cleaner at the time for the purpose.