Re: deprecated, I think remove - it's embracing the inevitable. If people shout we could look at adding back.

I favour breaking up the tests but I don't really mind. Monolithic is fine.

For now, I'm thinking you should move the old v0.13 definitions to a separate legacy folder instead of overwriting them.

I'm also for splitting the tests.

For now, I'm thinking you should move the old v0.13 definitions to a separate legacy folder instead of overwriting them.

I actually meant to put that under "Questions". We did that with v0.12, it makes sense to me as well.

I favour breaking up the tests but I don't really mind
I'm also for splitting the tests.

One "gotcha" with the tests is #6125. Essentially if we want to split and also test both the module and the global version, we'd wind up with N modules * 2 which here = 20 test files. If we split should we forego testing the global version? Or should we just suck it up and have 20 test files? Or some other solution that I'm (hopefully) missing.

@jbrantly , in this case it's probably overkill. All addons in a single file (x2) should be fine.

I think that we should remove the deprecated items as well. @jbrantly, what is the best way to help out?

what is the best way to help out?

I've given you collab access to my fork so you can push to this PR if you want. Feel free to take anything on the list, I haven't had a chance to do anything more yet.

Thanks!

I just rebased on top of master to pull in #6236. I'm going to start working on some of the various items that were commented on.

I've addressed the various comments in the thread so far:

• Removed cloneWithProps @johnnyreilly @pspeter3
• Now exporting the type as well as the variable for CSSTransitionGroup, TransitionGroup, PureRenderMixin and LinkedStateMixin. @use-strict
• Added legacy files for v0.13 @use-strict
• Fix minor naming issue @pspeter3

Plenty of stuff still left to do though.

Good work!

👍

travis ci failed. please merge master into this branch.

@vvakame This is still a WIP and the tests haven't been updated yet 😄 That's why travis is failing. I'll ping when everything is done and ready to be merged.

I'm curious about how we're going to do stateless function components. They don't seem like they would have an obvious type signature except for <T extends React.Props<any>>(props: T) => React.ReactElement<any>. Do people agree?

@pspeter3 According to this ticket, it doesn't look like function components are going to be supported by TypeScript yet: microsoft/TypeScript#4861

@dallonf Thanks for that link. I've been meaning to open that issue for the longest time but never got around to it. I'm glad to see someone else already did it.

@pspeter3 That seems right to me. I think the main thing will be updating createElement to accept them as component types.

@dallonf FWIW I intend to address microsoft/TypeScript#4861 this week

@RyanCavanaugh that is excellent news! Looking forward to it.

valueLink support should also be added to HTMLAttributes to support LinkedStateMixin.

@jbrantly looks like we're done with the remaining tasks except for CSSTransitionGroup updates and testing. I've already been adding tests as I go. Do you know what still needs to be tested?

@vsiao Awesome! I just finished up the CSSTransitionGroup update and also fixing dependency tests. My "Test, test, test" comment was more about upgrading real-world applications and not so much the unit tests, but I'm not sure if that's practical. I've removed that item.

There is only one remaining item I think related to the valueLink changes and the material-ui definitions (see my comment on 813f3b0).

Done! Passing tests finally 😄

OK! I think everything is done and ready to be merged!

@vvakame

Merged - well done!

Thanks for driving this @jbrantly

Thanks to everyone involved. Very much appreciated.

Yup, thanks to everyone who contributed with code or comments!

Thank all of you so much for all your hard work on this!

thanks all 🌟 will start testing these definitions soon!

Amazing work, thank you so much everyone!

Thank you for the great work!

Thanks all for your hard work on this. We've been using these while they have been in progress, and so far no problems at all.

I have an issue using ES6 module syntax in TypeScript/Visual Studio 2013.

import * as update from 'react-addons-update';

error: "Module react-addons-update resolves to a non-module entity and cannot be imported using this construct"

import update = require('react-addons-update');

No error. Do I have to use this syntax? I'm using es6 syntax everywhere else. :(

tl;dr: you have to use import ... = require(...) in this case.

import ... from ... is used for importing ES6 modules. import * as ... usually works with most commonjs because it translates to using the exports object. However, there is no equivalent to module.exports = construct in the ES6 spec. Even the default export ends up as an export.default = ... and you cannot override the exports object.

type ReactInstance = Component<any, any> | Element is wrong. Trying to accessing any Element's property gives me a compilation error:

this.refs['refname'].scrollHeight // error TS2339: Property 'scrollHeight' does not exist on type 'Component<any, any> | Element'.

This happening because of typescript union type spec:

The type A|B has a property P of type X|Y if A has a property P of type X and B has a property P of type Y.
(from Properties section)

Instead of using union type, there should be intersection type, which completely fits to this case:

The type A & B has a property P if A has a property P or B has a property P.
(from Properties section)

So, there should be type ReactInstance = Component<any, any> & Element