1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
//! Framework-agnostic component **behavior** — the `handle_event` logic for
//! the interactive component types whose handlers touch only core types.
//!
//! Rendering is backend-specific (ratatui paints a `Frame`, Slint builds a
//! reactive tree), but the *semantics* of how a component reacts to a key press
//! (fire an action, write a data-model value, toggle, …) are identical across
//! backends. Extracting that logic here lets every backend reuse one
//! implementation instead of duplicating it.
//!
//! Each submodule exposes
//! `pub fn handle_event(ctx: &ComponentContext, event: &InputEvent) -> Option<EventResult>`.
//! [`dispatch_event`] routes by component-type name.
//!
//! ## Scope
//!
//! Only handlers with no backend coupling are extracted here:
//! [`button`], [`checkbox`], [`slider`], [`text_field`]. The remaining
//! interactive types stay backend-specific for now:
//! - `choice_picker` / `tabs` — their handlers share locally-defined
//! deserializable types (`ChoiceOption`, `TabEntry`) with the ratatui render
//! path; extracting them would pull render types into core.
//! - `date_time_input` — its handler shares `chrono` parsing helpers with render.
//! - `audio_player` — drives real audio hardware (rodio), inherently backend-bound.
//!
//! A Slint backend reuses the four shared handlers via [`dispatch_event`] and
//! reimplements the rest locally until they are promoted here.
use crate;
use crateComponentContext;
/// Route a key-press event to the named component type's [`handle_event`].
///
/// Returns `None` for types without a shared handler (unknown types,
/// non-interactive types like Text/Column, or the backend-specific interactive
/// types listed in the module docs). Callers build a [`ComponentContext`] for
/// the target component, then call this.