9 ms·

I hate that the React team prefers ES6 classes. This is what I do: function App(params) { const component = new React.Component(params); component.lifeCyc

I hate that the React team prefers ES6 classes. This is what I do: function App(params) { const component = new React.Component(params); component.lifeCycleMethod = function() {...}; component.render = function() {...}; function privateMethod() {...} return component; }

nostrademons 10y ago
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.. http://javascript.crockford.com/private.html http://javascript.crockford.com/private.html https://addyosmani.com/resources/essentialjsdesignpatterns/book/#revealingmodulepatternjavascript 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.]
- baron816 10y ago
  Sorry, I was getting down voted a lot. I restored the code. I'm pretty sure Crockford still pushes this. https://weblogs.asp.net/bleroy/crockford%E2%80%99s-2014-object-creation-pattern 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.
  - asdfgadsfgasfdg 10y ago
    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.
swalsh 10y ago
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?
- jschrf 10y ago
  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. Classes simplify things IMO.
  - baron816 10y ago
    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. Edit: Here's Simpson's take: https://github.com/getify/You-Dont-Know-JS/blob/master/this%20%26%20object%20prototypes/apA.md https://github.com/getify/You-Dont-Know-JS/blob/master/this%...
    - acemarke 10y ago
      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.
ng12 10y ago
Oh god why. This is like Google Closure code, which is terrible to maintain even at it's most idiomatic.
- spicyj 10y ago
  On the contrary, I normally see Closure code written with prototypes in a very OO style.

nostrademons 10y ago

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.. http://javascript.crockford.com/private.html http://javascript.crockford.com/private.html https://addyosmani.com/resources/essentialjsdesignpatterns/book/#revealingmodulepatternjavascript 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.]

baron816 10y ago
Sorry, I was getting down voted a lot. I restored the code. I'm pretty sure Crockford still pushes this. https://weblogs.asp.net/bleroy/crockford%E2%80%99s-2014-object-creation-pattern 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.
- asdfgadsfgasfdg 10y ago
  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.

swalsh 10y ago

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?

jschrf 10y ago
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. Classes simplify things IMO.
- baron816 10y ago
  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. Edit: Here's Simpson's take: https://github.com/getify/You-Dont-Know-JS/blob/master/this%20%26%20object%20prototypes/apA.md https://github.com/getify/You-Dont-Know-JS/blob/master/this%...
  - acemarke 10y ago
    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.

ng12 10y ago

Oh god why. This is like Google Closure code, which is terrible to maintain even at it's most idiomatic.

spicyj 10y ago
On the contrary, I normally see Closure code written with prototypes in a very OO style.