[Andarist]

No description provided.

[taion]

This is actually the preferred style for propTypes and defaultProps per https://github.com/airbnb/javascript/tree/master/react#ordering.

[Andarist]

The airbnb style guide doesnt take into account class properties (yet I guess). It advise to put statics at the top of your class declaration, but according to es2015 its possible to have only static methods, not properties.

So to put things like propTypes, defaultProps etc as static in es2015 it is in fact the only way to attach them after the declaration.

However keeping them like this will prevent proper tree-shaking in the (hopefully near) future. Related issues - babel/babel#5632 (comment) and babel/babel#5902

[taion]

Well, no, it also makes it less onerous when changing things around between component classes and functions.

Like, without smarter heuristics, not being able to tree-shake functional components still seems pretty broken.

[Andarist]

Ok, I get your point about bigger ease when transforming between class and a function. Didnt think about it before.

However still the mentioned components (from the react-transition-group) wont go functional any time soon. So I still would argue that pulling those statics into the class declaration would be better.

[silvenon]

Just casually dropping by after a year…

While I agree with @taion's arguments, does not using static properties syntax really prevent tree-shaking? In the light of merging #77, is this PR still relevant?

[Andarist]

In the light of merging #77, is this PR still relevant?

It is, #77 provides "module" entries + deep path imports that can be manually imported (i.e. from 'react-transition-group/Transition'). People can still use import { Transition } from 'react-transition-group' and by doing so they won't have other things (unused) removed from their bundles because they request a file (main/module from pkg.json) which reexports other stuff.

This might be covered by webpack@4 though (thanks to sideEffects: false in pkg.json), but it's not the only bundler in the world & there are also many many projects using older versions of webpack that could benefit from this.

That being said this change alone won't improve tree-shakeability because of the things described here. It's a starter though that could allow babel in the future (hopefully I will get this feature into upcoming babel@7) to move statics INTO transpiled "class IIFE", which is not possible for statics defined not by class properties transform (well, not exactly impossible, but babel won't do that ever by default).

[silvenon]

I wanted to fully understand this, but it's a bit out my league for now. 😅 In any case, I see no reason not to add this. It won't affect maintainability in any way and users can only benefit from it.

Could you please rebase/resolve these changes and make sure that:

1. it compiles well – static class properties are stage 3, right? does our Babel configuration cover it?
2. it doesn't affect the documentation in www – our docs are partially generated from comments