Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

react/prop-types incompatible with flow variance syntax #961

Closed
ajhyndman opened this issue Nov 17, 2016 · 4 comments
Closed

react/prop-types incompatible with flow variance syntax #961

ajhyndman opened this issue Nov 17, 2016 · 4 comments

Comments

@ajhyndman
Copy link
Contributor

Flow introduced variance syntax in 0.34.0. This seems to have introduced a bug when component prop-types are explicitly flagged.

This code is flagged as incorrect:

import React from 'react';

type Props = {
  +value: string;
};

const Component = (props: Props) => (
  <div data-value={props.value} />
);

image

Versions:

"babel-core": "^6.18.2",
"babel-eslint": "^7.1.0",
"eslint": "~3.6.0",
"eslint-plugin-react": "^6.7.1",
"eslint-plugin-flowtype": "^2.25.0",
@ljharb
Copy link
Member

ljharb commented Nov 17, 2016

Can you elaborate what +value: string means in flow?

@ajhyndman
Copy link
Contributor Author

ajhyndman commented Nov 17, 2016

Oh, sure.

In Flow 0.34.0 they introduced a syntax for specifying whether a property in an object passed as a parameter is covariant, contravariant, or invariant. This tells you whether you are allowed to assign keys to a subtype or supertype of their declared type inside or outside of the function context. The property variance annotation can be a + or a -.

Long story short: I think it should be ignored when checking whether a prop has been validated or not!

Docs: https://flowtype.org/blog/2016/10/04/Property-Variance.html

@ljharb
Copy link
Member

ljharb commented Nov 17, 2016

Based on my understanding of that blog post, +/covariant is read only, -/contravariant is write only, and objects are invariant by default. In your example code, I agree the warning should not appear.

A separate question is what to do about contravariant props, but since you arent supposed to ever mutate props, it seems like you'd never want a contravariant prop, and that should be an error - but that seems like a separate rule.

@ajhyndman
Copy link
Contributor Author

I think you nailed it.

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

No branches or pull requests

2 participants