Classes, Complexity, and Functional Programming

Obligatory semi-to-not-related header image via: https://unsplash.com/photos/sMQiL_2v4vs

When I use classes, when I don't, what I do instead, and why

When it comes to applications intended to last, I think we all want to have simple code that's easier to maintain. Where we often really disagree is how to accomplish that. In this blog post I'm going to talk about how I see functions, objects, and classes fitting into that discussion.

A class

Let's take a look at an example of a class implementation to illustrate my point:

1 class Person { 2 constructor ( name ) { 3 4 5 6 this . _name = name 7 this . greeting = 'Hey there!' 8 } 9 setName ( strName ) { 10 this . _name = strName 11 } 12 getName ( ) { 13 return this . _getPrefixedName ( 'Name' ) 14 } 15 getGreetingCallback ( ) { 16 const { greeting , _name } = this 17 return subject => ` ${ greeting } ${ subject } , I'm ${ _name } ` 18 } 19 _getPrefixedName ( prefix ) { 20 return ` ${ prefix } : ${ this . _name } ` 21 } 22 } 23 const person = new Person ( 'Jane Doe' ) 24 person . setName ( 'Sarah Doe' ) 25 person . greeting = 'Hello' 26 person . getName ( ) 27 person . getGreetingCallback ( ) ( 'Jeff' )

So we've declared a Person class with a constructor instantiating a few member properties as well as a couple of methods. With that, if we type out the person object in the Chrome console, it looks like this:

The real benefit to notice here is that most of the properties for this person live on the prototype (shown as __proto__ in the screenshot) rather than the instance of person . This is not insignificant because if we had ten thousand instances of person they would all be able to share a reference to the same methods rather than having ten thousand copies of those methods everywhere.

What I want to focus on now is how many concepts you have to learn to really understand this code and how much complexity those concepts add to your code.

Objects: Pretty basic. Definitely entry level stuff here. They don't add a whole lot of complexity by themselves.

Functions (and closures): This is also pretty fundamental to the language. Closures do add a bit of complexity to your code (and can cause problems if you're not careful), but you really can't make it too far in JavaScript without having to learn these. (Learn more here).

A function/method's this keyword: Definitely an important concept in JavaScript.

My assertion is that this is hard to learn and can add unnecessary complexity to your codebase.

The this keyword

Here's what MDN has to say about this :

A function's this keyword behaves a little differently in JavaScript compared to other languages. It also has some differences between strict mode and non-strict mode.

In most cases, the value of this is determined by how a function is called. It can't be set by assignment during execution, and it may be different each time the function is called. ES5 introduced the bind method to set the value of a function's > this > regardless of how it's called, and ES2015 introduced arrow functions whose this is lexically scoped (it is set to the this value of the enclosing execution context).

Maybe not rocket science 🚀, but it's an implicit relationship and it's definitely more complicated than just objects and closures. You can't get away from objects and closures, but I believe you can often get away with avoiding classes and this most of the time.

Here's a (contrived) example of where things can break down with this .

1 const person = new Person ( 'Jane Doe' ) 2 const getGreeting = person . getGreeting 3 4 getGreeting ( )

The core issue is that your function has been "complected" with wherever it is referenced because it uses this .

For a more real world example of the problem, you'll find that this is especially evident in React ⚛️. If you've used React for a while, you've probably made this mistake before as I have:

1 class Counter extends React . Component { 2 state = { clicks : 0 } 3 increment ( ) { 4 this . setState ( { clicks : this . state . clicks + 1 } ) 5 } 6 render ( ) { 7 return ( 8 < button onClick = { this . increment } > 9 You have clicked me { this . state . clicks } times 10 </ button > 11 ) 12 } 13 }

When you click the button you'll see: Uncaught TypeError: Cannot read property 'setState' of null at increment

And this is all because of this , because we're passing it to onClick which is not calling our increment function with this bound to our instance of the component. There are various ways to fix this (watch this free 🆓 egghead.io video 💻 about how).

The fact that you have to think about this adds cognitive load that would be nice to avoid.

How to avoid this

So, if this adds so much complexity (as I'm asserting), how do we avoid it without adding even more complexity to our code? How about instead of the object-oriented approach of classes, we try a more functional approach? This is how things would look if we used pure functions:

1 function setName ( person , strName ) { 2 return Object . assign ( { } , person , { name : strName } ) 3 } 4 5 6 function setGreeting ( person , newGreeting ) { 7 return Object . assign ( { } , person , { greeting : newGreeting } ) 8 } 9 10 function getName ( person ) { 11 return getPrefixedName ( 'Name' , person . name ) 12 } 13 14 function getPrefixedName ( prefix , name ) { 15 return ` ${ prefix } : ${ name } ` 16 } 17 18 function getGreetingCallback ( person ) { 19 const { greeting , name } = person 20 return subject => ` ${ greeting } ${ subject } , I'm ${ name } ` 21 } 22 23 const person = { greeting : 'Hey there!' , name : 'Jane Doe' } 24 const person2 = setName ( person , 'Sarah Doe' ) 25 const person3 = setGreeting ( person2 , 'Hello' ) 26 getName ( person3 ) 27 getGreetingCallback ( person3 ) ( 'Jeff' )

With this solution we have no reference to this . We don't have to think about it. As a result, it's easier to understand. Just functions and objects. There is basically no state you need to keep in your head at all with these functions which makes it very nice! And the person object is just data, so even easier to think about:

Another nice property of functional programming that I won't delve into very far is that it's very easy to unit test. You simply call a function with some input and assert on its output. You don't need to set up any state beforehand. That's a very handy property!

Note that functional programming is more about making code easier to understand so long as it's "fast enough." Despite speed of execution not being the focus, there are some reeeeally nice perf wins you can get in certain scenarios (like reliable === equality checks for objects for example). More often than not, your use of functional programming will often be way down on the list of bottlenecks that are making your application slow.

Cost and Benefit

Usage of class is not bad. It definitely has its place. If you have some really "hot" code that's a bottleneck for your application, then using class can really speed things up. But 99% of the time, that's not the case. And I don't see how class es and the added complexity of this is worth it for most cases (let's not even get started with prototypal inheritance). I have yet to have a situation where I needed class es for performance. So I only use them for React components because that's what you have to do if you need to use state/lifecycle methods (but maybe not in the future).

Conclusion

Classes (and prototypes) have their place in JavaScript. But they're an optimization. They don't make your code simpler, they make it more complex. It's better to narrow your focus on things that are not only simple to learn but simple to understand: functions and objects.

See you around friends!

Appendix

Here are a few extras for your viewing pleasure :)

The Module Pattern

Another way to avoid the complexities of this and leverages simple objects and functions is the Module pattern. You can learn more about this pattern from Addy Osmani’s “Learning JavaScript Design Patterns” book which is available to read for free here. Here’s an implementation of our person class based on Addy’s “Revealing Module Pattern”:

1 function getPerson ( initialName ) { 2 let name = initialName 3 const person = { 4 setName ( strName ) { 5 name = strName 6 } , 7 greeting : 'Hey there!' , 8 getName ( ) { 9 return getPrefixedName ( 'Name' ) 10 } , 11 getGreetingCallback ( ) { 12 const { greeting } = person 13 return subject => ` ${ greeting } ${ subject } , I'm ${ name } ` 14 } , 15 } 16 function getPrefixedName ( prefix ) { 17 return ` ${ prefix } : ${ name } ` 18 } 19 return person 20 } 21 22 const person = getPerson ( 'Jane Doe' ) 23 person . setName ( 'Sarah Doe' ) 24 person . greeting = 'Hello' 25 person . getName ( ) 26 person . getGreetingCallback ( ) ( 'Jeff' )

What I love about this is that there are few concepts to understand. We have a function which creates a few variables and returns an object — simple. Pretty much just objects and functions. For reference, this is what the person object looks like if you expand it in Chrome DevTools:

Just an object with a few properties.

One of the flaws of the module pattern above is that every person has its very own copy of each property and function For example:

1 const person1 = getPerson ( 'Jane Doe' ) 2 const person2 = getPerson ( 'Jane Doe' ) 3 person1 . getGreetingCallback === person2 . getGreetingCallback

Even though the contents of the getGreetingCallback function are identical, they will each have their own copy of that function in memory. Most of the time this doesn’t matter, but if you’re planning on making a ton of instances of these, or you want creating these to be more than fast, this can be a bit of a problem. With our Person class, every instance we create will have a reference to the exact same method getGreetingCallback :

1 const person1 = new Person ( 'Jane Doe' ) 2 const person2 = new Person ( 'Jane Doe' ) 3 person1 . getGreetingCallback === person2 . getGreetingCallback 4 5 person1 . getGreetingCallback === Person . prototype . getGreetingCallback 6 person2 . getGreetingCallback === Person . prototype . getGreetingCallback

The nice thing with the module pattern is that it avoids the issues with the callsite we saw above.

1 const person = getPerson ( 'Jane Doe' ) 2 const getGreeting = person . getGreeting 3 4 getGreeting ( )

We don’t need to concern ourselves with this at all in that case. And there are other issues with relying heavily on closures to be aware of. It’s all about trade-offs.

Private properties with classes

If you really do want to use class and have private capabilities of closures, then you may be interested in this proposal (currently stage-2, but unfortunately no babel support yet):

1 class Person { 2 #name 3 greeting = 'hey there' 4 #getPrefixedName = ( prefix ) => ` ${ prefix } : ${ this . #name } ` 5 constructor ( name ) { 6 this . #name = name 7 } 8 setName ( strName ) { 9 #name = strName 10 11 12 } 13 getName ( ) { 14 return #getPrefixedName ( 'Name' ) 15 } 16 getGreetingCallback ( ) { 17 const { greeting } = this 18 return ( subject ) => ` ${ this . greeting } ${ subject } , I'm ${ #name } ` 19 } 20 } 21 const person = new Person ( 'Jane Doe' ) 22 person . setName ( 'Sarah Doe' ) 23 person . greeting = 'Hello' 24 person . getName ( ) 25 person . getGreetingCallback ( ) ( 'John' ) 26 person . #name 27 person . #getPrefixedName

So we’ve got the solution to the privacy problem with that proposal. However it doesn’t rid us of the complexities of this , so I’ll likely only use this in places where I really need performance gains of class .

I should also note that you can use a WeakMap to get privacy for classes as well, like I demonstrate in the WeakMap exercises in the es6–workshop.

Additional Reading

This article by Tyler McGinnis called “Object Creation in JavaScript” is a terrific read.

If you want to learn about functional programming, I highly suggest “The Mostly Adequate Guide to Functional Programming” by Brian Lonsdorf, and (for those of you with a Frontend Masters subscription) “Functional-Lite JavaScript” by Kyle Simpson.