This is the RevealingModulePattern that Crockford used to advocate back in the day, except assigning to an object that React creates instead of one you create..
Be aware that memory usage can quickly balloon with this pattern, because the GC needs to keep alive anything referenced from inside the closure, including closure objects for the private methods for each individual instantiation of the component. With normal prototypal inheritance, there's only one function object per class; that's the upside of the explicit 'this'. This (and inability of early debuggers to inspect closure variables, which has since been fixed) were what killed this technique in the 2000s.
[Edit: parent post was edited to remove the code sample. I'll keep this up since apparently people are finding it informative, but be aware that I'm replying to the code sample that used to be in the parent comment, not anything in the article.]
Memory is not cheap for your users. If your webapp (or worse webpage) burns through their memory they will come to regard it as slow, bloated and heavy and close the tab never to return.
Care to add more to this? I've been doing javascript in some form or another for 10 years. We've always been able to do something "class like", but having actual real classes in ES6 is great. What is there not to like?
I think this is just a trope that JS devs and newbies have launched on to, and that it's without merit.
Classes are good. Classes express concrete taxonomies of concrete things in ways that most developers can understand.
I think we should be happy that JS is flexible enough that adding "class" to the language is almost purely syntactical: it clarifies and makes semantic a bunch of otherwise boilerplate "Foo.prototype.blah" code that you see in so many non-trivial JS apps.
There's nothing wrong with classes, they're just not right for JavaScript. I'm not going to claim that I'm a JS expert or anything, this is just something I've learned from pretty well established JS experts like Kyle Simpson and Douglas Crockford.
The reasons they give are that 1) you should favor composition and delegation over classical inheritance 2) classes keep you from using and understanding closure and other functional patterns and 3) you just get a lot of really weird behavior when trying to use classes in JS which results in a lot of confusion and wasted time, especially for those who don't have 10 years of experience under their belt.
It's worth noting that the React team promotes composition over inheritance, and discourages any levels of inheritance past `class MyComponent extends React.Component`.
Long term, the React team plans to investigate concepts like "stateful functional components", but until then, classes are the most straightforward way of having lifecycles. The existence of ES6 classes is based on the wide range of third-party "class" implementations across the JS ecosystem, so clearly there was a desire to have them available. Since they're available, React is using them.
I was responding to a comment saying "classes are a bad idea in JS in general". `React.createClass` is a homegrown implementation of classes, React.Component builds on ES6 classes, both would be disliked by Kyle Simpson or Douglas Crockford.
There are three major differences between `createClass` and React.Component:
- Autobinding
- Mixins
- Custom class system vs one that's built into the language
Autobinding is the most useful aspect, but there's a variety of ways to deal with it: use the Class Properties syntax and write methods as arrow functions, use one of the many autobind utilities in a constructor, write your own base class that extends React.Component and do autobinding in its constructor, etc.
Mixins are now a discouraged approach for writing React code. If you still want to use mixins in React components, there's some "compat component" classes on NPM, or you could use a non-React-specific method of applying mixins.
And finally, deprecating a custom class implementation means that it's one less thing the React team has to maintain, and the lib size is that much smaller.
To me, classes make more sense when you carry context with event binding, which components often do. It's syntax sugar over the Foo.prototype.* drivel, and I don't mind it...
That said, I tent to follow more functional patterns for workflows (prefer Redux and similar extension), but for some components the class syntax is usually nicer. Most components are probably best served as simple render methods though.
function App(params) { const component = new React.Component(params);