Extract decorated functions as top level variables

[danbovey]

Could we get an option in .babelrc to extract each decorated function individually as it's own variable. Reason being is that react-hot-loader requires the OG decorated function (react component) to be its own top level variable. See their docs for the full explanation.

Currently this plugin transforms decorators to something like this:

const SuperComponent = 
     connect()(         <-- last HoC
       withSomeStuff(   <-- first HoC
         Component      <-- a real component
       )
     );

But with a "topLevel": true plugin option in .babelrc (just in development env section in my case), this plugin could transform decorators like this:

 const WithSomeStuffComponent = withSomeStuff(Component);
 const SuperComponent = connect()(WithSomeStuffComponent);

Would this be possible?

[loganfsmyth]

I'm not sure I fully follow the details, but this seems like the type of thing that could be implemented as a separate plugin that would run before this one, if you wanted that behavior. I'm not sure it is something that this plugin would do on its own?

[sirrodgepodge]

I believe this is exactly what I'm attempting here :),

https://www.npmjs.com/package/babel-plugin-undecorate

I'm assuming the reason you'd want this is for testability of the underlying class/method (that's why I wanted it).

[danbovey]

Closing as this is probably solved by babel-plugin-undecorate!

[vdh]

@danbovey Woah woah hey, it's not actually solved yet, it was only raised as a hypothetical solution

[danbovey]

@vdh As @loganfsmyth said, this issue doesn't have to be solved in this plugin, it's a little bit out of scope. I no longer need this so I haven't tested @sirrodgepodge's plugin but I assume that's the repo we can open an issue on if that doesn't solve this feature request.

[vdh]

@danbovey The problematic code is directly created by this babel plugin. Relying on yet another plugin to make further changes over the top of how it already behaves is an unstable attempt at solving the code generation issue.

[danbovey]

OK, reopening to be looked at by @loganfsmyth