121–130 of 209 posts
Big news seems to be removal of `React.createClass()` in favor of: class HelloWorld extends React.Component { }
It's sad to see how new generation can't learn lessons of the past.
I mean, creating a new type of brush for painters is ok, but I don't see the need for forcing them to redo their old paintings with the new type of brush in order to keep them visible..
IMHO Coffeescript and some other to Javascript transpilers are still a much better language than the entire Babel ES5/ES6/ES7 thing. But for some reason my free choice here is in jeopardy. The community apparently has chosen for Babel and are now happily nihilating things that are not compatible with that.
In my opinion this is not only irresponsible, but very arrogant as well.
Although I do understand and can write higher order components, I still write and use small mixins in projects because it works for me. I also use createClass because I enjoy the autobinding and don't like the possibility to forget calling super.
Now I need to explain my superiors why this warning is shown in the console, making me look stupid using deprecated stuff. And I need to convince them why I need to spend weeks rewriting large parts of the codebase because the community thinks the way I write is stupid. Or I can of course stick to the current React version and wait until one of the dependencies breaks.
It would be really great if library upgrades very, very rarely break things. Imagine if all the authors of the 60+ npm libs I use in my apps are starting to break things this way, for me there is no intellectual excuse to justify that.
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…
Agreed 100% about JSX. Especially since the only alternative anyone uses is opaque stringly-typed template nonsense (Angular, Vue, Ember, etc).
What is this problem in the Javascript landscape to keep forcing developers to do things differently, with the penalty of your app not working anymore if you don't comply? I mean, creating a new type of brush for painters is ok, but I don't see the need for forcing them to redo their old paintings with the new type of brush in order to keep them visible.. IMHO Coffeescript and some other to Javascript transpilers are…
And I believe there should be a better way to prepare your users for a major version upgrade (React 15 -> 16) than to update the current branch with all kinds of deprecation warnings. Even if a library - as popular as React - doesn't plan to provide lifetime support for any major because they like to to move fast, I understand that, it's simply not okay to ruin older branches this way, madly assuming everyone is surely going to upgrade to React 16 in the immediate future.
Ideally, I'd imagine there could be a separate optional package that adds these warnings dynamically. If that's not possible technically, then an optional build flag would be nice. Or two separate releases: react-15.5.0 and react-15.5.0-upgrade-support. Even better: go back to semver, and treat major upgrades as optional for the first 6 months. This allows other libraries like routers and style libs to catch up, so app devs can upgrade even more smoothly.
Maybe after all, DX is about when to provide helpful errors and warnings. And when not to?
Earlier quoted context omitted.
Yeah, in the beggining there wasn't autobinding, if you remember well. Then comes autobinding, now there's no autobinding anymore.
Yeah 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.
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.
Earlier quoted context omitted.
Yeah, in the beggining there wasn't autobinding, if you remember well. Then comes autobinding, now there's no autobinding anymore.
Yeah 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.
> 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-inherit...
For those still using propTypes, I'd recommend to take a look at Flow as replacement. https://flow.org/en/docs/frameworks/react
(Unfortunately it's not working with React Native, but I hope that's fixed soon: https://github.com/brigand/babel-plugin-flow-react-proptypes...)
EDIT: Thanks to namuol, I just discovered flow-runtime: https://codemix.github.io/flow-runtime
This looks amazing!
EDIT 2: flow-runtime also doesn't work with React Native: https://github.com/codemix/flow-runtime/issues/17
That's a shame. I might see if I can fix it, otherwise I'll just stick with compile-time checks for now.
For those still using propTypes, I'd recommend to take a look at Flow as replacement. https://flow.org/en/docs/frameworks/react
Flow’s interesting, unfortunately it requires more invasive changes to your code than just prop types. For example, if I remember correctly, you need a declaration for a class component’s state.
For those still using propTypes, I'd recommend to take a look at Flow as replacement. https://flow.org/en/docs/frameworks/react
Earlier quoted context omitted.
We use Flow everywhere now and love it. It's not perfect by any means but it's a lot easier to use than Java's static typing and a lot more expressive to boot. I can't overstate how great it is to be able to strongly type your modules and ensure you don't send the wrong input or receive the wrong input from them. In fact, Flow allows us to confidently implement APIs that would just be cumbersome otherwise; we can use…
> This has the incredible effect of making it a type error if you try to execute an action that doesn't exist. I don't want to start a "JavaScript is bad" flamewar, but it's sad that there is an entire class of problems that we as software developers are solving, where simple type checking seems amazing