4 ms·

This is great and I will be moving my React projects in this direction. At very least this project represents a de-facto standard and guidance about how to work

This is great and I will be moving my React projects in this direction. At very least this project represents a de-facto standard and guidance about how to work with React. However I do wish the React team would pick between ES6 classes and `React.createClass`. I think I remember the main React tutorial was rewritten in ES6 at one point, but then switched back. I've read arguments both ways, but I suspect they ES6 is still too much of a barrier to entry. People who aren't up to speed with ES6 will still be shaving a lot of yaks before actually jumping into React.

lacker 10y ago
If you're using create-react-app then you're encouraged to use ES6 classes - that's how the default App.js is set up.
- danabramov 10y ago
  >However I do wish the React team would pick between ES6 classes and `React.createClass` We’re going with ES6 classes. Expect createClass() to go into another package some time this year. (Obviously we’ll provide an automated “codemod” utility to convert your existing code.)
  - anthonybullard 10y ago
    Please say it isn't so! Class is terrible syntactic sugar to please old Java programmers. I'd be really interested in why this decision would be made. Im just getting going in React and am looking to make a move away from Angular, because Angular 2 is so hyper focused on classes and decorators. I like React because it's closer on the purity scale to something like Cycle.js. But nevermind me, React is a great tool, and this is a very nice and needed project!
    - acemarke 10y ago
      React's lifecycle methods and other similar features require some kind of "object instance" to exist. Since React was created prior to ES6, the React team created their own "inheritance"-ish approach, which is something that every JS library out there was doing as well. One of the main arguments for classes being included in the ES6 standard is that it's a common approach that libraries can converge on and use together, rather than every library inventing their own version of inheritance. Since ES6+ is now the actual Javascript language standard, it makes sense for React to move away from their homegrown class definition approach, and build on top of the approach that is now standardized in the language. The React community has already eagerly adopted ES6, and while React.createClass() isn't going to be deleted any time soon, it's time to start encouraging people to move away from using it. Either way, though, React's API _does_ depend on having something "class"-like available.
      - danabramov 10y ago
        Exactly. We don't like classes, but we don't like "pseudo classes" (createClass) even more. Better the devil that's standardized. We already offer a way to create stateless components with just functions. We will keep exploring that space and eventually might have a class-less solution we like that satisfies all our use cases.
        shados 10y ago
        One thing though, is that the standard classes are just not up to the job without a lot of stuff tacked on. Eg: the function binding problem pushes people to use class properties, which aren't yet a standard, and then they hit walls with tools that don't support them (eg: I dunno if it's still the case, but for a while class properties caused issues with Flow). createClass might not have been the answer, but on top of stateless component functions, things like the good old ES3 module syntax honestly would be more flexible/powerful (giving you a closure to do things like private members, etc) Instead we have people using babel with all sorts of plugins, tacking on 3rd party decorators and utilities, and a bunch of other cruft just to mimic features JavaScript have had from the beginning. And then (talking out of my rear here), it possibly put pressure on the TC39 to waste time discussing features we seriously don't need.
        hex13 10y ago
        There was not such thing like ES3 module syntax. This is just programming pattern many people used: https://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternjavascript https://addyosmani.com/resources/essentialjsdesignpatterns/b... It was a great idea back then, but that was never syntax. This and similar patterns rely on the fact JavaScript is very dynamic and flexible language and enables creating closures and creating objects dynamically. These are very powerful features of language, but they're dynamic, which is unfortunate because to know what exactly is happening in this code you have to run it. for IDEs/editors it's hard to look at your code and guess "well, it's module pattern, I see! You mean this and that". Tooling operates usually on static analysis of syntax. They use JS parsers to parse code to AST(Abstract Syntax Tree). And here's the thing: ES6 classes are visible in AST, there is something called ClassDeclaration. This means that every programmer can install some ES6 parser from NPM and analyse ES6 classes. This means that there will be better linting, better autocompletion etc. On the other hand - JavaScript parsers don't understand module pattern or other homegrown idioms. It's harder to analyse them statically. Especially if they rely on dynamic aspects on language. ES6 parser doesn't run your code. That's why ES6 classes, because they're static, are better for parsers, and consequently, enable better tooling, IDE support, autocomplete etc. Situation maybe were a little bit different if we had tooling for some sort of dynamic analysis (if tools were running code in sandbox and gathered data in runtime, not from syntax etc.). But because currently most of tooling is syntax based I think ES6 classes (and e.g. ES6 modules) are just better for analysis. Well... to contradict what I said early I must say that actually it's often possible to analyse such things like module pattern, createClass etc. But: 1. not always with 100% certainty of the result 2. there are too many idioms. If every framework, every team and every programmer has own way of writing JS, own module syntax, own class syntax etc. it's very hard to support all the frameworks and provide tooling for all people...
    - hex13 10y ago
      Syntactic sugar? But `createClass` is a lot worse syntactic sugar than ES6 classes. React.createClass (and angular.directive or similar guerilla solutions) are harder to analyse statically. And without static analysis you won't have proper tooling (IDE autocompletion, "go to definition" feature, dependency graphs, linting etc.). So. Welcome language standards or goodbye static analysis. I'm seriously happy that both React and Angular go into ES6 classes and resign from guerilla coding...

lacker 10y ago

If you're using create-react-app then you're encouraged to use ES6 classes - that's how the default App.js is set up.

danabramov 10y ago
>However I do wish the React team would pick between ES6 classes and `React.createClass` We’re going with ES6 classes. Expect createClass() to go into another package some time this year. (Obviously we’ll provide an automated “codemod” utility to convert your existing code.)
- anthonybullard 10y ago
  Please say it isn't so! Class is terrible syntactic sugar to please old Java programmers. I'd be really interested in why this decision would be made. Im just getting going in React and am looking to make a move away from Angular, because Angular 2 is so hyper focused on classes and decorators. I like React because it's closer on the purity scale to something like Cycle.js. But nevermind me, React is a great tool, and this is a very nice and needed project!
  - acemarke 10y ago
    React's lifecycle methods and other similar features require some kind of "object instance" to exist. Since React was created prior to ES6, the React team created their own "inheritance"-ish approach, which is something that every JS library out there was doing as well. One of the main arguments for classes being included in the ES6 standard is that it's a common approach that libraries can converge on and use together, rather than every library inventing their own version of inheritance. Since ES6+ is now the actual Javascript language standard, it makes sense for React to move away from their homegrown class definition approach, and build on top of the approach that is now standardized in the language. The React community has already eagerly adopted ES6, and while React.createClass() isn't going to be deleted any time soon, it's time to start encouraging people to move away from using it. Either way, though, React's API _does_ depend on having something "class"-like available.
    - danabramov 10y ago
      Exactly. We don't like classes, but we don't like "pseudo classes" (createClass) even more. Better the devil that's standardized. We already offer a way to create stateless components with just functions. We will keep exploring that space and eventually might have a class-less solution we like that satisfies all our use cases.
      - shados 10y ago
        One thing though, is that the standard classes are just not up to the job without a lot of stuff tacked on. Eg: the function binding problem pushes people to use class properties, which aren't yet a standard, and then they hit walls with tools that don't support them (eg: I dunno if it's still the case, but for a while class properties caused issues with Flow). createClass might not have been the answer, but on top of stateless component functions, things like the good old ES3 module syntax honestly would be more flexible/powerful (giving you a closure to do things like private members, etc) Instead we have people using babel with all sorts of plugins, tacking on 3rd party decorators and utilities, and a bunch of other cruft just to mimic features JavaScript have had from the beginning. And then (talking out of my rear here), it possibly put pressure on the TC39 to waste time discussing features we seriously don't need.
        hex13 10y ago
        There was not such thing like ES3 module syntax. This is just programming pattern many people used: https://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternjavascript https://addyosmani.com/resources/essentialjsdesignpatterns/b... It was a great idea back then, but that was never syntax. This and similar patterns rely on the fact JavaScript is very dynamic and flexible language and enables creating closures and creating objects dynamically. These are very powerful features of language, but they're dynamic, which is unfortunate because to know what exactly is happening in this code you have to run it. for IDEs/editors it's hard to look at your code and guess "well, it's module pattern, I see! You mean this and that". Tooling operates usually on static analysis of syntax. They use JS parsers to parse code to AST(Abstract Syntax Tree). And here's the thing: ES6 classes are visible in AST, there is something called ClassDeclaration. This means that every programmer can install some ES6 parser from NPM and analyse ES6 classes. This means that there will be better linting, better autocompletion etc. On the other hand - JavaScript parsers don't understand module pattern or other homegrown idioms. It's harder to analyse them statically. Especially if they rely on dynamic aspects on language. ES6 parser doesn't run your code. That's why ES6 classes, because they're static, are better for parsers, and consequently, enable better tooling, IDE support, autocomplete etc. Situation maybe were a little bit different if we had tooling for some sort of dynamic analysis (if tools were running code in sandbox and gathered data in runtime, not from syntax etc.). But because currently most of tooling is syntax based I think ES6 classes (and e.g. ES6 modules) are just better for analysis. Well... to contradict what I said early I must say that actually it's often possible to analyse such things like module pattern, createClass etc. But: 1. not always with 100% certainty of the result 2. there are too many idioms. If every framework, every team and every programmer has own way of writing JS, own module syntax, own class syntax etc. it's very hard to support all the frameworks and provide tooling for all people...
  - hex13 10y ago
    Syntactic sugar? But `createClass` is a lot worse syntactic sugar than ES6 classes. React.createClass (and angular.directive or similar guerilla solutions) are harder to analyse statically. And without static analysis you won't have proper tooling (IDE autocompletion, "go to definition" feature, dependency graphs, linting etc.). So. Welcome language standards or goodbye static analysis. I'm seriously happy that both React and Angular go into ES6 classes and resign from guerilla coding...