Functional Components with Exactly Two Arguments Implicitly Pure [Proposal]

[haraldrudell]

Suggestion:
I suggest that functional components with exactly 2 arguments to be implicitly pure

Benefit
By being implicitly pure instead of wrapped with memo, weird wrapping parenthesis and braces are not required, thus boilerplate is reduced

The Problem
Several parenthesis and braces in sequence is difficult to read. For example memo wrapping anonymous functions have two parenthesis and one brace: export default memo(({id}) =>

Closing parenthesis and braces are also required

Considerations

• Arguments provided by react@next 16.7.0-alpha.2 to a functional components are nextProps and context
• Advanced React programmers for performance reasons will typically use pure components everywhere
• Novice React users are unlikely to use context, thus unlikely to list 2 arguments should they use functional components or class components
• Traditional components today are a legacy pre-15.4 construct, basically the curse of the planet

Implementation

• The number of arguments a function is declared with are accessible as function-value.length
• function-value.prototype.isReactComponent is truthy when the function-value is a class component

As of React 16.7.0-alpha.2:
“Awkward memo-wrapping”

const Pure1 = memo(function C() {
  …
})
const Pure2 = memo(({id}) => {
  …
})

With suggestion implemented:

const Pure1 = ({id}, pure) =>
  <>
    <h1>ID</h1>
    <p>The id is: {id}</p>
  </>
function Pure2({id}, pure) {
  return <>
    <h1>ID</h1>
    <p>The id is: {id}</p>
  </>
}
const Traditional1 = ({data}) => <div>{data.prop}</div>
function Traditional2({data}, context, trad) {
  return <div>
    {data.prop}
  </div>
}

#14469 was a previous abandoned alternative suggestion

harald.rudell@gmail.com

[heyimalex]

The issue I think is that React.memo isn't free.

I'd actually push back against the idea that "Advanced React programmers for performance reasons will typically use pure components everywhere"; all of the extra equality checks can make the hot path slower. I'd imagine that's why it's opt in.

Here are some prior issues with core contributors weighing in:

• Make stateless components “Pure” by default in React 17 #14000
• Do functional components behave like React.Component or React.PureComponent? #13060
• Pure Functions as Stateless Components #3995

[ckknight]

Why would I want to add an extra argument to a function if I don't access or otherwise use that argument? Seems confusing.

[Li357]

This seems like a headache especially with linters (no-unused-vars). The fact that it's implicit makes it very hard to understand at a glance that it's pure if the second unused argument is named anything else.

[haraldrudell]

@heyimalex

• This proposal does not suggest changing the default behavior. The default remains being traditional components, so your performance point is not relevant
• Performance has to be measured, theorizing assertions are of little value.
  https://moduscreate.com/blog/react_component_rendering_performance/ tests pure to be 27% faster. The gain is greater for a stateful component with many children
• A common pattern is redux-immutable-pure components

@ckknight

• The point of this proposal is to remove the memo import and one set of parenthesis
• Some people do write out unused function arguments because they want to be reminded of what values the invoking library is providing

@Li357

• Your linting behavior statement is not based on facts. The react-app-pipeline linter issues no warnings

This is something that would make my React code easier to read

[jquense]

Hey folks, new, significant, API additions should be submitted via the RFC process in the RFC repo. Let's please move this there. I will add tho that this is propsoal will probably run into issues making it in for a few reasons:

The second (and third) arguments of function components already are used making this require a major version bumps to implement. And second, last I knew the core react team had other plans for the other arguments of stateless functions.

Unrelated, but I'd also push back that advanced react programmers always use pure components :P. I don't use them hardly ever; they make no meaningful impact in most cases, and as noted aren't free to use. As perf optimization I think a slightly awkward API isn't a big deal, but if you do think this would add a lot it may be worth it to build a Babel plugin to compile them down to memo calls

[escaton]

@haraldrudell don't forget that second argument is already used for ref when component is wrapped with forwardRef

[aralroca]

IMO memo approach is enough understandable.

However I understand that maybe as a function wrapper is not 100% elegant solution... Especially if you have more "wrappers" like connect:

export default memo(
  connect(mapStateToProps, mapDispatchToProps)(MyComponent),
)

Nevertheless, @haraldrudell I don't understand at all your proposal... For example, if you want to implement something like this:

function MyComponent(){ /* ... */ }

function areMyPropEqual(prevProps, nextProps) {
    return prevProps.myProp !== nextProps.myProp
}

export default memo(MyComponent, areMyPropEqual)

How do you propose to do it?

[aralroca]

BTW; for me, if I will propose to do it like:

export default function MyComponent {
/* ... */
}

MyComponent.memo  = true;

or

export default function MyComponent {
/* ... */
}

MyComponent.memo  = (nextProps, prevProps) => { /* ... */ };

[gaearon]

Please use https://github.com/reactjs/rfcs for API suggestions.