- Home
- Skills
- Zhanghandong
- Makepad Skills
- Robius App Architecture
robius-app-architecture_skill
- Shell
715
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill zhanghandong/makepad-skills --skill robius-app-architecture- SKILL.md12.0 KB
Overview
This skill documents Robius-style app architecture patterns for Makepad applications, focused on mixing synchronous UI code with a Tokio async runtime. It distills production-ready patterns for request submission, worker tasks, lock-free update queues, and startup/shutdown sequencing. Use it to design predictable, cross-platform (native + WASM) Makepad apps with robust background processing and UI wake-up semantics.
How this skill works
The skill describes how the UI thread submits typed AppRequest enums into a Tokio-backed request channel and how a worker_task spawns per-request async tasks. Background tasks enqueue DataUpdate items into a crossbeam SegQueue and call SignalToUI::set_ui_signal() so the main thread polls and applies updates inside widgets. It also covers static runtime initialization, Cx::post_action() usage for routed responses, and patterns for startup/shutdown state persistence.
When to use it
- Building a Makepad app that needs background async I/O or streaming APIs
- Designing clear UI ↔ async runtime communication using typed requests/actions
- Handling high-frequency updates from network or streams without locking the UI thread
- Implementing cross-platform async behavior compatible with native and WASM targets
- Establishing reliable startup and shutdown sequences with persisted state
Best practices
- Keep UI logic on the main thread and all blocking/async work in the Tokio runtime
- Use typed enums (AppRequest, DataUpdate) for requests and updates to make flows explicit
- Use crossbeam::SegQueue for lock-free, high-frequency background updates
- Always call SignalToUI::set_ui_signal() after enqueueing updates to wake the UI thread
- Use Cx::post_action() for async task results that need to be handled by the UI event loop
- Register base widgets before dependent modules in live_register() and pass shared state via Scope::with_data()
Example use cases
- Chat client with live sync: submit fetch or send requests from UI, stream incoming messages via subscribers
- AI assistant with streaming results: spawn async streaming tasks and push incremental tokens via SegQueue + SignalToUI
- Background sync service: worker_task listens for periodic tasks and posts state changes with Cx::post_action()
- Cross-platform app: use PlatformSend/UiRunner patterns to unify native and WASM task spawning
- High-frequency sensor or telemetry UI: enqueue frequent updates lock-free and apply them on Signal events
FAQ
Push a DataUpdate into the SegQueue and call SignalToUI::set_ui_signal(); on Event::Signal the UI should drain the queue and update state.
Where do I store the request sender for submit_async_request()?
Keep an Arc/Mutex-wrapped static or global (e.g., REQUEST_SENDER) initialized when starting the static Tokio runtime so the UI thread can send AppRequest values.