Change component signature from (props, children) to (props) and props.children

Current component signature:

const Component = (props, children) => (
  <div {...props}>{children}</div>
)

Desirable component signature:

const Component = (props) => (
  <div {...props}>{props.children}</div>
)
// or even
const Component = (props) => (
  <div {...props} />
)

Props

• You may omit the unused argument if your component uses only children, ref #567

  const Component = (props) => (
    <div>{props.children}</div>
  )
  

  vs

  const Component = (_, children) => (
    <div>{children}</div>
  )
  

• It is easier to use memoization because you don’t need to compare children separately from other props

  const Component = (props) => (
    <h1 title={props.title}>Hello {props.children}</h1>
  )
  
  const MemoizedComponent = memoize(
    Component,
    // by default (props, nextProps) => !shallowEqual(props, nextProps)
  )
  const DeepMemoizedComponent = memoize(
    Component,
    (props, nextProps) => !_.deepEqual(props, nextProps)
  )
  const CustomMemoizedComponent = memoize(
    Component,
    (props, nextProps) => props.children !== nextProps.children
  )
  

  vs

  const Component = (props, children) => (
    <h1 title={props.title}>Hello {children}</h1>
  )
  
  const MemoizedComponent = memoize(
    Component,
    // by default (props, nextProps, children, nextChildren) => !shallowEqual(props, nextProps) || children !== nextChildren
  )
  const DeepMemoizedComponent = memoize(
    Component,
    (props, nextProps, children, nextChildren) => !_.deepEqual(props, nextProps) || children !== nextChildren
  )
  const CustomMemoizedComponent = memoize(
    Component,
    (_, _, children, nextChildren) => children !== nextChildren
  )
  

• Using children prop is valid and it will not throw an error: TypeError: Cannot assign to read only property 'children' of object '#<HTMLHeadingElement>'
• It will be easier to add something new in the future (or via HOA)

  const ComponentWithContext = (props, context) => (
    <div>{props.children}</div>
  ) // Context for SSR aka context in React.js
  const ComponentWithConnect = (props, store, actions) => (
    <div>{props.children}</div>
  )  // aka React-Redux Connect
  // etc.
  

Cons

• It is a breaking change and requires at least Hyperapp v2 release

[Mytrill]

Would it be ok to to have the children passed both as a second parameter and in the props? That provides almost all the listed benefits AND keeps it backward compatible. The only benefits that it removes is the last one (easier to add things with HOAs).

The drawback is that there are 2 ways to write components with children.

[zaceno]

@JorgeBucaran I’m not really sure. In my very ignorant opinion, neither the pros or the cons (in the OP) are especially strong arguments. In such cases I tend to lean toward no change . But I’m basically fine with whatever.

As for the “both” suggestion… I think it should be either or – otherwise it looks bad. Like we don’t have a clear idea/agreement.

If we do decide definitely that 2.0 will have props.children, then it would be ok until that time, to have the signature ({children: ...}, children) as long as we deprecate the second arg in the docs. (Making it clear that we’ve made a concious decision, but leaving it there for compatibilty until 2.0)