Async Event Handling

[ghost]

Hi, I was reading this part of the book and was wondering what the point of Event::Tick is.

Also, it looks like they send an Event::Render at 30 FPS consistently, but lots of apps don't need to render when nothing is happening. They only render when a key is pressed and something changes as a result. This sounds like its synchronous, but these same apps are asynchronous and use tokio and tui/ratatui (some text editors I've looked at). In fact, there already is a non-async counter app, so what is the point of the async counter app? Especially in this case, it seems wrong to render 30 FPS in an app that only changes on user input. I say all this knowing that I'm probably missing something, and I would appreciate if one of you could help me understand this. My understanding of async might be flawed. Thanks for this library and book!

[kdheepak]

This is a great question and thanks for posting it!

You are right that this part of the book is sending Event::Render 30 times a second, which is completely overkill. I think I'll change it to something more reasonable (4 times a second?) and change Event::Tick to 1 time a second.

The point of having two kinds of ticks, Event::Tick and Event::Render is that sometimes you want to refresh your data at a consistent rate (e.g. every 60 seconds or every second) and sometimes you want to update your UI much faster than that. This is particularly true when you are doing animations or rendering a progress bar or a spinner (which needs to be updated even then there's no user input).

I think it would be possible to do everything using just one tick, i.e. Event::Render and then update the data every 60th Event::Render (if render was 60fps) to get a data update every second. This seems a little cleaner (even if it more complex). I also don't like doing non-ui work on a Event::Render and having a Event::Tick is nice for that.

I'll rework this answer into the documentation to expand on this part of it more.

[ghost]

Yeah, you might want to create one tutorial that explains what to do for applications that render on input events (like a text editor), and another for things that need to render at a constant rate (like what you said: animations). The reason I originally had this question was because when looking through the source code of the helix text editor, I didn't find any sort of tick thing. It looks like it only renders on input events, which is common in terminal apps. If this type of thing should be done asynchronously, maybe make a tutorial (e.g. no tick rate or render rate). If it shouldn't, the simple synchronous app tutorial is probably fine.

[joshka]

I agree with @tz629. This tutorial is IMO a bit to synthetic to be useful. I wrote a small stopwatch example that could be a good fit for explaining the need for rendering things async, and we've also floated the idea of a pomodoro app. Realistically though, the need for async comes from doing some sort of file or network IO, not from simple applications rather than the need to update at some fixed interval like 60fps.

[kdheepak]

I can merge the current async counter tutorial contents into the stopwatch tutorial and make just one tutorial out of the two. Would that be better than the status quo?

[ghost]

What approach do you think is best for a text editor? I'm still planning how to structure my own text editor and I don't know if I should use async or not. Text editors don't render at a specific frame rate, but when a key is pressed. The neovim text editor uses libuv, which is asynchronous, but handles input in the way I said earlier. I'm kind of confused by this.

[joshka]

There's still likely asynchronous processes that happen in a text editor. Anytime you want to do something that takes time and also want to remain responsive to the user's input. E.g. loading completions / annotations / performing searches / etc. You might also use a high fps for things like animated scrolling, progress bars etc.

@kdheepak maybe - I think we really need a database tool, or something else that inherently has a time dimension as part of it (perhaps an LLM tool, or what about something like postman?)