5 ms·
> Even assuming all goes well, you've prevented yourself from doing any other work, like rendering views that don't depend on that data. Is that right? `await`
by rco8786 10y ago
> Even assuming all goes well, you've prevented yourself from doing any other work, like rendering views that don't depend on that data.
Is that right? `await` is non-blocking, no?
- nolanl 10y agoIt's not so much about blocking as it is about delaying the module waterfall. E.g. a module that did `await new Promise(_ => setTimeout(_, 5000))` at the top would prevent any of its dependents from being loaded for 5 seconds.
- domenicd 10y agoThat's false. Module loading and execution are separate stages. The dependent modules would load before this await is ever reached.
- gavinpc 10y agoWait... so the OP's premise is completely wrong? Doesn't the body of a module have to complete before dependent modules will execute their bodies? In other words, if you put for (let i = 0; i < 10e8; i++) // blah in the body of a module, wouldn't that block dependent modules for the duration of the loop? Would top-level await be different? edit The premise, as I understand it, is that the module itself is treated as the "currently-executing method" for the purpose of the `await`.
- domenicd 10y agoIt would block dependent module execution, but not dependent module fetching, which is the actual expensive part.
- s_kilk 10y agoIt's kinda funny how the semantics of this thing are so non-obvious and nuanced, that it takes so much effort to explain to people how it works :)
- domenicd 10y agoIt's not that complicated; unfortunately a lot of FUD has been spread about alternate models based on misconceptions, which definitely makes it tricky to explain because you have to overcome that FUD.
- nolanl 10y agoSounds like I misunderstood. Thanks for the correction!
- tribex 10y agoAwait essentially is blocking.
- rich_harris 10y agoAn async function is non-blocking. await is blocking within the async function. Top-level await basically boils down to a proposal to wrap your entire app inside an async function.
- domenicd 10y agoThat's false. It wraps each individual module within an async function. They can each proceed concurrently. (And all of them proceed after any `import`ed modules load.)
- untog 10y agoBut any module with a dependency on a module with top-level await will have to wait for that dependency. As will anything depending on that. It's not difficult to imagine some code nested deep in some NPM module completely changing the load behaviour of your app without you knowing.
- domenicd 10y agoYes. Let's rephrase that first sentence. "Any module with a dependency on data that it needs to execute will have to wait for that data before it executes." That's a good thing.
- untog 10y agoIs it a good thing for your entire app to be held up by any component that needs to load data? I'm sceptical.
- domenicd 10y agoBut your entire app wouldn't be held up! Only that subgraph.
- rich_harris 10y ago
- giulianob 10y ago`await` will "block" the current method but the current calling method will continue executing unless that method calls await itself (and so on). You can perform whatever other work needs to happen that doesn't require on the data. It's just a matter of having the right architecture in place that doesn't just waits for the request to finish before doing additional work.
- bmeck 10y ago`await` allows the event loop/job queue to run while waiting. However, while using `import` declarations, your module will not run until all imports have completed; this means that your module will be suspended while the dependency awaits. If your app is shipped as a single bundle this means your entry point would be unable to run anything while dependencies are awaiting if you use `import` declarations. If your app places runtime dependent imports into a dynamic import like using `import()` as a function, it would not be suspended while waiting.
- domenicd 10y agoExactly correct. But note that > your entry point would be unable to run anything while dependencies are awaiting is very different from the situation with synchronous I/O (in a single-threaded environment). With sync I/O, not only is your entry point unable to do anything (which is what it chose to do, by using `import` instead of `import()`), your entire app is unable to do anything! So other entry points are also blocked. Even worse, since sync I/O blocks the event loop, it prevents the user from interacting with your web page or Node app---e.g. scrolling, clicking links, pressing Ctrl+C to exit, and so on.