You're right that components should intuitively pend forever. But with Async UI, the line between a component and a normal async function is blurry; our login_form eventually returns, so it is a normal async function, but it also renders something, so it is kind of a component...

Concretely the login_form function works by racing a render (a true, never-completing component) with a "listener" future that completes when the user submits their login. Once the listener completes, the race is over and the render future gets dropped. We can then return from login_form.

This pretty interesting - does it take inspiration from anything? I personally haven't seen anything like this.

It would also be great to see example code for that - it's the most significant part where I was looking for more information but couldn't find it.

Edit: A bit unrelated, but the tokio vs async-std split continues!

Edit 2: How does error handling work? Is check_login a component or regular request?

The async control flow is not directly inspired by anything. It is a cool side effect of using async for everything that I myself only discovered once I started writing examples.

Async UI as a whole is inspired by the simple fact that UI is an effect system[1], and async is also an effect system.

[1]: https://en.wikipedia.org/wiki/Effect_system

Re async split: Diversity promotes innovation :)

Re error handling: There's no real support yet. For now when I hit an error I just render nothing. I might add support for components returning Result<_, _> in the future.

Crank.js uses async and races for control flow. It’s pretty interesting

The full example code is here: https://github.com/wishawa/async_ui/blob/main/examples/gtk-l....

(except for that invalid_login_popup is not a real popup because I haven't implemented popups yet)

I'll add a link to it in the blog post.