Improve Parity With Crossterm Backend

[callmeclover]

Currently, ratzilla isn't very "drop-in" as a web backend for ratatui, as it uses specialized draw functions and doesn't have many events. I would like to improve upon this. I plan on forking this repository and working on parity between this project and crossterm, as well as with ratatuis Backend trait. If this is acceptable, this should act as a tracking issue. Here are my plans:

• Parity!
  • Replace draw_web with standard draw function.
  • Replace all on_..._event functions with a single read function.
    • Consolidate all events into an enumerator.
    • Utilize more of the event API from JavaScript.

I'll add more as I compare the API of this project with ratatui and crossterm.

Would you be open to this?

[orhun]

Heya!

I'd be open to this! It's going to be probably breaking as hell but that's fine, we're still 0.x

Feel free to send a PR! I'd be also interested in discussing API decisions btw

[callmeclover]

Forked! I'll start working on the events tomorrow, it'll probably be the easiest to tackle.

[callmeclover]

@orhun I was thinking about whether to make Event a trait or enum, since it wouldn't be exhaustive as an enum. Any thoughts? Also, do you think we could work with a stream for a read/poll function? If not, I'll probably still use a Vec<Event> for a queue.

[orhun]

How a trait would look like? I initially thought an enum would be a better fit.

I'm not sure about polling (or if web-sys would allow that). Probably needs some investigation. Using Vec<Event> in the meantime makes sense.

[callmeclover]

How a trait would look like? I initially thought an enum would be a better fit.

I was thinking that a trait could work better for custom events, but honestly it'd probably be better to just mark Event as #[non_exhaustive] and give it a Custom(CustomEvent). Don't know how that would work listener-wise though.

[vcque]

Hi!

That would be awesome to have that!

Although after trying to do that recently myself I think the input (and threading) abstraction needs to be defined in ratatui itself for each backend to implement.

Here's my attempt FWIW: https://github.com/vcque/lost-signal/blob/main/crates/client/src/tui_adapter.rs
ratzilla impl: https://github.com/vcque/lost-signal/blob/main/crates/client-wasm/src/ratzilla_adapter.rs
crossterm impl: https://github.com/vcque/lost-signal/blob/main/crates/client-term/src/crossterm_adapter.rs

[callmeclover]

Hi!

That would be awesome to have that!

Although after trying to do that recently myself I think the input (and threading) abstraction needs to be defined in ratatui itself for each backend to implement.

Here's my attempt FWIW: https://github.com/vcque/lost-signal/blob/main/crates/client/src/tui_adapter.rs ratzilla impl: https://github.com/vcque/lost-signal/blob/main/crates/client-wasm/src/ratzilla_adapter.rs crossterm impl: https://github.com/vcque/lost-signal/blob/main/crates/client-term/src/crossterm_adapter.rs

If you're talking about the draw_web -> draw change, then maybe, but then again, a ratzilla::web_render_loop would be just as good.
I'll definitely be looking at your code as another reference though.

[orhun]

Hey again!

Although after trying to do that recently myself I think the input (and threading) abstraction needs to be defined in ratatui itself for each backend to implement.

That's a bit against the current architecture we have. Ratatui is a UI widget library and we leave the terminal manipulation to the user basically. But at the same time, we will be providing backends such as ratatui-crossterm with the next release. So that makes me think 🤔

[vcque]

That's a bit against the current architecture we have. Ratatui is a UI widget library and we leave the terminal manipulation to the user basically. But at the same time, we will be providing backends such as ratatui-crossterm with the next release. So that makes me think 🤔

I don't see ratatui providing backends for the main terminals as a problem as long as the core is independent from one.

My point was that input handling is somewhat core to building widgets and not providing a common interface for them would force crate or app' devs to support specific backends anyway.

For example, The ratatui-input crate had to define an InputRequest struct and convert crossterm and termion events to it. That means it can't be used with ratzilla out-of-the-box. Each widget provider which wants to support input handling has to do the same work to support one or more backends.

For my specific use case, I wanted to have my little tui game either on term or browser (works great btw, thanks!) without having to write backend specific code. But I also had to write a compatibility layer for crossterm/ratzilla.

I think if ratatui provided a common interface for inputs that each backend could/would implement, that would allow widget devs to write portable widgets.

[vcque]

If you're talking about the draw_web -> draw change, then maybe, but then again, a ratzilla::web_render_loop would be just as good. I'll definitely be looking at your code as another reference though.

I'm not sure what you mean by ratzilla::web_render_loop. It just seems that ratzilla needs to own the rendering loop/callback which is quite different from ratatui which allows to call draw at any point.

[callmeclover]

@vcque @orhun

It just seems that ratzilla needs to own the rendering loop/callback which is quite different from ratatui which allows to call draw at any point.

The issue is that we can't just use loop, because we're targeting WASM: we HAVE to use requestAnimationFrame to create a loop, and that's where Ratatui fails. WASM wasn't really made to host a terminal environment.
That's why draw_web exists; as a middleman. I don't like it, but there's no standard way to go about it. I will most likely use a loop_web instead of draw_web for parity, though.

[orhun]

Or maybe render_loop (since it might be more conventional)?