A curated list of resources on why ES6 (aka ES2015) classes are NOT awesome
DISCLAIMER: This is an opinionated summary of the core points made throughout the linked content. I am only providing this as a convenience for people who requested it. If you're looking for technical depth, skip this section. Please, take the time to dive into the content before drawing any conclusions.
If a feature is sometimes dangerous, and there is a better option, then always use the better option. — Douglas Crockford
class: Composable Factory Functions Are Here
I'm not convinced that using ES6 class syntax in this fashion is the best long term solution for React, and you should be aware of the alternatives: React.createClass(), react-stamp, and pure (stateless) functions. However, Dan has established a solid, reasonable set of guidelines to follow in the meantime. So, if you must use ES6 classes in React, please follow his lead:
With that said, we should think about why needing to use
extends in such a limited fashion, to establish sane & maintainable practices for the specific purpose of creating a React Component (through 1-level deep inheritance), is necessary in the first place. It probably means that there should be a better solution and/or a better syntactical approach to solving this problem. I’d like to see a syntax focusing on what the conceptual thing actually is, i.e., a component, not a class… Why was createClass() not originally named createComponent()? Why do we think that classes are the right tool for modeling components in the first place?
Also, read Dan's previous article on composition:
Currently, it is not all that practical to completely avoid using ES6 classes in React due to the fact that functional components lack the lifecycle methods of ES6 class components (or the deprecated
createClass factory function). However, it is possible to avoid them by using Andrew Clark's recompose, a React utility belt for function components and higher-order components. Using recompose, you are able to use methods like
shouldComponentUpdate, etc. with functional components via the
lifecycle helper utility. However,
lifecycle currently uses React's
createClass under the hood, and many of recompose's other API methods are implemented using classes... So, you will probably still be using them if you use recompose in your project, depending on the specific methods you are using. However, they will be abstracted away from the code you are writing, which you might still find nice enough to consider.
Otherwise, if you are willing to abandon React compatibility & a React-like API altogether, look into snabbdom, a virtual DOM library focused on simplicity, modularity, & performance. Like Inferno, Snabbdom is extremely fast and features a powerful hooks API. Also, if you are a fan of JSX, you can keep using it via snabbdom-jsx. You may be surprised how similar what you can accomplish when using a minimal virtual DOM library is to when using a larger view library like React, especially if you are already heavily using a state container like Redux.
Since writing this not-awesome-list I've really jumped into learning functional programming core concepts/principles, and, honestly, I don't really use prototypal inheritance or object composition anymore either, because I really believe FP is the way to go. However, I do still think that if you're going to do OOP in JS, then using prototypes & the OLOO (Objects Linked to Other Objects) concept + object composition is a much better idea than emulating Java with class syntax, the constructor pattern, & inheritance. Embrace simple! OO composition is better than classical inheritance by a long shot, but functional composition is even better.
HOWEVER, I am mostly referring to application code when I suggest embracing simplicity by avoiding classes and OOP. I'm not saying that you should NEVER use ES6 classes or that there aren't any good use cases for them. The nature of V8 and other JS engines is that object-oriented code can often be better optimized. So, it's perfectly acceptable to use classes and an OO style to squeeze out as much performance as possible when writing the internals of a library. You have a good reason to do so in that case, BUT you can abstract away those details and make it so that the library's public API (and your application code when using said library) can be elegant and declarative. This is important for maintainability. Rigorous, consistent functional code lends itself to better understanding, and, thus, better long term maintainability. If micro-optimizations must be done in libraries for performance reasons, then so be it, but the power of abstraction allows you to hide imperative and/or OO code away from the user, saving them the headache of having to break out of a functional coding style in their apps.
I have also seen a number of people choosing to use ES6 classes as an abstraction to implement Algebraic Data Type libraries, and I understand why they do. It does seem like a logical choice when building out the methods of each data type to satisfy the various laws involved that define these algebraic structures. However, some of these libraries will provide a functional API via wrapper functions and not publicly expose each data structure's methods directly. I strongly prefer libraries that do this, or at least make the functional API variants ALSO available along with the method-based API, because it allows taking advantage of further FP techniques, like currying & partial application, which is very important for creating reusable functions.