Calling the Frontend from Rust
This document includes guides on how to communicate with your application frontend from your Rust code. To see how to communicate with your Rust code from your frontend, see Calling Rust from the Frontend.
The Rust side of your Tauri application can call the frontend by leveraging the Tauri event system, using channels or directly evaluating JavaScript code.
Event System
Tauri ships a simple event system you can use to have bi-directional communication between Rust and your frontend.
The event system was designed for situations where small amounts of data need to be streamed or you need to implement a multi consumer multi producer pattern (e.g. push notification system).
The event system is not designed for low latency or high throughput situations. See the channels section for the implementation optimized for streaming data.
The major differences between a Tauri command and a Tauri event are that events have no strong type support, event payloads are always JSON strings making them not suitable for bigger messages and there is no support of the capabilities system to fine grain control event data and channels.
The AppHandle and WebviewWindow types implement the event system traits Listener and Emitter.
Events are either global (delivered to all listeners) or webview-specific (only delivered to the webview matching a given label).
Global Events
To trigger a global event you can use the Emitter#emit function:
Webview Event
To trigger an event to a listener registered by a specific webview you can use the Emitter#emit_to function:
It is also possible to trigger an event to a list of webviews by calling Emitter#emit_filter. In the following example we emit a open-file event to the main and file-viewer webviews:
Event Payload
The event payload can be any serializable type that also implements Clone. Let’s enhance the download event example by using an object to emit more information in each event:
Listening to Events
Tauri provides APIs to listen to events on both the webview and the Rust interfaces.
Listening to Events on the Frontend
The @tauri-apps/api
NPM package offers APIs to listen to both global and webview-specific events.
-
Listening to global events
-
Listening to webview-specific events
The listen
function keeps the event listener registered for the entire lifetime of the application.
To stop listening on an event you can use the unlisten
function which is returned by the listen
function:
Additionally Tauri provides a utility function for listening to an event exactly once:
Listening to Events on Rust
Global and webview-specific events are also delivered to listeners registered in Rust.
-
Listening to global events
-
Listening to webview-specific events
The listen
function keeps the event listener registered for the entire lifetime of the application.
To stop listening on an event you can use the unlisten
function:
Additionally Tauri provides a utility function for listening to an event exactly once:
In this case the event listener is immediately unregistered after its first trigger.
Channels
The event system is designed to be a simple two way communication that is globally available in your application. Under the hood it directly evaluates JavaScript code so it might not be suitable to sending a large amount of data.
Channels are designed to be fast and deliver ordered data. They are used internally for streaming operations such as download progress, child process output and WebSocket messages.
Let’s rewrite our download command example to use channels instead of the event system:
When calling the download command you must create the channel and provide it as an argument:
Evaluating JavaScript
To directly execute any JavaScript code on the webview context you can use the WebviewWindow#eval
function:
If the script to be evaluated is not so simple and must use input from Rust objects we recommend using the serialize-to-javascript crate.
© 2024 Tauri Contributors. CC-BY / MIT