Skip to content

Add definitions for React 16.6's React.memo#29990

Closed
Jessidhia wants to merge 0 commit intoDefinitelyTyped:masterfrom
Jessidhia:react-16-memo
Closed

Add definitions for React 16.6's React.memo#29990
Jessidhia wants to merge 0 commit intoDefinitelyTyped:masterfrom
Jessidhia:react-16-memo

Conversation

@Jessidhia
Copy link
Copy Markdown
Member

@Jessidhia Jessidhia commented Oct 24, 2018

CI finally passes 🎉


  • Use a meaningful title for the pull request. Include the name of the package modified.
  • Test the change in your own code. (Compile and run.)
  • Add or edit tests to reflect the change. (Run with npm test.)
  • Follow the advice from the readme.
  • Avoid common mistakes.
  • Run npm run lint package-name (or tsc if no tslint.json is present).
    • It's broken locally? Error: Could not parse version: line is '// TypeScript Version: 2.8'
      • What is going on I have to abuse CI for tests because I can't run any testing locally
    • Fixed with: rm -rf node_modules types/*/node_modules && git clean -f -d

If changing an existing definition:

@typescript-bot typescript-bot added Popular package This PR affects a popular package (as counted by NPM download counts). Awaiting reviewer feedback labels Oct 24, 2018
@typescript-bot
Copy link
Copy Markdown
Contributor

typescript-bot commented Oct 24, 2018

@Kovensky Thank you for submitting this PR!

🔔 @johnnyreilly @bbenezech @pzavolinsky @digiguru @ericanderson @morcerf @tkrotoff @DovydasNavickas @onigoetz @theruther4d @guilhermehubner @ferdaber @jrakotoharisoa @pascaloliv @Hotell @franklixuefei - please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

If no reviewer appears after a week, a DefinitelyTyped maintainer will review the PR instead.

@plantain-00
Copy link
Copy Markdown
Contributor

@Kovensky Can you add static contextType in this PR? it's introduced in 16.6 too

@Jessidhia
Copy link
Copy Markdown
Member Author

@plantain-00 I actually wrote an issue about that because TypeScript doesn't support generics on the constructor type, which would be required for this.context to correctly get its type from static contextType: #29989

@Jessidhia
Copy link
Copy Markdown
Member Author

Jessidhia commented Oct 24, 2018

I assume the failures with TypeScript@next are related to microsoft/TypeScript#27627

EDIT: here's the bug: microsoft/TypeScript#27948

@typescript-bot
Copy link
Copy Markdown
Contributor

@Kovensky The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

@Jessidhia
Copy link
Copy Markdown
Member Author

I fixed things enough such that the tests for react itself now pass. However, other libraries that are making use of React.ComponentType will have a hard time adapting to TS@next's new overload resolution...... it's not something that can be fixed in react, has to be either fixed in TS@next or on the users themselves.

@typescript-bot
Copy link
Copy Markdown
Contributor

typescript-bot commented Oct 24, 2018

@Kovensky The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

@vagusX
Copy link
Copy Markdown
Contributor

vagusX commented Oct 24, 2018

@Kovensky would you like to add static getDerivedStateFromError in this PR?

    interface StaticLifecycle<P, S> {
        getDerivedStateFromProps?: GetDerivedStateFromProps<P, S>;
        getDerivedStateFromError?: GetDerivedStateFromError<S>;
    }

    type GetDerivedStateFromError<S> =
        /**
         * Receiving the error that was thrown as a parameter  and returns an update to a component's state.
         * This lifecycle is invoked after an error has been thrown by a descendant component.
         */
        (error: Error) => Partial<S> | null;

BTW, react 16.6 also includes some other features, would you implement all? Maybe I could help it out too.

@typescript-bot typescript-bot added the Other Approved This PR was reviewed and signed-off by a community member. label Oct 24, 2018
Comment thread types/react/index.d.ts
//
// We don't just use ComponentType or SFC types because you are not supposed to attach statics to this
// object, but rather to the original function.
interface ExoticComponent<P = {}> {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're introducing the concept of exotic components (components without statics, essentially), would it be a good idea to introduce ExoticComponent as one of the union types in React.ComponentType? To userland I believeComponentType and ReactType are all the "all-encompassing" types that can be used as JSX value-based components.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind, I just read up on microsoft/TypeScript#27948.

Copy link
Copy Markdown
Member Author

@Jessidhia Jessidhia Oct 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ExoticComponent does happen to be assignable to SFC so it does work as-is.

I wonder what I can do about memo and forwardRef, though... I could have a sub-interface with an extra type prop for memo, and extend LibraryManagedAttributes to check there.

As for forwardRef, it already does not support LibraryManagedTypes; I tried to look into ReactFiberBeginWork's code to see if it supports defaultProps, but the code path that does access defaultProps seems to be unreachable according to my limited understanding of Fiber. At any rate, even if it is reachable, it does happen to be looked up as a static added to the exotic component itself, so that'd have to be another subtype I guess.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's a static added to the exotic component itself, wouldn't it defeat the purpose of it being an exotic component, since that type was created to discourage adding statics to it? I guess it's a smaller subset of the statics allowed in vanilla components.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only forwardRef has that, though, not memo. They're more like subtypes of ExoticComponent.

Comment thread types/react/index.d.ts
*
* @deprecated Exotic components are not callable
*/
(props: P): (ReactElement<any>|null);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside: I'm surprised that this actually works with how the compiler resolves JSX value-based elements. I had thought that the return type of this call signature needs to be assignable to JSX.ElementClass, but I guess if the tests are passing, then it still works?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like an SFC signature to the compiler, so it's return value is only checked against JSX.Element | null.

Comment thread types/react/index.d.ts
? P
: {};

function memo<T extends ComponentType<any>>(
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both memo and forwardRef will break the LibraryManagedAttributes inference, since the static properties are not copied over. Is there any way we can preserve those when using these "HOC-like" functions?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to in my follow-up PR, but it seems LibraryManagedAttributes just don't work at all with non-class components, even if the type that JSX.LibraryManagedAttribute extracts is correct.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this still the case? AFAIK it should apply correctly to all components now.

Copy link
Copy Markdown
Contributor

@ferdaber ferdaber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me aside from the issues with the TSnext's new changes re: multiple call signatures for JSX tags.

@typescript-bot typescript-bot added the Owner Approved A listed owner of this package signed off on the pull request. label Oct 24, 2018
@Jessidhia
Copy link
Copy Markdown
Member Author

Jessidhia commented Oct 25, 2018

Yeah, the call signature thing will either be fixed on the TypeScript side, or those individual dependencies will have to all be updated and for them it'll likely be a breaking change.

I'll see if I can get LibraryManagedProps working with memo and forwardRef in a follow up PR to not block merging this one; same for adding the other new types.

I still don't know what to do with the new static variables and lifecycles though; it's not possible in TS to use generics in the constructor type itself. See #29989

@eljenso
Copy link
Copy Markdown

eljenso commented Oct 25, 2018

@Kovensky Would you consider including lazy and Suspense into this PR? See #30031

@Hotell
Copy link
Copy Markdown
Contributor

Hotell commented Oct 25, 2018

@eljenso
Copy link
Copy Markdown

eljenso commented Oct 25, 2018

@Hotell So we'll have to wait for TS 3.2 for these types to be merged?

@Hotell
Copy link
Copy Markdown
Contributor

Hotell commented Oct 25, 2018

"unfortunately" yes I think so @eljenso

@Jessidhia
Copy link
Copy Markdown
Member Author

Jessidhia commented Oct 25, 2018

I'm not sure why. The tests are already broken on master if react is tested at all. This PR actually reduces the breakage.

@typescript-bot
Copy link
Copy Markdown
Contributor

typescript-bot commented Nov 2, 2018

@Kovensky The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

@TimoWestland
Copy link
Copy Markdown

Any updates on this? :)

@vishnutsivan
Copy link
Copy Markdown
Contributor

Waiting for the merge :(

@johnnyreilly
Copy link
Copy Markdown
Member

We can't merge until we've a passing build I'm afraid. No doubt this will be solved but this is open source; people are doing this for ♥️ in their spare time. Please bear with them until they can.

@typescript-bot
Copy link
Copy Markdown
Contributor

typescript-bot commented Nov 8, 2018

@Kovensky The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

@TimoWestland
Copy link
Copy Markdown

Completely understand! Not trying to push, was just wondering about the status on this because all the todos were done so it wasn’t clear if there was any work left to do to get the build working. Thanks for the update! I’ll just keep watching this thread.

@weswigham weswigham closed this Nov 8, 2018
@weswigham weswigham reopened this Nov 8, 2018
@Jessidhia
Copy link
Copy Markdown
Member Author

Looks like a simple text fix remains, I'll do it once I'm at my computer 🎉

I think I'll also tone down a bit on the warning for the call signature, it annoyingly shows as if it was documentation even when the component is being used in JSX...

@typescript-bot typescript-bot added Merge:Express Has Merge Conflict This PR can't be merged because it has a merge conflict. The author needs to update it. and removed The Travis CI build failed labels Nov 9, 2018
@typescript-bot
Copy link
Copy Markdown
Contributor

@Kovensky Unfortunately, this pull request currently has a merge conflict 😥. Please update your PR branch to be up-to-date with respect to master. Have a nice day!

@Jessidhia
Copy link
Copy Markdown
Member Author

The other PR (#30054) which included all commits from this one too was merged 🎉

@Jessidhia Jessidhia deleted the react-16-memo branch November 9, 2018 06:44
@donaldpipowitch
Copy link
Copy Markdown
Contributor

@Kovensky Thank you very much!

@DanielRosenwasser
Copy link
Copy Markdown
Member

DanielRosenwasser commented Nov 9, 2018

@Kovensky just wanted to say thanks for all the awesome work you've done here on the React declarations on DefinitelyTyped! The last few weeks have likely been tiresome so I'm sure we all appreciate it.

@zaguiini
Copy link
Copy Markdown
Contributor

zaguiini commented Nov 9, 2018

If I lived near @Kovensky, I'd certainly pay her a beer!

@TimoWestland
Copy link
Copy Markdown

This is aweomse, @Kovensky. Thank you :)

@Hotell
Copy link
Copy Markdown
Contributor

Hotell commented Nov 19, 2018

arigato gozaimasu @Kovensky ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Has Merge Conflict This PR can't be merged because it has a merge conflict. The author needs to update it. Other Approved This PR was reviewed and signed-off by a community member. Owner Approved A listed owner of this package signed off on the pull request. Popular package This PR affects a popular package (as counted by NPM download counts).

Projects

None yet

Development

Successfully merging this pull request may close these issues.