Exercise: Using System.import()

In notebook:
FrontEndMasters Webpack Deep Dive
Created at:
2017-01-04
Updated:
2017-01-04
Tags:
Webpack libraries React JavaScript
He imports the graph module in his app. In app.js ​import toggleGraph from './graph'​

Explains a bit graph/index.js but not very important to know the details for this workshop. 
graph/index.js imports : ​import renderGraph from './render'​ 
graph/render.js: uses React, ReactDOM, rd3, lodash

So render.js would be a good splitting point for lazy loading. 

Using ​System.import()​ for lazy loading

This is actually ES6 standard (System API). This returns a Promise. 
  // pseudo code

System.import('./whatyouwannaimport').then(thing => {
  // first test in the browser what you got
  console.log(thing.default)
})
The exercise is to finish this function in graph/index.js:
  function loadAndRenderGraph() {
  
}

Q&A: why he does the export on the top of the files? (related to hoisting)

function declaration hoisting: not only the declaration, but the definition is hoisted as well. 
So he can export functions at the top of the files and the definition is hoisted even if it comes much later in the code. 
Improves maintainability. 

So his export pattern looks like this:
  export {func1, func2, func3}

function func1 () {
  ..
}

function func2 () {
  ..
}

function func3 () {
  ..
}
You can do ​default​ and named exports in ES6. 
  // this works
export default myfunc

export function myfunc () {
  ...
}
Then import it as
  import {myfunc}, myfunc as foo from './mymodule'
But you won't do it often...

Q&A: where does ​System.import()​ comes from?

From the browser when it will be implemented, but currently from Webpack (transpiles it).
The specs are not finished yet, because it's not yet decided how to resolve the path used for the imports (for NodeJS it's different because it sees your file system and can check multiple fallback locations. 

A great resource for ES6 features

git.io/es6