5 ms·
React team is doing an amazing job. I remember when it was first announced, I thought Facebook was crazy. "JSX? That sounds like a bad joke!" I don't think I've
by TheAceOfHearts 10y ago
React team is doing an amazing job. I remember when it was first announced, I thought Facebook was crazy. "JSX? That sounds like a bad joke!" I don't think I've ever been so wrong. After hearing so much about React, I eventually tried it out and I realized that JSX wasn't a big deal at all, and in fact it was actually pretty awesome.
Their migration strategy is great for larger actively developed applications. Since Facebook is actually using React, they must have a migration strategy in place for breaking changes. Since breaking anything has such a big impact on the parent company, it makes me feel like I can trust em.
Heck, most of the items in this list of changes won't surprise anyone that's been following the project. Now there's less magic (e.g. React.createClass with its autobinding and mixins), and less React-specific code in your app (e.g. react-addons-update has no reason to live as a React addon when it can clearly live as a small standalone lib).
- fiatjaf 10y agoI still think JSX is a bad joke. Luckily React has nothing to do with it.
- fiatjaf 10y agoYeah, in the beggining there wasn't autobinding, if you remember well. Then comes autobinding, now there's no autobinding anymore.
- linkmotif 10y agoYeah I still use `React.createClass({})` because... autobinding. Also wish someone would explain the draw of ES6 classes. React is about composition, not inheritance. Have never seen a `React.Component` extended.
- fiatjaf 10y agoI've seen one. It is the horror, the horror.
- acemarke 10y agoSee my comment downthread regarding intended use of React.Component: https://news.ycombinator.com/item?id=14065106 https://news.ycombinator.com/item?id=14065106 .
- linkmotif 10y agoThanks. I responded there.
- cormacrelf 10y agoBasically nobody does this, as far as I know. I think some of the big component authors like Wijmo do, but not most people, it's way too messy. The composition is usually in the form of higher order components. It's very simple to wrap a function with another one, with more or different functionality. Classes just make it equally as simple when the wrapped component has its own state to manage. Point is, nobody really cares whether they're ES6 or createClass, because nobody's actually doing inheritance. It's just that we JS devs like to stay on the bleeding edge, and we like to think that we're converging on standards even if that's a silly dream. Example: show a spinner for 1 second before displaying. const F = (props) => <div>{props.content}</div>; class C extends React.Component { state = { initial: "state" }; render = () => <div>{this.state.initial}</div>; } function delayWithSpinner(WrappedComponent) { return class extends React.Component { state = { showSpinner: true }; stop = () { this.setState({ showSpinner: false }); } render() { return this.state.showSpinner ? <Spinner duration={this.props.duration} onCompletion={this.stop}/> : <WrappedComponent {...this.props}/> } } } // exactly the same composition pattern for // both classes and functions. const SlowC = delayWithSpinner(C); const SlowF = delayWithSpinner(F);
- boubiyeah 10y agoES6 classes are a complete mess brought by corporate people loving OO, even in a setting that doesn't make sense. You can "autobind" with this notation: myMethod = () => { } but it doesn't look as good as myMethod() {} and you have to remember this EVERY TIME you add a method. Also, you never need to use the constructor in React. Just do: state = {} in the body of the class. You may need babel presets #918718$$&ééàdi for it to work though.
- zdragnar 10y agoClasses and inheritance are features of type systems, not OOP. Plenty of functional programming JS libraries use classes for testing types (for example, the Either monads' Left and Right).
- paulddraper 10y agoClasses and class inheritance are features of class-based systems, yes. Prototypes and prototype inheritance are features of prototype based systems.
- icc97 10y agoReact themselves say they never use it [0] > At Facebook, we use React in thousands of components, and we haven't found any use cases where we would recommend creating component inheritance hierarchies. [0]: https://facebook.github.io/react/docs/composition-vs-inheritance.html#so-what-about-inheritance https://facebook.github.io/react/docs/composition-vs-inherit...
- crgwbr 10y agoWe have a fairly large react codebase with some components using inheritance. It's not the solution to every problem certainly, but sometimes an abstract base component can be useful.
- ng12 10y agoAgreed 100% about JSX. Especially since the only alternative anyone uses is opaque stringly-typed template nonsense (Angular, Vue, Ember, etc).
- boubiyeah 10y agoHumm no, JSX is just a DSL. I much, much prefer virtual DOM over String templates but I also prefer hyperscript over JSX: h('div')
- zdragnar 10y agoJSX is a macro (it's expended to plain JS at compile time). Almost every other major framework uses DSLs (strings are evaluated and transformed into code at run time).
- mnutt 10y agoI'm not sure ember's HTMLBars (the default, a drop-in replacement for handlebars) is any more stringly-typed than JSX.
- enraged_camel 10y agoI use single-page components in Vue and write templates like this: <template> <div> <h2>{{ title }}</2> </div> <template> <script> export default { data() { return { title: "Hello world" } } } </script> Works well in my opinion. Separates the template into its own section but keeps it inside the same file.
- ng12 10y agoIn my mind this is strictly inferior to JSX, which would be: export default ({title}) => ( <div> <h2>{title}</h2> </div> ) The only benefit to the template is if you use fancy features (#each, binding, etc) which is worse because now you have two places where the logic happens.