There are many ways to create new JavaScript objects. In this post, we'll use the fluent interface pattern! In the fluent interface pattern, we use classes with defined methods to add attributes to our object.
In the following example, we create a PersonBuilder class. In the constructor, we create an empty person property. Then, we have some additional methods called withName and withAge that allow us to give our person a name and age, respectively.
Finally, we have a build method. This just returns our person object, signifying that we're done building.
class PersonBuilder {
constructor() {
this.person = {};
}
withName(name) {
this.person.name = name;
return this;
}
withAge(age) {
this.person.age = age;
return this;
}
build() {
return this.person;
}
}
Note that we return this in the withName and withAge methods--this returns the current instance, allowing us to continue to chain methods.
The implementation of our class ends up being something like this:
const person = new PersonBuilder()
.withName("Daffodil")
.withAge(25)
.build();
console.log(person);
// { name: "Daffodil", age: 25 }
And that's it, we now have a person object!
Why Build Objects This Way?
The fluent interface pattern can definitely be verbose, but one nice thing about it is that it makes it pretty hard to set an incorrect property on your object--you can only set object props by using the methods on your class. This can be especially handy if your object has a lot of properties, or if you need a handy way to generate a bunch of different objects to a specification (e.g., for test case generation).
Top comments (9)
Builder design pattern is definitely useful and widely used.
Personally, I think it's really easy to read.
I've never heard it called that before! I've always heard it referred to as the Builder Pattern. "Fluent" seems like a sensible name, though - you can use it for other things too (Knex, for example, uses it to build database queries).
I definitely find it really handy when there are a large number of optional elements, and also when the object in question is really complex.
I suppose the main downsides are 1) leaving your object in an unfinished state, and 2) perhaps making it harder to catch that at compile time (e.g., if you're using TypeScript or the like)?
Fantastic summary overall!
I haven’t seen that before and it does read nicely.
Nice, I tend to use this pattern more and more over time, it results in a really nice developer experience.
Thats really nice
Awesome as usual.
Thank you!
Where is the behavior of the created object?
In my opinion fluent is useful only for small objects.
For larger objects I prefer having class which describes all 'settings' and create a constructor for that.