a2ui_dioxus/
lib.rs

1//! Dioxus backend for A2UI.
2//!
3//! Translates an A2UI component tree (the flat `id → ComponentModel` map owned
4//! by [`a2ui_base::model`]) into a Dioxus [`Element`] tree rendered into a
5//! desktop WebView, and bridges widget interactions back to the
6//! framework-agnostic interaction layer in `a2ui_base` via Dioxus's
7//! reactive-signals architecture.
8//!
9//! Of the six A2UI renderers this is the most architecturally distinct. Dioxus
10//! is a *reactive-signals* framework (like React): the runtime state lives in a
11//! [`Signal`] at the root, and the UI is a pure read of it — so unlike the Iced
12//! backend (Elm `view`/`update`, needs a `Message` enum) or the egui backend
13//! (immediate mode, needs a persistent `EditBuffers` state bridge), interactive
14//! widgets here read straight from the signal in render and write straight back
15//! through it on interaction. **No message enum, no state bridge.** The signal
16//! *is* the interaction channel: any write re-renders every component that read
17//! it.
18//!
19//! Two further Dioxus-specific simplifications:
20//! - **Recursive components** — the whole tree is one [`A2uiNode`] component
21//!   that renders itself per node (Dioxus supports recursion natively, unlike
22//!   Slint's bounded-depth codegen), so there is no flat-array workaround.
23//! - **WebView rendering** — Dioxus desktop renders to a system WebView
24//!   (WebKitGTK on Linux), so the bespoke dark theme is a CSS stylesheet
25//!   ([`theme::STYLESHEET`]) rather than a per-widget style-fn palette, and the
26//!   A2UI component kinds map to ordinary HTML elements + classes.
27//!
28//! Everything here lives behind the `backend` cargo feature, which pulls in the
29//! Dioxus desktop runtime. Without it this crate is an empty shell (it compiles
30//! with no dependencies beyond `a2ui-base`), keeping the workspace's default
31//! build light.
32//!
33//! [`Element`]: dioxus::Element
34//! [`Signal`]: dioxus::prelude::Signal
35
36#![cfg_attr(not(feature = "backend"), allow(unused_imports))]
37
38#[cfg(feature = "backend")]
39pub mod app;
40#[cfg(feature = "backend")]
41pub mod node;
42#[cfg(feature = "backend")]
43pub mod theme;
44
45/// The gallery root component — owns the state signals and renders the sidebar
46/// + preview pane + modal overlay. Construct from the gallery (or any host)
47/// and hand to `dioxus::launch`.
48#[cfg(feature = "backend")]
49pub use app::Gallery;
50
51/// The recursive per-node component. Re-exported so a host can render a raw
52/// subtree (`<A2uiNode id=.. base_path=.. />`) without the gallery chrome.
53#[cfg(feature = "backend")]
54pub use node::A2uiNode;
55
56/// The whole-gallery CSS stylesheet (the dark Catppuccin-Mocha + green-accent
57/// palette). Inject it via the desktop `Config`'s custom `<head>`.
58#[cfg(feature = "backend")]
59pub use theme::STYLESHEET;
60
61/// Re-export the core interaction pieces backends compose against, so consumers
62/// can `use a2ui_dioxus::{dispatch_event, apply_event_result, ...}` in one place.
63#[cfg(feature = "backend")]
64pub use a2ui_base::components::dispatch_event;
65#[cfg(feature = "backend")]
66pub use a2ui_base::focus::FocusManager;
67#[cfg(feature = "backend")]
68pub use a2ui_base::interaction::apply_event_result;
a2ui_dioxus/lib.rs

a2ui_dioxus/
lib.rs
