Nice work. But perhaps you meant to link to https://github.com/mbasso/react-decoration/tree/master/docs instead? The releases page only shows a single release and two decorators.

It is also worth noting that the decorator syntax is still not final, and using it with Babel 6 requires https://github.com/loganfsmyth/babel-plugin-transform-decora.... More details on the decorator deprecation is in that repo.

I don't see anything here, with the exception of the debounce decorator, that isn't just an excuse to use a decorator for some reason. All of the examples can be implemented without decorators with the same amount of complexity and clarity.

That's what I thought, and there are lodash & underscore to do twenty different flavours of debounce. However, stuff like @killEvent and @stopPropagation does make sense.

The great thing about React is that it's easy to reason about. Devs new to React can quickly come up to speed. When you start decorating React components like this, you're introducing magic and making React code less easy to reason about. I'm not saying that you should avoid this in all cases, but you should consider the pros and cons and be careful. It seems that decorators at the component class level provide a mechanism to bring back mixins for those who want to use ES6 React components with mixins.

Well I glanced in and saw a decorator for event functions, like a debounce for an onClick.

That seems like a whole different thing. Isn't it worth while?

Decorating individual functions probably isn't a bad thing in those cases. The link takes you to only part of the Github repo. Look at the rest of it and you will see various class-level decorators.

The examples on the main page don't look very compeling :

@autobind onClick() {} is equivalent to : onClick = () => {}

@extractValue onChange(value) {} is equivalent to : onChange({value}) {}

It longer, less efficient, less understandable.

The main docs page has better examples.

Decorator's shouldn't be a part of javascript when function composition serves the same purpose without adding additional syntax.

To play Devil's advocate, function composition can accomplish literally anything that's conputable, and principle of least power would suggest that having specific and limited syntax for common patterns is productive.

If Javascript continues to admit statement-based syntax, I think decorators are appropriate, because they allow the functional decorator pattern to be applied to function (and method, and class) declarations.

Most of the things that were introduced in ES6 were already possible without adding additional syntax (classes, arrow functions, etc.).

Function composition is so common it deserves its own syntax.

This reminds me of https://github.com/acdlite/recompose, although the latter seems a bit more useful at first glance.