6 ms·

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_f

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.

lucasyvas 4y ago
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?
- wishawa 4y ago
  The full example code is here: https://github.com/wishawa/async_ui/blob/main/examples/gtk-login-form/src/main.rs 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.
- wishawa 4y ago
  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 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.
  - kwkelly 4y ago
    Crank.js uses async and races for control flow. It’s pretty interesting

lucasyvas 4y ago

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?

wishawa 4y ago
The full example code is here: https://github.com/wishawa/async_ui/blob/main/examples/gtk-login-form/src/main.rs 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.
wishawa 4y ago
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 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.
- kwkelly 4y ago
  Crank.js uses async and races for control flow. It’s pretty interesting