Tried reproducing in the try-flow interface but it doesn't seem to support nested components. But in my code something like this is validating, although it shouldn't be:
import React, { Component } from 'react';
/* @flow */
type Column = {|
x: string
|}
type Props = {
columns: Array<Column>
}
class Renderer extends Component<Props> {
render() {
return (
<div>
{this.props.columns.map(c => <div key={c.y} />)}
</div>
)
}
}
This is a canned example, but when mapping over an array of Column objects and then using one in an inner component I would like to get an error stating that y is not found. But the tests work fine. I tried specifically mapping c: Column as well, but that didn't work either.
Is this expected?
UPDATE: It appears this happens only if I use a ternary if statement in the body:
<div key={c.y ? c.y : somethingElse} />
I was able to replicate on flow.org/try:
/* @flow */
import React from 'react';
type Column = {|
getValue: string => void
|};
type Props = {
column: Column
}
const Renderer = ({ column }: Props) => {
return <div>{column.doesntExist ? column.doesntExist('x') : null}</div>
}
This code validates, although I was hoping it would raise an error due to the reference doesntExist on the closed Column object type.
I think this is just an issue with refinements and exact object types. The mapping and react bits don鈥檛 seem to be part of the cause. You can see in this sorter example, which also passes type checks although II would expect it to fail:
type Column = {|
x: string
|}
declare var c: Column
c.y ? c.y : 2
The same logic with an if statement also passes when I鈥檇 expect it to fail. Curious if this is expected or not (cc @calebmer)
That makes sense (and thank you for the quick response). I tried to strip down the example but stopped at React; glad you took it all the way to the base case.
I understood this is by design.
But sketchy-null should report these cases.