property `children` not found in props of React element ... #1964

MoOx · 2016-06-17T07:47:22Z

This issue showed when I upgraded from 0.25 to 0.27...

I think I am still having issue.

Here is a component

// @flow

import React from "react"
import { StyleSheet, View } from "react-native"

type Props = {
  children: ReactElement,
}

const NavigationBar = (props: Props): ReactElement => {
  return (
    <View
      accessibilityRole={ "menubar" }
      style={ styles.bar }
    >
      <View style={ styles.center }>
        { props.children }
      </View>
    </View>
  )
}

NavigationBar.defaultProps = {
  children: null,
}

const styles = StyleSheet.create({
  // ...
})

export default NavigationBar

And here is a place where it is throwing errors

// ...
const Header = (props: Props): ReactElement => {
  const { user } = props

  return (
    <NavigationBar> // <- HERE I AM THE ERROR: property `children` not found in props of React element `NavigationBar`
      <View style={ styles.left }>
// ...

Looks like a bug. Or maybe I am doing something wrong?

Kerumen · 2016-06-22T15:18:43Z

Dupe of #1934

ctrlplusb · 2016-07-12T15:19:33Z

For now I have had to resort to the following:

type Props = {
  children?: ReactElement,
  other: number,
};

function Foo({ children, other } : Props) {
  return (
     <div>...</div>
  );
}

szagi3891 · 2016-07-25T04:26:37Z

fast offtopic :
ReactElement is the proper way to describe output type from function render ?
where it is defined by this definition ?

jedwards1211 · 2016-07-29T16:17:57Z

@ctrlplusb you can workaround without using a maybe prop:

<NavigationBar children={<span>flow bug (this will get overridden by the children below)</span>}>
  <View style={ styles.left }>
  ...
</NavigationBar>

jedwards1211 · 2016-07-29T16:19:24Z

@szagi3891 It's here: https://github.com/facebook/flow/blob/master/lib/react.js#L32

I thought it has to be React.Element in recent versions of flow though?

ekosz · 2016-09-14T18:17:17Z

Is there any update on this issue? I just just ran into this.

MoOx · 2016-09-20T10:23:10Z

My real poor workaround is to always do children?: React$Element<any>.

wildeyes · 2016-09-23T09:40:16Z

@MoOx Hey, why do you write the dollar sign between React and Element?

gcanti · 2016-09-23T10:26:35Z

@wildeyes React$Element and import type { Element } from 'react' are equivalent https://github.com/facebook/flow/blob/master/lib/react.js#L226

Cut out extra flowignore lines that are no longer necessary now that react-motion uses flow. Use `children` prop to work around facebook/flow#1964

mqklin · 2016-10-08T07:44:46Z

My workaroud:

type Props = {
  children: React$Element<*>,
};

class Div extends Component {
  props: Props;
  render() {
    const { props } = this;
    return (
      <div>{props.children}</div>  
    );
  }
}

Usage:

  <Div
    children={(
      <span>Works nicely</span>
    )} 
  />

Ehesp · 2016-10-19T13:27:25Z

Hitting this issue... bread and butter React syntax. Work arounds feel a bit stinky :(

rosskevin · 2016-10-19T13:54:48Z

This syntax works for me and I believe was the recommended change when upgrading from 0.25.0

// @flow
import React, {Element} from 'react' // EDIT this should be importing type!!

type Props = {
  children: Element<any>
}

And the signature for render is

render (): Element<any>

Am I missing something in the question/problem? I made this change quite some time ago and it is working well. This doesn't seem like a workaround.

EDIT: I've left the above for posterity, but after more use it seems that we should be using import type {Element} from 'react' and Element<*>, see my later comment.

Ehesp · 2016-10-19T14:04:07Z

@rosskevin Well I'm fairly new to Flow at the moment, so maybe I'm not understanding correctly! Here's my example:

/**
 * @providesModule Button
 * @flow
 */

import React, { PropTypes } from 'react';
import { TouchableHighlight, Text } from 'react-native';

function Button({ onPress, children }: { onPress: () => void, children: string }) {
  return (
    <TouchableHighlight
      onPress={onPress}
    >
      <Text>
        {children}
      </Text>
    </TouchableHighlight>
  );
}

Button.propTypes = {
  onPress: PropTypes.func,
  children: PropTypes.string.isRequired,
};

export default Button;

So in this, I'm saying by Button must always have children which must always be a string. When I implement this in another component like so...

<Button onPress={this.someFunc}>
    Click Me
</Button>

... I get a Flow error of Flow children: Property not found in props of React element "Button".

The only "fix" I can see right now is changing children: string to children?: string, which is removing the error, but now Flow thinks a children prop maybe has to be set (which it isn't), when in fact I always want to have children, just not as a direct prop, rather than in-between my <Button> component.

EDIT: Same issue with using Element<string>. Also it doesn't really work with the above, since now I can pass in any Element (View, Text etc) as the child (between the component) and it doesn't complain.

rosskevin · 2016-10-19T14:30:41Z

@Ehesp - I suggest two things

use Element<any> for children
stop doing propTypes separately and use flow-react-proptypes (before your babel entry for transform-flow-strip-types. Here's my .babelrc

Here's how I would refactor your component:

// @flow
import React from 'react'
import pure from 'recompose/pure'
import { TouchableHighlight, Text } from 'react-native'

type Props = {
  onPress: Function,
  children: Element<any>
}

export default pure((props: Props): Element<any> => {
  const { onPress, children, ...rest } = props
  return (
    <TouchableHighlight onPress={onPress}>
      <Text>
        {children}
      </Text>
    </TouchableHighlight>
  )
})

This is untested but I think it should work for you.

AsaAyers · 2016-10-19T14:31:42Z

JSX converts to something like this:

React.createElement(
    Button,
    { onPress: thissomeFunc },
    "Click Me"
);

Flow recognizes that the 2nd parameter is where props come from, but it doesn't seem to recognize that the 3rd parameter gets mixed into props under the key children.

This workaround works because you're moving children from the 3rd parameter into the 2nd parameter

  <Div
    children={(
      <span>Works nicely</span>
    )} 
  />

becomes

React.createElement(Div, {
  children: React.createElement(
    "span",
    null,
    "Works nicely"
  )
});

If you use children?: React$Element<any>. the error goes away. Flow still thinks children is always missing, but now that it's marked optional it doesn't complain.

AsaAyers · 2016-10-19T14:38:18Z

@rosskevin I corrected your untested code here. You can see that at the bottom I am passing children to Pure but Flow just doesn't see it.

I dumped the : Element<any> part because it was just giving me errors I didn't need to fix.

rosskevin · 2016-10-19T14:52:17Z

@AsaAyers - I corrected your correction ;) with imports here

I haven't seen this problem but it does seem that you have to make Element<any> optional.

Here is a reduced test case that seems to prove either this is a bug (or my misunderstanding).

Macil · 2016-10-19T20:23:05Z

That doesn't work for elements that actually require children.

react-motion specifically requires a function to be passed as the children prop.

ghost · 2016-11-04T10:14:53Z

So apparently the fix: a7878eb was reverted in 0185892, which means that flow currently can't check whether the children prop has been set in jsx.

From the revert:

We don't have a way to declare the type of a React element "nominally" based on it's type. Without this, it's arguably better to be ignorant than support JSX children.

Still, eventually supporting jsx children would be nice, it's a pretty crucial part of using react. Any feedback on whether there will be support for this in the future?

AsaAyers · 2016-11-04T14:56:21Z

Every few months I come back and try Flow to see if it's ready. When trying to add Flow to my codebase it never takes me long to find the show stoppers. It seems I can only use flow if I significantly change the style of my code to avoid JS features where Flow is buggy. I guess I'd need to drop JSX to avoid this.

If this were the only problem I might consider one of the workarounds here. But for now I'm back to subscribing to issues and I'll try again in a few months when some of them close.

steida · 2016-11-29T16:10:38Z

@AsaAyers I recently flowtyped my relatively huge project. You can check it. https://github.com/este/este

steida · 2016-11-29T16:13:17Z

@AsaAyers If you are not sure what to use, use any. Even /* @flow weak */ is immensely useful. Or check how I flowtyped Fela robinweser/fela#134

A bug in flow (facebook/flow#1964) prevents it checking in it's children prop has been set in jsx. You can make flow ignorant to this prop by setting it as optional. Addresses chenglou#375

cjke · 2017-04-16T03:00:58Z

I do agree - and it is painful. Especially considering they come from the same parent.

However, I do feel that it is a rabbit hole. Unless they can define the relationship between an argument and a property on another argument abstractly, or we are provided a mechanism to define required props.children and children in ours components separately, I don't see how this could be added without bloating flow to handle specific library use cases (in this case React).

In saying this, I am no Facebook engineer, I'm a pleb with a laptop - so I'm sure they will figure out something that avoids tightly coupling flow to react while resolving this issue.

suchipi · 2017-04-16T03:20:24Z

Off the top of my head, here's some places where different uses of JSX differ:

Is the third argument used as an attribute called children?
When there is only one child JSX element, is it passed as a single-item array to the factory function, or a bare item?
How are uppercase/lowercase element type names treated? (React uses identifiers for uppercase and strings for lowercase)

You could theoretically make configuration for each of these in .flowconfig:

[options]
jsx.useChildrenAttribute=true
jsx.singleChildWrappedInArray=false
jsx.identifierTypeMatcher=^[A-Z]\w+

But in practice, most people just want

[options]
jsx.react=true

aaronjensen · 2017-04-16T05:30:54Z

Could it be typed something like this?

/* @flow */

type Props = {
  foo: string,
  children: number
}

type RC<P> = (props: P) => void

declare var Foo: RC<Props>
 
declare function createElement<C, P: { children: C }>(component: RC<P>, props: $Diff<P, {children: C}> & {children?: void}, children: C): void
declare function createElement<P>(component: RC<P>, props: P, children: void): void

createElement(Foo, {foo: 'hi', children: 3})
createElement(Foo, {foo: 'hi'}, 3)

https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgAKATnDgM5gC8YA3qmGFHHAFxjkbECWAdgOYAaBmADGAC24wAJsTy92vAK4BbAEZ5iqAL7ps+MACUAwgB5CAPmpgAFDlIV2hAJTUrANzjdp6aXlEwAIZyYO7BYABiLOwm5g7kFgyofgHBBFBKvKIY3HC8YnKBGHgAojB4KvIYpsaCROy0YpIycgpgxmDaFjaicCo4eVUxZpZ19mTk7AAkACLcUFDmdbQSUrLy7MZdYABkdKst8gD87J7e2nUH623GzqdePilBIRlZOXkFeEWl5ZW81ZYen0BrwhkYRhYxvEnJdmtd7t47qEHuhRIVimUKlUbFE4MtmGwwABySRE2FrVrsADM2mcqDRXwxv2xuPx0WJpIuYCpziAA

daltones · 2017-04-16T21:39:50Z

@aaronjensen seems like a good start. But Flow still doesn't “understand” that JSX children would be the third argument of createElement.

Besides that, these declarations don't handle multi-element children the way React.createElement is.

<Foo>
  <i />
  <i />
  <i />
</Foo>

// equals to:
createElement(Foo, null, createElement('i'), createElement('i'), createElement('i'));

// and not:
createElement(Foo, null, [createElement('i'), createElement('i'), createElement('i')]);

aaronjensen · 2017-04-17T04:42:57Z

@daltones

But Flow still doesn't “understand” that JSX children would be the third argument of createElement.

Really? What does it do with JSX then? I was assuming that it translated it into a React.createElement call (if you use the default pragma). How else would it type proptypes or the children prop? Babel certainly "understands" it.

As for the multiple children, I think you can handle that too:

/* @flow */

type Props = {
  foo: string,
  children: number
}
  
type BarProps = {
  foo: string,
  children: Array<number>
}

type RC<P> = (props: P) => void

declare var Foo: RC<Props>
declare var Bar: RC<Props>

declare function createElement<C, P: { children: C }>(component: RC<P>, props: $Diff<P, {children: C}> & {children?: void}, children: C): void
declare function createElement<C, P: { children: C }>(component: RC<P>, props: $Diff<P, {children: C}> & {children?: void}, ...children: C): void
declare function createElement<P>(component: RC<P>, props: P, children: void): void

createElement(Foo, {foo: 'hi', children: 3})
createElement(Foo, {foo: 'hi'}, 3)
createElement(Bar, {foo: 'hi'}, 3, 3, 3)

daltones · 2017-04-17T05:15:02Z

@aaronjensen Yeah! And I guess this is the main bug here: Flow can only handle normal JSX props (name={value}), but cannot handle element children (<Foo>{children}</Foo>).

You can see the issue using your example adding the same elements in JSX syntax.

SEAPUNK · 2017-04-17T05:19:25Z

Considering how Facebook & Co. uses React and (I would assume) also use Flow, I wonder how they handle this problem themselves... 🤔

aaronjensen · 2017-04-17T15:13:06Z

Flow can only handle normal JSX props (name={value}), but cannot handle element children ({children}).

Right, which is what we're discussing in this thread. They cannot handle it now, but I'm wondering if one way for them to handle it is with a better signature of React.createElement.

The example you linked doesn't really prove anything because it's still using the built-in React.createElement jsx pragma. Unfortunately, // @jsx doesn't work on flowtype.org for some reason, so I built this: https://github.com/aaronjensen/type-create-element

Try loading that up and changing the children types.

The only thing the signature doesn't handle right now afaik is JSXIntrinsics because I'm not entirely sure how to type those (and maybe they aren't either)

aaronjensen · 2017-04-21T17:13:24Z

Typescript just merged support for this: microsoft/TypeScript#15160

Hypnosphi · 2017-05-04T00:55:02Z

React flow typing excludes defaultProps from the config of props that need to be provided to createElement, because they will be assigned by React. Maybe it should also exclude children for the same reasons, like this:

Config: $Diff<$Diff<Props, DefaultProps>, {children: any}>

Macil · 2017-05-04T01:13:27Z

@Hypnosphi Sometimes you want to enforce the type of children; having the type be ignored wouldn't help there.

Hypnosphi · 2017-05-04T01:42:39Z

@agentme yes, but normally children are provided separately from props. $PropertyType<Props, 'children'> can be used for their checking.

UPD. The {children: any} in my comment above wasn't intended to ignore the type, it was meant to exclude the children prop from shape. But, because of some $Diff<A, B> bug, B's field types override the corresponding ones of A, so in fact the original type gets lost, and <Component children={/* bad value */} /> stops rising a warning. Something like this should work though:

Config: $Diff<$Diff<Props, DefaultProps>, {children: $PropertyType<Props, 'children'>}>

…ing AnimatedBar

karlhorky · 2017-06-06T15:51:39Z

Just tried @rosskevin 's example again with Flow 0.47.0 and it is not throwing errors currently:

Try Flow Link

Is this intentional or actually a bug currently in Flow?

Strangely enough, it doesn't appear to be actually checking the type of the children:

Try Flow - children with type boolean

echenley · 2017-06-06T16:25:14Z

@karlhorky I may be mistaken, but wouldn't you have to do this?

import React, { type Element } from 'react'

Otherwise, you could use the global React$Element type and avoid the import altogether.

karlhorky · 2017-06-06T16:36:50Z

Hm, this doesn't make a difference for the result.

rosskevin · 2017-06-12T18:32:00Z

Infer * might be the key, this seems predictable

suchipi · 2017-06-13T00:18:48Z

Ooo, does that mean this is fixed?

SEAPUNK · 2017-06-13T00:30:59Z

I hope so, even though nobody on the dev team said anything about it. My cynical side expects this to break again in the next releases.

gaastonsr · 2017-06-13T00:37:46Z

Almost, it checks for the presence of children but it doesn't do type checking yet.

suchipi · 2017-06-13T00:58:43Z

You're right: https://flow.org/try/#0JYWwDg9gTgLgBAJQKYEMDG8BmUIjgcilQ3wChRJY4YBPMJOAbwFEAbJEJAOxgF85suAkXQwypWvTgAFHGADOcALxNScOBC4BhVsDQBrAFxwAYgFcuGYJoA0auGgAWwVgBMiXY2w7cYAHgAqAD5SXlJSNE15eABlCnZlOAAKMDl5Y1kIBQBKZSDVdUiuaKYNbV0DGwdnNw8qgDpGohL+FVSs+XsiGDMoLmT7dT9XYAA3Mp09fSVGTUmDXhD1ZaYnF3duMJW-AHoR0aW4bNDw0h2duHkzNDQkJFdFFEUkAA96DHuAfgioiHZ61gQADmSXsfji4AScwq00YSVySnyRXkfyQAOBSXwAHVoG58NlFoMmABWLZwXYQsDsELHM4XTAoFyPZ5vJAfVzfZGo9EgsGUqHlKYzeF5By-f6AkHY3GufG8HY0oA

agrcrobles · 2017-08-16T18:51:11Z

Flow v0.53 supports children out of the box!!

import * as React from 'react';

type Props = {
  children?: React.Node,
};

More info: https://flow.org/en/docs/react/children/

asolove · 2017-08-22T02:21:05Z

Now that Flow v0.53 has improved the Component type and made children work, I think this issue can be closed. (/cc @calebmer)

Flow doesn't understand jsx + children (facebook/flow#1964) so this makes the prop optional and adds an invariant to make sure it was actually passed. Closes expo#301 fbshipit-source-id: 76ea6d7

ctrlplusb mentioned this issue Jul 12, 2016

Support Stateless Functional React components #1081

Closed

gcanti mentioned this issue Jul 31, 2016

RFC: Ditching JSX in favour of advanced static type checking gcanti/babel-plugin-tcomb#83

Closed

jamiebuilds mentioned this issue Aug 3, 2016

children in a stateless component #1934

Closed

kevinrobinson mentioned this issue Aug 19, 2016

Copy revisions for response modes, additional tests mit-teaching-systems-lab/threeflows#133

Merged

Macil added a commit to StreakYC/react-draggable-list that referenced this issue Sep 26, 2016

Use latest react-motion.

22fca76

Cut out extra flowignore lines that are no longer necessary now that react-motion uses flow. Use `children` prop to work around facebook/flow#1964

Macil mentioned this issue Oct 3, 2016

Flow: Property not found chenglou/react-motion#375

Open

vkurchatkin added the react label Oct 27, 2016

cooljeffrey pushed a commit to cooljeffrey/resume that referenced this issue May 10, 2017

resorted App.js. Encountered flow bug facebook/flow#1964 which affect…

44d19a1

…ing AnimatedBar

yinanfang mentioned this issue May 11, 2017

Add props annotation after bug fix yinanfang/DBDCapital-Node#56

Open

Ap0c mentioned this issue Jun 14, 2017

Monthly Contrib Checkout Designs guardian/support-frontend#83

Merged

Palisand mentioned this issue Aug 16, 2017

Update flow/.flowconfig with version 0.53.0 expo/create-react-native-app#366

Closed

danrot mentioned this issue Aug 17, 2017

update flow and add children annotations sulu/sulu#3483

Merged

1 task

MoOx closed this as completed Aug 22, 2017

amanmdave mentioned this issue Mar 3, 2020

Tooltip for "Properties" and "Objects" panels is "[object Object]" 4ian/GDevelop#1484

Closed

property children not found in props of React element ... #1964

property children not found in props of React element ... #1964

Comments

MoOx commented Jun 17, 2016

Kerumen commented Jun 22, 2016

ctrlplusb commented Jul 12, 2016 • edited Loading

szagi3891 commented Jul 25, 2016

jedwards1211 commented Jul 29, 2016 • edited Loading

jedwards1211 commented Jul 29, 2016

ekosz commented Sep 14, 2016

MoOx commented Sep 20, 2016

wildeyes commented Sep 23, 2016

gcanti commented Sep 23, 2016

mqklin commented Oct 8, 2016 • edited Loading

Ehesp commented Oct 19, 2016

rosskevin commented Oct 19, 2016 • edited Loading

Ehesp commented Oct 19, 2016 • edited Loading

rosskevin commented Oct 19, 2016 • edited Loading

AsaAyers commented Oct 19, 2016

AsaAyers commented Oct 19, 2016 • edited Loading

rosskevin commented Oct 19, 2016

Macil commented Oct 19, 2016

ghost commented Nov 4, 2016

AsaAyers commented Nov 4, 2016

steida commented Nov 29, 2016

steida commented Nov 29, 2016

cjke commented Apr 16, 2017

suchipi commented Apr 16, 2017

aaronjensen commented Apr 16, 2017

daltones commented Apr 16, 2017

aaronjensen commented Apr 17, 2017

daltones commented Apr 17, 2017

SEAPUNK commented Apr 17, 2017

aaronjensen commented Apr 17, 2017

aaronjensen commented Apr 21, 2017

Hypnosphi commented May 4, 2017 • edited Loading

Macil commented May 4, 2017 • edited Loading

Hypnosphi commented May 4, 2017 • edited Loading

karlhorky commented Jun 6, 2017

echenley commented Jun 6, 2017

karlhorky commented Jun 6, 2017

rosskevin commented Jun 12, 2017

suchipi commented Jun 13, 2017

SEAPUNK commented Jun 13, 2017

gaastonsr commented Jun 13, 2017

suchipi commented Jun 13, 2017

agrcrobles commented Aug 16, 2017

asolove commented Aug 22, 2017

property `children` not found in props of React element ... #1964

property `children` not found in props of React element ... #1964

ctrlplusb commented Jul 12, 2016 •

edited

Loading

jedwards1211 commented Jul 29, 2016 •

edited

Loading

mqklin commented Oct 8, 2016 •

edited

Loading

rosskevin commented Oct 19, 2016 •

edited

Loading

Ehesp commented Oct 19, 2016 •

edited

Loading

rosskevin commented Oct 19, 2016 •

edited

Loading

AsaAyers commented Oct 19, 2016 •

edited

Loading

Hypnosphi commented May 4, 2017 •

edited

Loading

Macil commented May 4, 2017 •

edited

Loading

Hypnosphi commented May 4, 2017 •

edited

Loading