Support Functional Components

[jamiebuilds]

Moving from #34.

As of react@0.14, plain functions can be used as components. In the future this will bring performance optimizations in React.

function Component(props) {
  return <div/>;
}

Many people are already using these, there's even a Babel plugin (that I wrote) to transform pure component classes to pure component functions.

It would be great if babel-plugin-react-transform supported these. However, there is a pretty big concern.

Since these are just plain functions, with JSX in them there is nothing that designates that it is a react component. i.e. in order to tell that a class is a react component, we can test that it extends React.Component, or that it has a matching interface.

We can attempt to match them by treating "any function that has JSX in it will be treated as a component" i.e.:

function Component() {
  return <div/>;
}

However, this would also match the inner function in here:

class Component extends React.Component {
  render() {
    const children = this.props.items.map(function(props) {
      return <li>{props.name}</li>;
    });
    return <ul>{children}</ul>;
  }
}

So we can tighten things and say "only top level components", but then we run into wanting to support factories:

function componentFactory() {
  return function Component(props) {
    return <div/>;
  };
}

I could keep going for a while, you can put functions all over the place in JavaScript and no matter what we define as the rule here there will be exceptions. It's a matter of deciding what the heuristics should be that balances:

1. Rarity - How often people will actually run into exceptions in real world code
2. Obviousness - How easy it is to understand the reasoning behind an exception

It might be possible to get around the obviousness problem by throwing compile errors when running into ambiguous scenarios.

[kevinrenskers]

If you only do the top level ones automatically and would require a comment above or inside other functions? // @hmr: true or something

[jamiebuilds]

No, comments are a gross for this.

We get a ton of issues on Babel because of the Angular community using /* @ngInject */ comments to modify their code. Because comments are insignificant syntax they run into all sorts of problems.

I would try everything possible before using comments.

[gaearon]

I'd choose a convention a la "let/const function bindings at top level with capital letter names and JSX immediately inside."

In the first release I'd avoid trying to find factories altogether. I don't think that's a big problem.

Avoiding false positives is more important than finding every possible case. You can look at eslint React plugin as an inspiration for the heuristics.

[Restuta]

@thejameskyle I think what @gaearon suggests makes sense and as of next iteration we can support a "manual hint" case when heuristic didn't work. What are other options yo see besides comments? Can generators be used?

[gaearon]

An additional heuristic can be "a function with propTypes assigned to it later". Though React is gradually phasing out propTypes in favor of flow, it seems like a nice heuristic for most code bases.

[shinzui]

Can we limit the heuristic to any function that returns JSX and has props as its first argument?

[SpainTrain]

Can we limit the heuristic to any function that returns JSX and has props as its first argument?

Unfortunately, that would not cover the destructuring use case:

(from https://facebook.github.io/react/blog/2015/10/07/react-v0.14.html#stateless-functional-components)

// Or with destructuring and an implicit return, simply:
var Aquarium = ({species}) => (
  <Tank>
    {getFish(species)}
  </Tank>
);

[jamiebuilds]

The other issue that I didn't point out here is that many people do not use JSX in favor of something like hyperscript.

[shinzui]

@SpainTrain good point. I am even using destructuring in some of my stateless components. 😄

[shinzui]

@thejameskyle Shouldn't the first pass be focused only on the most common and recommended way (JSX/ES6) of writing stateless components?

[Restuta]

So far proposed heuristics are:

• let/const function bindings at top level with capital letter names and JSX immediately inside
• a function with propTypes assigned to it later

This doesn't cover:

• non-JSX users that don't use propTypes
• factories and some HOCs

And it's sounds like it's okay for now. Subjectively this covers majority of the cases.

We haven't yet discussed manual hinting, since I feel like it's a nice option.

I think that going with something as basic as "let/const function bindings at top level with capital letter names and JSX immediately inside." is probably a great idea.

Right now, people are just saying "Please support functional components!"

Once you can say "They are supported as long as... xyz" then you will probably start getting people with issues letting you know when there is a scenario that "xyz" just doesn't work.