it looks like if the server doesn’t respond right away—which is expected
the client/server coordinate in advance like a sports team; so this isn’t RPC. The server client does not need to ask the client server for anything at all [ed: fixed errors]; the information simply shows up. Therefore, there may not even be a Pending exception at all, because maybe the server information arrived before the client was ready to render it! For more info about the network planner see UIs are streaming DAGs.
Now, I guess I’m supposed to know that when the
server does respondinformation is available, that thetrwill be inserted?, and I’m supposed to know that the"loading"will be removed fromdom/props?
Here with try , the catch body mounts when Pending is present and unmounts when Pending “goes away.” (dom/div ...), (dom/props ...) represent point writes to the DOM. This resource management of the DOM is performed by a functional effect system (Missionary) which guarantees that all the resources are constructed (mounted) and destroyed (unmounted) in the right order, per the DAG. Because all the interesting work is done by Electric & Missionary, electric-dom is only 300 LOC. Note it’s not just try; this is the case for all control flow operators - if, e/for, try/catch etc.
See demo-2-toggle — clone the repo and run the demos it takes 20 seconds — you’ll see the functional effect system maintain the DOM in response to the atom changes. Quiz to check your understanding: what is dom/text ?