
Show HN: React-decoration – A collection of decorators for React Components - mbasso
https://github.com/mbasso/react-decoration/releases/tag/1.3.0
======
STRML
Nice work. But perhaps you meant to link to [https://github.com/mbasso/react-
decoration/tree/master/docs](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...](https://github.com/loganfsmyth/babel-plugin-transform-
decorators-legacy). More details on the decorator deprecation is in that repo.

~~~
pault
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.

~~~
paulftw
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.

------
steve_taylor
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.

~~~
dismantlethesun
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?

~~~
steve_taylor
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.

------
hokkos
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.

~~~
mhluongo
The main docs page has better examples.

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

~~~
acjohnson55
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.

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

