It's one way to do things. There's a bunch of things I'd choose to do differently though. (I've never reviewed this before, so this is a first encounter review):
tick rate and frame rate are only relevant when you have stuff which needs to be polled or animated at a regular cadence. Many apps don't need that at all
stdout is faster to render. stderr is better if you might need to output stuff that will end up in a pipe
mouse and paste are bad names for fields
start() is too long and responsible for too many things
there are variables prefixed with _ which are actually used
event_send should not be unwrapped, it is expected to return an error when the recieving side is closed, that error can either be ignored or used to stop the sending loop
I'd simplify this and wrap the crossterm events with a single Event::Crossterm(...) variant instead of a variant per crossterm event. The extra variants don't really add value
I'd separate the event loop stuff from the terminal handling stuff more explicitly
tokio advises running blocking IO on a blocking thread pool - that hasn't been considered here (it's not something I've experimented with however)
If you don't specifically need async, then I'd avoid this and keep it simple / work out the bits you actually need based on building them up yourself. You might find agreement with some of these points, or disagree with them. That's fine - there's many ways to structure things and many of them will work well. Most of the above tends to the subjective side of things rather than purely objective. The code will work for you, but may not be right for you.
In a discord conversation about https://ratatui.rs/recipes/apps/terminal-and-event-handler/ I wrote:
It's one way to do things. There's a bunch of things I'd choose to do differently though. (I've never reviewed this before, so this is a first encounter review):
If you don't specifically need async, then I'd avoid this and keep it simple / work out the bits you actually need based on building them up yourself. You might find agreement with some of these points, or disagree with them. That's fine - there's many ways to structure things and many of them will work well. Most of the above tends to the subjective side of things rather than purely objective. The code will work for you, but may not be right for you.
I'd suggest leaving this as-is for now, but noting it should be cleaned up a bit in the future once https://github.com/ratatui-org/ratatui/pull/1180 lands