function App(params) { const component = new React.Component(params);
component.lifeCycleMethod = function() {...};
component.render = function() {...};
function privateMethod() {...}
return component;
}http://javascript.crockford.com/private.html
https://addyosmani.com/resources/essentialjsdesignpatterns/b...
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.]
I'm pretty sure Crockford still pushes this. https://weblogs.asp.net/bleroy/crockford%E2%80%99s-2014-obje...
It does eat up more memory, but as Crockford says, memory is cheap. It's not likely that it'll cause a problem.
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.
Classes simplify things IMO.
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.
Edit: Here's Simpson's take: https://github.com/getify/You-Dont-Know-JS/blob/master/this%...
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.
Huh? Why? React.createClass({}) is/was pretty straightforward. What is more straightforward about classes? All I see is more code.
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.
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.