search

tc39 / proposal-defer-import-eval

A proposal for introducing a way to defer evaluate of a module
https://tc39.es/proposal-defer-import-eval
MIT License
208 stars 12 forks source link

Detect that a module is currently in its lazy (loaded but not evaluated) state? #11

Closed getify closed 10 months ago

getify commented 2 years ago

Is the intention of this proposal that the laziness status -- whether it's been loaded-but-not-evaluated or also-fully-evaluated -- be detectable by the userland code, or that it be be opaque (impossible to detect)?

To wit: would the lazily loaded module's binding value have a typeof that indicates anything different between whether it had been evaluated or not? Or would any access expression (such as typeof theModule) force the evaluation of the module first, thereby thwarting detection?

My experience with dynamic resource loading (going back as far as 2009 with the popular-at-the-time LABjs loader) is that many use-cases around wanting to defer and dynamically load resources imply needing to inquire about the status of such loading rather than having it be entirely opaque. For example, if you know a resource is fully ready to use, you might render the asset/UI for it right away, but if you know there might be a noticeable delay (like loading it, or even just evaluating it), you might choose to display a spinner or placeholder and keep the main asset UI un-rendered until it's "complete".

codehag commented 2 years ago

At the moment, its made to be opaque -- laziness is thought of as transparent layering of information that "this doesn't need to execute yet, but if I use it for the first time -- run the code". But as you say, there are cases where you may want to detect something like this. We have it in the firefox codebase under isModuleLoaded and co, but we were trying to remove all of them.

That said, I think there may be room for that if it is necessary. I would put it off for now though, and give it proper thought. This may be related to weak imports.