uses default export if require() returns an object

[brigand]

An example of when this happens:

export class Foo extends React.Component {};
export default decorator(Foo);

It just checks to see if the export is an object, and uses that.default instead of that. There's no compatibility break (previously would throw an error).

[brigand]

@sokra I know you're very busy, but would you merge this or add me as a maintainer?

I'll also take a stab at adding high order component support for es6 classes where mixins don't work.

I'm greenjello on npm.

[jsg2021]

require() almost always returns an object. I believe the export loader composition is the true fix.

[brigand]

That's not true in babel 6 when using export syntax.

// input
export default 1;

// output
"use strict";

Object.defineProperty(exports, "__esModule", {
  value: true
});
exports.default = 1;

[jsg2021]

for non-Babel sources exports is an object too. unless the author replaces 'module.exports`.

require returns module.exports

[justingreenberg]

@jsg2021 is correct, checking for an object primitive is not an adequate heuristic here

@brigand, since this issue is specific to babel's cjs interop transform, it should be sufficient to check for the presence of the __esModule flag on the component module:

if (component.__esModule === true) component = component.default

although this is going to be a common issue, i assume @sokra will prefer the exports loader solution suggested here.. either way, should definitely be documented

[brigand]

Yeah, checking __esModule would be better, but it doesn't look like this will ever be merged so I won't bother updating the PR.

I don't think exports loader is a good solution because you have to hardcode whether you're using es6 modules or not every place you use react-proxy (I don't have a .async.js extension or similar). This also means that when you disable babel's es6 module import and switch to webpack 2's es6 modules, you'll have to rewrite all the uses of react-proxy-loader (I think).

[rosskevin]

It looks like there is a published fork here:
https://github.com/buzzer13/react-ondemand-loader

Would this be the best to switch to for es6?

[jsg2021]

Update: Webpack2 prevents the exports-loader from being a viable solution.

This pull and that fork aren't necessary. Just configure this loader to get the output of the exports-loader.

.
.
.
loaders: [
    { test: /\.async\.jsx$/i, loader: 'react-proxy-loader!exports-loader?exports.default' },
    {
        test: /\.js(x?)$/i,
        exclude: /node_modules/,
        loader: 'babel',
        query: {
            sourceMaps: true
        }
    },
.
.
.

[rosskevin]

@jsg2021 I ended up switching to https://github.com/luqin/react-router-loader

Much easier, no config necessary, works well with es6 import.

Here's a gist on jsx syntax with code splitting and dynamic routing https://gist.github.com/rosskevin/de55079e0d48f046fb518e45bb4f12b1

[jsg2021]

With webpack 2, the exports-loader chain no longer works :(

So we will likely need a variant of this PR

[jsg2021]

lets update this to just if (component && component.default) component = component.default;

This will let component be any value, but if it is non-null and has a 'default' key it will take it over the original.

This being targeted towards React Components the 'component' value does not need to be as flexible as other loaders. We could even add a warning if the component isn't "a react renderable component"

[brigand]

done

[jsg2021]

@brigand If you sign the cla, they will be able to merge your PR... also, if you see my comment above, it will be more universal.

[brigand]

@jsg2021 updated and signed CLA.

[jsg2021]

@d3viant0ne mind taking a look?

[michael-ciniawsky]

@brigand @jsg2021 Thx