robius-app-architecture_skill

This skill guides structuring Makepad apps with Robius patterns, enabling async backend integration, signal-driven UI updates, and Tokio-runtime orchestration.
  • 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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
robius-app-architecture skill by zhanghandong/makepad-skills | VeilStrat