A recent tweet by @acdlite (read here) discusses a new pattern. That pattern and this RFC both covers a way to provide extra data to components so whoever has interest in this RFC should also read that.

Other ways of providing extra data are HOCs and Render Props

There are old-ES-Decorators-style HOCs ((Config) => (ComponentType) => ComponentType):

• react-redux connect()
• recompose

And also Relay HOCs ((Config, ComponentType) => ComponentType):

• react-relay

I'd like to note that the main aim of the RFC is talk about not React's code but its ecosystem. I can imagine many conclusions for this RFC:

• React starts providing decorator APIs.
• Libraries start providing decorator APIs.
• We write documentation to tell users how to use decorators. (Like there is for HOCs and Render Props)
• All, some or none of the above.

While I follow many well-considered React people, I haven't seen anyone talking about decorators and how they can (or maybe can't) benefit React.

I just wanted to start a discussion and get people thinking with decorators. I will edit the RFC as we further the discussion.

I believe this will be an easier discussion after Stage 2 Decorators support for Babel 7 is complete: babel/proposals#11

Until then it will not be possible to provide POCs.

As you note, Decorators are stage 2. I believe the main reason they haven't been discussed more broadly is because they're still viewed as unstable and likely to cause churn. The confusion between stage 0 and stage 2 decorators in the comments above seems to be evidence to that point, it seems very possible that they'll undergo further changes if and when they progress to stage 3.

And if it's not currently possible to provide POCs because they're not supported anywhere, then that again seems like evidence that this conversation should be happening sometime in the future.

it seems very possible that they'll undergo further changes

That's the important part. We can either wait until TC39 finalises the spec, or shape the spec by thinking on valid use cases. It would be great if we could discuss how we could benefit from decorators and provide TC39 with constructive inputs.

As you note, Decorators are stage 2. I believe the main reason they haven't been discussed more broadly ...

@vcarl the reason why I would love React team to talk about this so the specification moves faster and we can benefit from this feature, but because we keep looking for workaround (or rather other way to do it) we do not get there 😞

From my code example, either pipe operator or decorators but the current way to do is so ugly and easy to error prune to be honest.

HOCs with Decorators

HOC (Note: This is NOT a valid Stage 2 Decorator)

const injectFoo = (value) => (Base) =>
  class Wrapper extends Component {
    render() {
      return <Base foo={value} />;
    }
  };
const injectBar = /* ... */;
const injectBaz = /* ... */;

class MyComponent extends Component {
  render() {
    const { foo, bar, baz } = this.props;
  }
}

export default injectFoo('foo')(injectBar('bar')(injectBaz('baz')(MyComponent)));

HOC w/ Stage 2 Decorators

const injectFoo = (value) => (classDescriptor) => ({
  ...classDescriptor,
  // Finisher is a HOC
  finisher: (Base) =>
    class Wrapper extends Component {
      render() {
        return <Base foo={value} />;
      }
    },
});
const injectBar = /* ... */;
const injectBaz = /* ... */;

@injectFoo('foo')
@injectBar('bar')
@injectBaz('baz')
export default class MyComponent extends Component {
  render() {
    const { foo, bar, baz } = this.props;
  }
}

Preventing Prop Name Collision with Property Decorators

Apollo has a HOC named "graphql" and it injects a prop named "data". To prevent collisions you have to pass an options object for each use:

import { graphql } from 'react-apollo';

class MyComponent extends Component {
  render() {
    const { foo, bar, baz } = this.props;
  }
}

export default compose(
  graphql(foo, { name: 'foo' }),
  graphql(bar, { name: 'bar' }),
  graphql(baz, { name: 'baz' }),
)(MyComponent);

This could be simplified with property decorators:

import { graphql } from 'react-apollo';

const graphqlProp = (query, options) => (elementDescriptor) => {
  const propName = elementDescriptor.key;
  
  return {
    ...elementDescriptor,
    propertyDescriptor: {
      ...elementDescriptor.propertyDescriptor,
      writable: false,
      get() {
        return this.props[propName];
      },
    },
    // Finisher is a wrapped HOC
    finisher: (Base) => graphql(query, {
      ...options,
      name: propName,
    })(Base),
  }
};

export default class MyComponent extends Component {
  @graphqlProp(foo) foo;
  @graphqlProp(bar) bar;
  @graphqlProp(baz) baz;

  render() {
    // Both work
    const { foo, bar, baz } = this.props;
    const { foo, bar, baz } = this;
  }
}

I use decorators a lot for providing access to some context, such as confirm dialogues and status messages. A nice bonus is that they can render differently in different contexts. Also, I prefer it to using render props. With render props I don't have access to the received state from this. Would love to have:

@withContext('foo', MyContext)
class Foo extends Component {
  render() {
    return (
      <div>
        {this.props.foo.bar}
      </div>
    )
  }
}

This would be just as cool however:

class Foo extends Component {
  static withContext = {
    foo: MyContext
  }

  render() {
    return (
      <div>
        {this.props.foo.bar}
      </div>
    )
  }
}

#68