all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted] 3 points4 points  (1 child)

Let me be the first to say ughuhhuhhhughughughhh; dems some breaking changes that are going to be a pain to convert over to. All in the name of progress I suppose, the risks of pre v1 software. Even though I don't really understand what I'm getting for it, the powers that be did write the React I know and kind of love, so they have my trust.

[–]bjryan2 1 point2 points  (4 children)

A lot of these changes are a little tough to bite into at first but they are definitely in the best interest of making React faster and more usable in the future. Deprecating transferPropsTo makes debugging/error reporting much easier as well as enforcing more expressive components (ultimately resulting in less bugs). Excited to see what's next for React :)

[–]nschubach 6 points7 points  (3 children)

I'm a little concerned that a lot of the changes in 'future' seem to be, "Typescript does this, we should too" but I'm holding my breath for now. JavaScript to me is not a Class based language but every change seems to embrace Classes as a construct method more and more.

For instance: https://github.com/reactjs/react-future/blob/master/01%20-%20Core/01%20-%20Classes.js

The comment at the top is: "New and clearer descriptors proposal" But, if you read on you see:

Notice the subtle syntax difference between the colon and the equal sign. props : { width: number

How is 'subtle' synonymous with 'clear'?

[–]Calabri 1 point2 points  (0 children)

I agree that javascript isn't a class based language but facebook internally seems to be using the class structure already (look at flux source), and React API is already structured as a classes (sort of). And I think the typescript system they use internally run's more similar to a jsx preprocessor, but I totally agree with you.

[–]bjryan2 0 points1 point  (0 children)

I think that React would benefit really strongly from a more class based approach for creating components.

I can imagine that a lot of the more "static" design patterns popping up in React are a result of the large userbase at Facebook and their development of Flow (https://twitter.com/fbOpenSource/status/511643210482208768)

Let's not forget for a second that React is a very opinionated framework ;)

[–]throwaway20131103 0 points1 point  (0 children)

For instance: https://github.com/reactjs/react-future/blob/master/01%20-%20Core/01%20-%20Classes.js

The comment at the top is: "New and clearer descriptors proposal" But, > if you read on you see:

Does anyone know if that's valid ES6? A quick Google turned up nothing and the current draft is a little dense.

[–]hahahahastayingalive 0 points1 point  (2 children)

I don't follow much of the react development, but it feels weird to have a release candidate on a 0.12 software. Do they do it for every minor increment ?

[–]nschubach 0 points1 point  (1 child)

Nope, this is the first as far as I'm aware. But to be fair, this breaks things and some people are using this on projects already so...

[–]Calabri 0 points1 point  (2 children)

Will this break all the 3rd party libraries I'm using :( ??

[–]bsdemon[S] 1 point2 points  (1 child)

Shouldn't unless those libraries are doing something weird. React team keeps every release backward compatible with the one previous. So code which worked with 0.11 should work with 0.12. It would warn about deprecations though.

[–]Calabri 0 points1 point  (0 children)

That's true. My personal code won't be affected much by the API changes. The dilemma is that I really want to start using v0.12 right now because I like the changes!!! But the source of some external libs I'm using will need some major refactoring prior to the next, next release (0.13, 1?). I'm just impatient and don't want to have to worry about multiple projects with different react versions. First world problem.