Adds decorators

[goatslacker]

Floating this change with you, if it's cool to add then I'll add some tests and docs.

I know this is a bit futuristic but this makes the API really nice to work with. Check out the Stargazers example.

[bebraw]

I think stage=1 should be enough here (decorators are a Stage 1 feature).

[goatslacker]

Stage 0 is so static class properties work which are required so that the class has a display name.

[ericclemmons]

Thanks for the notes here. I missed this (subtle) difference. I like being able to do propTypes inside of the class definition, too!

[ericclemmons]

@goatslacker Can you shed some more light on how decorators work in this scenario? Like, for the end-user? I've seen David Abromov's (SP?) experiments with it, but don't know much besides that.

I kinda still don't get it:

https://github.com/wycats/javascript-decorators

[goatslacker]

The de-sugared version of this would be (it's just a function call):

Resolver.decorate(options)(Component)

Don't mind the name, we can call it anything else.

[ericclemmons]

We can call it whatever you want, suga!

/rimshot?

[ericclemmons]

@goatslacker Question for ya. I've been messing with decorators internally and was naturally drawn to:

• @Capitalized decorators when they wrap classes.
• @lowerCased decorators for properties & methods.

The examples are non-opinionated as well:

https://github.com/wycats/javascript-decorators#class-declaration

If course, now eslint complains because Capitalized(function() { ... }) should be invoked with new.

What are your thoughts? My initial take on them, where they mirror the naming/capitalization of their subject, or always lowercased because they're technically functions and should be named as such?

[goatslacker]

I've generally always kept them camelCase because like you said they're functions, but I don't have any strong opinions on the matter.