If you've worked on any react or next.js application in the past, you've probably noticed that it's very unopinionated in general, especially when ...
For further actions, you may consider blocking this person and/or reporting abuse
Also do I need this if I enable top-level awaits in webpack? Cuz I do that now that all major browsers support this.
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.
When’s this coming?
There's currently an open PR for this in react/rfcs so could be 3 days could be soon TM. Hopefully sooner than alter.
I personally hope that it's sooner rather than later.
yes
So a Suspense without UI fallback. Am I right?
You missed such a cool chance for a pun in your conclusion!!
Do tell!
Would be interesting to see if we could use this to create use() versions of hooks, like apollo's useQuery, that would be easier to use conditionally.
Basically yes.
But also I'm not so sure I'd recommend doing a custom implementation of a hook that a library already provides. Usually the stuff a library provides you is made to work with the rest of their stuff.
Awesome!
It's an interesting addition to hook functionality, but the thing that stands out to me is the fact that this is a hook that is allowed to be called conditionally.
Hooks are normally known for not being intended to be called conditionally. The
usehook introduces an exception.Now, the RFC talks about this, and it makes a point that this is fine, because it's only going to be the one single exception, and that rather than having to remember a bunch of arbitrary exceptions, we just need to remember this single one.
I think that this nevertheless still introduces a confusing piece of knowledge that you have to remember about hooks and about the special behavior of this proposed hook.
As we pile on more and more of this kind of complexity on top of hooks, and more magical behavior, it makes me wonder: are hooks the wrong direction? Were they a mistake for React?
I really enjoyed your verbose and well-styled comment 😌
I'm personally more of a Nuxt user, but thanks for your share.
In which version of React is it coming out?
This is cool, how about using Suspense with promise wrapper?
Is use hook execute on every render? Unlike useEffect hook we can decide when request will be called out