Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React v15.5.0

facebook.github.io

Post reply on HN
Print view View original

71–80 of 209 posts

Re: React v15.5.0

#71

Post by gavinpc »

thatswrong0 wrote: post #48
nodesocket wrote: post #2

Big news seems to be removal of `React.createClass()` in favor of: class HelloWorld extends React.Component { }

Mild rant: I'm not convinced ES6 classes are better than components created the old way. First, the lack of autobinding callback functions for child props is not ideal. I don't even have to think about it with createClass, and it requires at least one extra step with ES6. It's less convenient. Second, I don't think HOCs are necessarily easier to reason about than mixins in many situations. React is already quite defi…

I felt the same way and avoided `class` for mostly the same reasons.

For better or worse, there are many ways to make pseudo-classes using Javascript. Is prototype configurable? Writable? Enumerable? What about the properties of prototype? Are they configurable? Enumerable? Writable? And there are still people who clobber the default prototype, killing its `constructor` and changing the above.

And that's just one level. When it comes to calling super constructors and super methods, things get much wilder.

I've come to terms with the view that ES6 classes are just a way for us to move on with our lives. We do a common thing in a common way, and never think for a second about what subclassing approach to use, what method is compatible with what other method, and whether it's implemented correctly.

Yes, you need a build step to target older browsers. But you needed a dependency anyway, to support whatever ad-hoc method you were using.

I never used mixins, but I agree that HoC's present a special problem for testing.

Re: React v15.5.0

#72

Post by gedy »

swalsh wrote: post #54
baron816 wrote: post #43

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; }

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?

There's a functional programming clique in JS that dislikes it.

Re: React v15.5.0

#73

Post by xamuel »

YCode wrote: post #68
xamuel wrote: post #60

Happy to see propTypes getting shelved. Too many people stubbornly use propTypes even in Typescript projects. Hopefully this change will usher in the final stamping out of that.

What's wrong with propTypes?

In a non-Typescript project, they're a shoddy half-baked type system duct-taped together. In a Typescript project, they're almost completely redundant, they add a huge maintenance burden for basically no gain.

Re: React v15.5.0

#74

Post by tlrobinson »

PudgePacket wrote: post #51

Why do React and other js libraries emit warnings as console.error when browsers support console.warn?

console.warn in most (all?) browsers' dev tools didn't/doesn't provide the full stack trace.

I think that changed recently in Chrome, at least.

Re: React v15.5.0

#75

Post by tlrobinson »

thatswrong0 wrote: post #48
nodesocket wrote: post #2

Big news seems to be removal of `React.createClass()` in favor of: class HelloWorld extends React.Component { }

Mild rant: I'm not convinced ES6 classes are better than components created the old way. First, the lack of autobinding callback functions for child props is not ideal. I don't even have to think about it with createClass, and it requires at least one extra step with ES6. It's less convenient. Second, I don't think HOCs are necessarily easier to reason about than mixins in many situations. React is already quite defi…

If you don't want to think about binding, just use the arrow function syntax:

    class Foo extends Component {
      bar = () => {
        // ...
      }
    }

Re: React v15.5.0

#76

Post by Silhouette »

debaserab2 wrote: post #59
Silhouette wrote: post #55

Earlier quoted context omitted.

All current browsers support ES6. That's debatable, particularly when you factor in bugs. However, even if they did, it seems unwise to assume that all relevant users for all or even most projects will be on the latest evergreen browsers. Several large groups, including business users on IE and mobile users on slightly older devices, probably won't be. I know there's a certain type of web developer who would love for…

This is a common theme I'm noticing a lot lately. Meanwhile, I check my product's browser breakdown and IE9/10 is still too significant to ignore. There's just no way our customers would be okay with this. Many are still locked on older IE versions due to (bad) corporate policies. I can't strongarm them into upgrading. Which leads me to wonder: are developers that are so willing to advocate breaking compatibility wit…

I'm afraid this culture is now endemic in web development. Everyone expects everything to be free, so the people building most of the tools, from the libraries to the browsers themselves, are mostly either doing it for fun as an amateur or doing it professionally in order to support something that does bring in revenues. Neither of these necessarily implies writing or maintaining ideal tools to support web development more widely; any wider benefit is largely coincidental. Unfortunately, because so much of the influence is now concentrated with so few organisations or even individual people, and most of them are aligned on this, it's going to be difficult to return to a more widely supportive ecosystem now.

Re: React v15.5.0

#77

Post by whitefish »

I'd like to see React support shadow-dom and web components. Not holding my breath however, since Facebook considers web components to be a "competing technology".

Unlike real web components, React components are brittle since React does not have the equivalent of Shadow DOM.

Re: React v15.5.0

#78

Post by marcusarmstrong »

debaserab2 wrote: post #59
Silhouette wrote: post #55

Earlier quoted context omitted.

All current browsers support ES6. That's debatable, particularly when you factor in bugs. However, even if they did, it seems unwise to assume that all relevant users for all or even most projects will be on the latest evergreen browsers. Several large groups, including business users on IE and mobile users on slightly older devices, probably won't be. I know there's a certain type of web developer who would love for…

This is a common theme I'm noticing a lot lately. Meanwhile, I check my product's browser breakdown and IE9/10 is still too significant to ignore. There's just no way our customers would be okay with this. Many are still locked on older IE versions due to (bad) corporate policies. I can't strongarm them into upgrading. Which leads me to wonder: are developers that are so willing to advocate breaking compatibility wit…

For whatever my anec-data is worth, I run a sports stats website as a hobby (which has a decidedly non-developer user base), and when looking at my own user breakdown I found that less than .1% of my traffic was IE10 or below.

So while there's still likely an insular group at play, it's not limited to just developers.

Re: React v15.5.0

#79

Post by Silhouette »

marcusarmstrong wrote: post #78
debaserab2 wrote: post #59

Earlier quoted context omitted.

This is a common theme I'm noticing a lot lately. Meanwhile, I check my product's browser breakdown and IE9/10 is still too significant to ignore. There's just no way our customers would be okay with this. Many are still locked on older IE versions due to (bad) corporate policies. I can't strongarm them into upgrading. Which leads me to wonder: are developers that are so willing to advocate breaking compatibility wit…

For whatever my anec-data is worth, I run a sports stats website as a hobby (which has a decidedly non-developer user base), and when looking at my own user breakdown I found that less than .1% of my traffic was IE10 or below. So while there's still likely an insular group at play, it's not limited to just developers.

Stats for older IE versions are similar for most sites/apps I'm involved with, though I know in some niches they are still important.

IE11 is a different case entirely, though. Almost everything still gets significant traffic on that platform, and in the business world supporting it is pretty much essential. Not much ES6 support there, though.

Re: React v15.5.0

#80

Post by raquo »

untog wrote: post #66
raquo wrote: post #57

Earlier quoted context omitted.

It is though. Runtime type validation is just a clutch that's needed when you don't have compile time validation.

Not necessarily - you could be parsing a JSON API response or something.

If you don't trust your JSON input to be of proper type, you should validate its type immediately when you receive it, before you start fanning it out to your code. Spreading this work to prop types just makes it harder to keep track of it, and harder to find the source of the problem.

Besides, some of that broken JSON data might never even be passed through proptypes (e.g. if that data lives only in a component's state).

Also, there are compile-time solutions to this in some compile-to-JS languages, e.g. like https://github.com/lihaoyi/autowire for Scala.js

Post reply on HN