EDIT: JS is already dynamic. If a function returns a promise then it should be awaited and render blank or nothing in the vdom. This is obvious, except in JS where architecture prefers synchronous-only design with async being an afterthought.
Hope this is helpful.
Wouldn't making the lifecycle methods async not fix this?
If the entire runtime was async then wouldn't that naturally allow any other user/component level async calls to naturally work as expected?
In some way, Suspense is "making them async" btw. Or, rather, making render async. So maybe we're talking about the same thing.
If the React runtime was completely async (as in returning promises for every function) from the `ReactDom.Render()` to the lifecycle methods to render(), then user code can transparently support any `await fetchSomeData()` calls. Basically change every method from:
f(x) => T;
async f(x) => Promise<T>;
It's the general state of Javascript and frontend code which is finally starting to understand what multithreading and concurrency is.
It's surprising that JS has so much history with callbacks and events but async methods are unsupported or require workarounds by so many core frameworks and libraries which default to synchronous APIs for everything.
So what if React is massively bloated, stupid syntax, can't use regular HTML, can't use regular CSS, can't use async/await, have to do everything a special way...literally, SO WHAT. It IS REACT! OMG behold it's glory. It came from FB, maybe if we use it we can scale like FB!
Omg the idiocy. But keep on slavishly following the next front-end dev trend. I can't tell whether front-end dev culture is a massive circle-jerk or cargo cult. And don't mention the irrational hate attempted to be heaped onto anyone who dares question the programmatic thinking of the official line of the React Appreciation Society.
Why not just ask people why they use X? Plenty of veteran developers on HN could tell you why they like React despite a sea of alternatives, but it's easier to just cast aspersions instead of understanding.
It's a shame to see this on HN which is supposedly a community of craftspeople who build things. If you can only come up with insults for why another group of people do something, it's time for you to get up off your ass and ask someone in that group. And this extends beyond just engineering, it's how you understand other people in general.
I'm pretty sure I'm being baited here but all of these are categorically false.
React is the first framework that allows me quickly build rich web-apps that load fast, perform fast, and have a structure and order to them that keeps them enjoyable to work on as they get bigger.
I have no loyalty to Facebook and I've tried pretty much every major framework or library that's gained traction in the past 15 years.
It's too low-level and hard to manage (if you care about correctness and performance). You eventually have to invent your own locking (to enforce ordering guarantees between read/update remote calls) and do resource management by hand (async task becomes something you have to keep track of, in case you need to abort/restart it, recover from network errors, etc.)
There are much better abstractions for getting remote data. State machines are one such abstraction that I like to use.
I'm still awaiting the day when web devs rediscover that coding an event driven FSM with pure functions is acctually the most flexible and easiest to reason about way to manage client-server communication. Meanwhile it's my secret sauce.
There's no reason why these frameworks have to treat async functions as a special case. If the promise hasn't resolved then don't render that node. The fact that it was ever blocking is just a byproduct of sync-only thinking. This is extremely common in JS where libraries are designed around sync first and have workarounds to support async.
You get a reference to it and it's a resource to manage manually. You need to ensure that the side effect you attached to it at one time will not mess up anything in the future, despite not knowing in what situatuion in the future it will be resolving. User might have done many other operations with tha app in the meantime, etc.
You may also want to carry around an AbortController, in case you may need to cancel the operation behind the promise (like a fetch).
So promises are just references to some resources.
Async functions actually make the management of async jobs harder, since you're basically encoding a sequence of jobs into the structure of the functions you define and you don't even see the promises behind those, and you'll not have control over their execution from the outside, unless you explicitly code for it at every point.
You don't get to say: ok, whatever's going on now with all my data fetching async functions that may be currently running, I want to pause them in whatever state they may be now. Or cancel them right now, or restart them from where I paused them.
With explicitely coded FSM, you can do any of this, easily.