Hey!
What would be definite purpose of having to define the export clause(named or otherwise) in a module ?
Eg. if one of the exported property(function) accesses a non-exported property in the module, this function still works correctly when invoked in a js file that has imported only the exported property(function)
So, the export clause doesn’t seem to limit scope.
So that would be 1 “definite purpose” for me. Also, including a JS file within another JS file used to be rather annoying, and the import/export syntax seems to be aimed at improving that.
If I understand right, the non-exported variable can only be accessed through an exported variable. It cannot be accessed (within the imported environment) without first accessing one of the already exported variables.
Based on similar discussion on this forum, personally I understood that if we use exported object that access non-exported objects - this will work because it use it’s own scope which includes non-exported one. But if we try directly access smth that not exported - this will fail, as we try to access object that currently not in our scope.
By exporting smth we make it part of the scope we want to work with.
Maybe one analogy could be that when I export function, lets say “count apples in the box” which is stored in my friend’s room. Imagine that this function actually is “call my friend and ask him to find box, open it and count apples”. This basically made me include virtually his room into my scope. But myself I cannot go find box or open it, because my scope is only my room - the box simply doesn’t exist for me. In order to access box directly, I need to make it exportable, like asking him to pass it to me.