Suggestion for README: when folder structures change often, it helps to have a dynamically evaluated import
geoyws opened this issue · comments
This feature will help a lot in terms of saving dev time.
I don't understand this suggestion. Perhaps a pull request would be clearer.
@domenic I think he's suggesting that a use case for dyanimic import() is when a directory tree is modified a single variable can be set to the correct module ID; versus having to change all lines of import something from 'old/directory/tree' in every sibling module file.
The way that problem is currently solved is by using injection of imported module contents into other imported module members which is not so parsimonious.
I still don't understand and still suggest a pull request with e.g. example code or spec changes so we can judge more clearly.
I think the suggestion is to add an example to the readme like the following to illustrate the dynamic nature of the import() operand:
// constants.js
export const COMPONENTS = '/path/to/components';// module.js
import { COMPONENTS } from './constants';
export default function gimmeComponent(name) {
return import(`${COMPONENTS}/name.js`);
}@ljharb Thanks. That's what I was trying to explain.
So the idea is to show that template strings containing variables can be used when using import() ?
@mkay581 i think the idea is specifically to convey that paths to modules can be stored in a constant, and used in import(), which gives you all the benefits that constantization normally does, but newly gives them for importing modules.
Ah okay, I thought that this "constantization" was implied, given that import() operates like other function calls and does not have to appear at the top of the module file like legacy imports. But thanks for the explanation.
@mkay581 It is implied. Though it might be of interest for persuading interested parties.
I think this is adequately illustrated by https://github.com/tc39/proposal-dynamic-import#example, so I'll close this.