Expand description
App update service and other types.
The UPDATES
service can execute arbitrary futures and setup update handlers. It can also be used to request update,
info rebuild, layout and render for any widget. Note that from inside the widget you should use the WIDGET
service instead,
as it is more efficient.
The example below setups a handler that is called every app update.
use zng::prelude::*;
zng::update::UPDATES
.on_pre_update(app_hn!(|args: &zng::update::UpdateArgs, _| {
println!("pre_update #{}", args.count);
}))
.perm();
Updates are coalesced, multiple requests for the same widget will cause it to only update once, and multiple widgets
can update on the same pass. See the Main Loop docs in the app
module for more details.
§Full API
See zng_app::update
for the full update API.
Structs§
- Updates that must be reacted by an app owner.
- Represents a single event update.
- Widget info updates of the current cycle.
- Widget layout updates of the current cycle.
- Represents an
on_pre_update
oron_update
handler. - Widget render updates of the current cycle.
- Update schedule service.
- Represents all the widgets and windows marked to receive an update.
- Weak
OnUpdateHandle
. - Widget updates of the current cycle.
Enums§
- Identify node and app-extension operations that can be requested.
Traits§
- Represents a set of widgets that subscribe to an event source.
- Extension methods for infinite loop diagnostics.