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

81–90 of 209 posts

Re: React v15.5.0

#81

Post by linkmotif »

fiatjaf wrote: post #36
TheAceOfHearts wrote: post #29

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…

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.

Re: React v15.5.0

#82

Post by captain_crabs »

STRML wrote: post #26
acemarke wrote: post #11

For those who are interested in some of the details of the work that's going on, Lin Clark's recent talk on "A Cartoon Intro to Fiber" at ReactConf 2017 is excellent [0]. There's a number of other existing writeups and resources on how Fiber works [1] as well. The roadmap for 15.5 and 16.0 migration is at [2], and the follow-up issue discussing the plan for the "addons" packages is at [3]. I'll also toss out my usual…

I was in awe the entire time Lin was speaking. Not a single "um" or other verbal tic; she's an incredible speaker and was admirably lucid throughout that entire talk. That's so difficult to do. And style aside, she made understanding Fiber incredibly simple. Just wanted to express my admiration for her work and gratitude for making this information public, available, and free.

Your comment made me want to watch the video. And she does "uhh" at 3:50.

But I suck, this talk was great, she's a really good speaker, thanks for weirdly convincing me to watch this

Re: React v15.5.0

#83

Post by linkmotif »

raquo wrote: post #57
streptomycin wrote: post #23

Earlier quoted context omitted.

Flow is not a replacement for propTypes, they are complementary. Flow for compile-time errors, propTypes for runtime errors.

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

Let's not forgot prop type checks are removed during build (if you are building). So they don't happen in production. Like some kind of type erasure, but not :D.

Re: React v15.5.0

#84

Post by raquo »

streptomycin wrote: post #62
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.

Technically true, but how many projects actually are 100% typed, including: * absolutely no any types or other imprecise types, no files skipped, no lines skipped, etc * every single piece of external data (API requests, reading from localstorage/IndexedDB, etc) is explicitly validated to make sure it exactly conforms to expectations * all dependencies are also typed to the same standard (not just some type definitio…

You could make some of the same arguments against prop types - what if you miss them, what if they are incorrect (too narrow).

Regarding third party libraries, with prop types you are effectively writing your own bindings to the parts of those libraries that happen to go through your props, except you fail far away from where the error is produced.

Prop types are also a very ad-hoc solution to a very general problem. Why are props for UI components especially deserving of type checking? What about the rest of your application code? Event your components' state is not worthy of type checking?

With JS or typed-JS languages like Typescript or Flow you will never get full type safety (Flow is better at safety than TS if you're interested). For me the solution is to either go 80% of the way for 20% of the effort with those languages, or go full Scala.js or something that is actually type safe. And the latter has many goodies like https://github.com/lihaoyi/autowire to make API calls typed.

Re: React v15.5.0

#85

Post by spicyj »

YCode wrote: post #69
Rapzid wrote: post #3

Fiber is what I'm really waiting for. Not much official chatter about it, but looks like a 16 release? They just removed some addons in master that many third party packages rely on, including material-ui. Hopefully these other popular packages can be ready to go with the changes when the fiber release hits.

When I saw this post I immediately hit http://isfiberreadyyet.com/ and was sad it went back down to 92% :|

We added some more tests for server rendering (which Fiber doesn't yet support). Working on it though.

Re: React v15.5.0

#86

Post by spicyj »

ng12 wrote: post #65
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; }

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

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

Re: React v15.5.0

#87

Post by smdz »

I absolutely love how React+TypeScript setup handles PropTypes elegantly. And then you get the amazing intellisense automatically.

```

interface State {}

interface ISomeComponentProps {

  title: string;

  tooltip?: string

  ....
}

@ReduxConnected

export class SomeComponent extends React.Component {

....

```

Re: React v15.5.0

#88

Post by frik »

Silhouette wrote: post #55
spankalee wrote: post #39

Earlier quoted context omitted.

It's really time to start distributing ES6 via npm. All current browsers support ES6. It's now generally faster than equivalent ES5, it minifies better, tooling is better, etc. It's the app that should compile all the code to run in the target environment if needed. This is what we've done in the new Polymer CLI / polymer-build: we compile all dependencies but only if necessary.

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…

Many user are still on ES5/JS5 capable browser.

IE11, older FF and Chrome, and especially older mobile devices with older Webkit based browser (Android and iOS)

Re: React v15.5.0

#89

Post by debaserab2 »

Silhouette wrote: post #79
marcusarmstrong wrote: post #78

Earlier quoted context omitted.

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.

Yeah that's interesting. I might be biased since I'm in an exclusive B2B market.

Still though, it's hard to adopt a policy that axes even just 1% of your customer base just for the sake of easier development cycles when alternate options exist.

Re: React v15.5.0

#90

Post by sandGorgon »

dwg wrote: post #24
ggregoire wrote: post #4

For those still using propTypes, I'd recommend to take a look at Flow as replacement. https://flow.org/en/docs/frameworks/react

I agree, but for those considering using flow please beware that it's not a trivial undertaking. I recently converted a small app. There were several mind benders—beyond basic types, annotations can get pretty tricky—and the tooling isn't quite seamless. This is not to discourage you. You may well decide it's worth the effort.

Could you talk about what to watCh for ? We are looking to convert an app of our own as well.
Post reply on HN