Top level await is awesome for sure, but as far as I know all it allows you to do is use await without wrapping it in an async function, which comes with it's own set of problems: gist.github.com/Rich-Harris/0b6f31...
outlined nicely by Rich Harris here, would recommend giving it a read it's fantastically explained.
essentially the TL;DR version of it is that if you use top level await you're essentially blocking all modules who depend on the resolution of that top level await. Which is not great. the use hook will not block anything,
Hey, thanks for the response. It turns out that the gist had an edition in February 2019 that basically states that his concerns are no longer valid since a variation B took over the previous specification. This variation B no longer blocks siblings and therefore top-level await ended up being good and nice.
Don't know much about those as I am primarily a .Net backend developer. I just know enough of ReactJS to keep my team aligned whenever they go nuts and start coding like crazies.
I can say, though, that top-level await seems to work nicely in ReactJS. I made for my team the wj-config package to end some configuration madness they had. Version 2 requires top-level await. So far so good.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Top level await is awesome for sure, but as far as I know all it allows you to do is use await without wrapping it in an async function, which comes with it's own set of problems: gist.github.com/Rich-Harris/0b6f31...
outlined nicely by Rich Harris here, would recommend giving it a read it's fantastically explained.
essentially the TL;DR version of it is that if you use top level await you're essentially blocking all modules who depend on the resolution of that top level await. Which is not great. the
usehook will not block anything,But good question Jose 👍
Hey, thanks for the response. It turns out that the gist had an edition in February 2019 that basically states that his concerns are no longer valid since a variation B took over the previous specification. This variation B no longer blocks siblings and therefore top-level await ended up being good and nice.
That is correct there was a whole V8 response to his concerns as well here: v8.dev/features/top-level-await
Was not aware they addressed his concerns since the first time I've read about it. Thanks for the clarification Jose :)
Now the only concern I have left is how supported this feature is in tools such as rollup or vite.
Don't know much about those as I am primarily a .Net backend developer. I just know enough of ReactJS to keep my team aligned whenever they go nuts and start coding like crazies.
I can say, though, that top-level await seems to work nicely in ReactJS. I made for my team the wj-config package to end some configuration madness they had. Version 2 requires top-level await. So far so good.