import and export statements help isolate specific parts of an application by splitting content into isolated modules instead of making everything global. In the past this functionality was emulated by importing all files into a page then only using their content when needed using dependency injection systems. Alternatively, 3rd party libraries handled loading JavaScript files when they were needed (e.g. RequireJS). But these libraries require setup and management of the dependencies.
import and export provide native support of this functionality without having to install anything. The support is still lacking in browsers though the core parts are mostly supported these days. To demonstrate how this works here is a simple HTML file:
<!DOCTYPE html> <html lang="en"> <head> <title>ES6 Import Test Page</title> </head> <body> <b>Check your browser console</b> <script type="module" src="import.js"></script> </body> </html>
Don't forget to add type="module" to the script element. Otherwise the imports will not work. Additionally, this needs to be run on a server instead of just opening the file in a web browser to avoid Cross Origin Request errors.
The import.js file looks like this:
import './importModuleA.js'; // 'Running Import Module A' import myDefaultFunction from './importModuleB.js'; import { moduleCMessage, squareArea, defaultX, defaultY } from './importModuleC.js'; myDefaultFunction(); // 'Running Import Module B' moduleCMessage(); console.log(squareArea(2, 2)); // 4 console.log(squareArea(defaultX, defaultY)) // 42
Each of the import styles is explained import file by import file below. Note that no 'use strict' is necessary since all ES6 code runs in strict mode. Firstly, here is importModuleA.js:
console.log('Running Import Module A');
No exports are needed if a file just needs to be run for side effects. Here is importModuleB.js export default function() { console.log('Running Import Module B'); }
The default function will be assigned to whatever the first import from the module is. Both of the above cases will probably be exceptions except in very simple cases (due to lack of clarity). Instead most imports will be loading and running parts of modules direcly like importModuleC.js demonstrates:
Each name is simply exported as is, then the names are imported as is. There are more features to the imports, but I find that imports and exports should be kept simple. So that the code functionality is not buried in complex import strategies.
#Requirejs and amd are pretty cool. But I kinda hate the whole idea of dynamic loading modules. It does not look good in places like a blog template. But I guess it's fine to use them in more complex single page software. I just learned #typescript in 4 hours btw. I'm still working on it though ... There are just too many unrelated tools in javascript that developers need to combine to meet their needs. Sometimes I juat miss the old days when there was a notepad and nothing else ๐. #js #javascript #es6 #es5 #programming #nodejs #coding #coder #techie #technology
