export default should not be inline with the class declaration

[majapw]

When there are static variables like propTypes and defaultProps, we shouldn't export them until we have actually set them onto the Component. This may change if the current ES7 proposal for static class properties gets accepts, and we update to support it.

[ljharb]

LTGM 👍

The important thing in my eyes is that we don't have things like:

const foo = someExpression;
export default foo;

… in these cases we should just have

export default someExpression

[justjake]

If we want to make this change, we should add a lint rule for it. Personally, I prefer doing export default class Foo extends Component { ... } and then adding the propTypes attribute afterwards. Does the spec specify that objects are frozen when they are exported?

[ljharb]

No, nothing in JS is frozen unless you Object.freeze it.

imo there shouldn't be any expressions after the default export. I'm fine with the way this style is currently described, but I think that this change makes sense.

[justjake]

why? seems overly perscriptive

[majapw]

Logically, it looks better? I feel like you shouldn't be able to add things to a module after it's been exported. It feels weird?

[justjake]

doesn't feel weird to me, coming from Python, Ruby and Go.

[hshoff]

Let's merge it for now and if things get weird we can always reopen follow up with another PR. Thanks @majapw!

[philihp]

Modifying properties after you've done an export default feels like requesting the bartender for another drink after you've already settled up your tab.

[ljharb]

@philihp wait, you don't do that?