1

I have been looking at the following article https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import . There is a code snippet in the examples:

file.js

function getJSON(url, callback) {
  let xhr = new XMLHttpRequest();
  xhr.onload = function () { 
    callback(this.responseText) 
  };
  xhr.open('GET', url, true);
  xhr.send();
}

export function getUsefulContents(url, callback) {
  getJSON(url, data => callback(JSON.parse(data)));
}

main.js

import { getUsefulContents } from '/modules/file.js';

getUsefulContents('http://www.example.com',
    data => { doSomethingUseful(data); });

getUsefulContents is exported in file.js and later imported in main.js. But getJSON is not exported. Intuitively it seems to me that since the function getJSON is not exported to main.js and getUsefulContents depends on getJSON there should be an error. But how is it that inspite of importing only one function from file.js, the dependent function also works in the scope of main.js. Is there something I should know about scoping in case of exports or any other concepts? Any clarification would help, thanks.

sak18
  • 101
  • 13
  • `getUsefulContents()` is referenced as the import and executes in the closure of the enclosing module. Therefore, `getJSON()` is in the same execution context as `getUsefulContents()` – Randy Casburn Nov 20 '20 at 18:47
  • Hi @RandyCasburn . Could you elaborate more on the terms closure and execution context, maybe in the answer by providing any references. Would like to know how this works. Might be helpful for future reference as well. Thanks. – sak18 Nov 20 '20 at 18:59
  • Is there a similar thing in C or Java? – sak18 Nov 20 '20 at 19:09
  • 1
    @sak18 [How do JavaScript closures work?](https://stackoverflow.com/q/111102) - in short, it's just the function with all the outer scope of it. So, if you have a function and some variable `x` declared in the same scope, the function will have access to `x`. – VLAZ Nov 20 '20 at 19:10
  • 2
    @sak18 - in Java a _similar_ (but not the same) concept is the Context interface. Think of a closure as a bubble of isolated code that no other code can gain access to. A module is one of those bubbles. So the only way to provide access into the bubble is to _export_ that access. As I said though, when importing we are binding a reference from one context into another context. The code executes within its own context - within its own bubble - within its own Module. – Randy Casburn Nov 20 '20 at 19:21
  • @sak18 - you may find it interesting to know that Modules act like Singletons. So if you _export_ a binding to a variable and several modules each import that variable, that variable will reflect any value set by any of those modules. Could be an app configuration, utility functions, app data model, state machine, etc. – Randy Casburn Nov 20 '20 at 19:29
  • @RandyCasburn I guess you can also liken it to static imports. If you import `org.hamcrest.Matchers.allOf` them you can use `allOf()` in your code, even though you've not imported anything that method relies on. – VLAZ Nov 20 '20 at 19:30
  • @VLAZ - I think so too, but try to avoid the _static_ word because of the "class" connotation. So it's _static_ without classes. That might be weird to many. – Randy Casburn Nov 20 '20 at 19:38
  • @VLAZ - and, you can `import * as something from './mymodule.js'` to, Just like `org.hamcrest.Matchers.*` :-) – Randy Casburn Nov 20 '20 at 19:41

0 Answers0