Given that ratatui has StatefulWidget, what does tui-react enable that ratatui does not?

[matta]

I am not quite understanding what tui-react provides and how it differs from modern ratatui. I have a feeling I am missing something.

From the README:

Why tui-react?

I kept having a terrible feeling when managing state with tui widgets when writing dua, and after trying many things, I realized what the problem actually was. It took me some time to realize it's not possible to have stateful components in with TUI, and I admire the smarts that went into the API design! After all, it effectively prohibited this! Amazing!

That's why I implemented my own terminal and some key components, based on the ones provided by TUI, which can serve as standard building blocks in a stateful world.

Thus far, the experience was fantastic, and it feels much better than before. Let's see what happens with it.

Yet ratatui has StatefulWidget since about four years ago. What is possible with tui-react that is not possible (or difficult) in ratatui?

[Byron]

Thanks for bringing this up - the README could certainly use an update.

It was valid during tui times when certain paradigms couldn't be done. By now, this can probably be done just as well with ratatui alone.

The problem here is that I have no intention to change something that's working, for dua primarily, so these crates are probably going to stay.

If you like, please feel free to submit a PR with a README update to clarify this, and be less confusing for the next reader who comes along.

[matta]

Thanks, Byron. I appreciate your reply.

You might find this commit interesting: matta/dua-cli-without-tui-react@c22a718

I found that porting https://github.com/Byron/dua-cli off the tui-react Terminal was relatively easy.

The key insight is that any struct may both implement Widget and bind to mutable references to other objects. Thus, there are no strong immuability guarantees enforced by the current ratatui rendering API. I suppose it is at best a strong encouragement.

The technique in my commit uses a closure to establish a level of indirection between the Widget trait used by ratatui Frame::render_widget API and the application's code. Because it is possible to bind mutable references to the closure, they are passed through to arbitrary application level rendering code.

My first attempt used a bespoke struct that held the mutable references needed just for the one call site in dua's eventqueue.rs. I only came up with the more general closure based approach after some head scratching.

Let me know if you are interested in the above as a PR. Of course, it is perfectly fine if you are not.

Either way, I think I'll approach the ratatui people about this approach to see if they'd like to bless this approach as a way to bridge ratatui into non-Widget based rendering approaches. If the tui-react crate's README is ever updated it'd be nice to point something like an example in the ratatui repo that shows this kind of approach.

[Byron]

You might find this commit interesting: matta/dua-cli-without-tui-react@c22a718

I found that porting https://github.com/Byron/dua-cli off the tui-react Terminal was relatively ea

Indeed, that looks like something that should be a PR. I'd love to use more of ratatui as it would allow dua to benefit more from improvements.

Either way, I think I'll approach the ratatui people about this approach to see if they'd like to bless this approach as a way to bridge ratatui into non-Widget based rendering approaches.

I think they bless it already as with tui, this definitely wasn't possible due to the way ownership was handled in the terminal draw. At least that's how I remember it - it felt like it was intentionally prohibited using the type-system.

Finally, a dua-PR would definitely be appreciated :). Thanks again.