i have an index.js
file that reads:
import aReducer from './ducks/a';
import bReducer from './ducks/b';
import * as aSelectors from './ducks/a';
import * as bSelectors from './ducks/b';
console.log(aReducer) //function i expect
console.log(aSelectors) //object with keys to selectors i expect
export { aReducer, bReducer, ...aSelectors, ...bSelectors };
If I console.log
in this file I see that the reducers are functions I expect and the selectors alias are objects with keys to the selectors I expect. The reducers are default exports for the duck files and the selectors are exports from the same respective file.
However, when I try to import this module with another file I am only able to import the two reducers. The two selectors are undefined. I thought that de-structuring would add each key to my export object. What am I doing wrong?
other_file1.js
import { aReducer, bReducer } from 'my-module'; //works!
other_file2.js
import { someSelectorThatWasInMyaSelectorsObject } from 'my-module'; //does NOT work!
You cannot use ...
in an export {};
block. It is an explicit list of names just like import {name} from
is. It is not an object with keys being exported. e.g. the same way imports do
import { foo as fooRenamed } from "";
with export
it is
export {
fooVar as foo,
};
The export
block is an explicit list of variables to export, with an optional explicit name for the export. There are no objects involved.
Specifically, there are no objects involved because the names of the exports are processed and known before the body of the file has even executed, so not only are objects not allowed, they are impossible to allow because objects require execution to exist.
To get what you'd want, you should use:
// Export the referenced files' default under two specific names.
export { default as aReducer } from './ducks/a';
export { default as bReducer } from './ducks/b';
// Re-export every named export from these two files.
export * from './ducks/a';
export * from './ducks/b';
来源:https://stackoverflow.com/questions/45447083/re-exporting-modules-does-not-work-with-object-spread