Inertia Rust
A server-side Inertia.js adapter for Rust. Inertia Rust aims to interoperate with any Rust (micro-)framework and template engine, since a compatible provider exists.
Due to its flexibility, it requires a bit more configuration. Hence, please read this document carefully to ensure that your Inertia application works correctly.
Getting started
[]
= { = "0.1", = ["default", "basic-vite-resolver"] }
= "4"
= { = "0.2", = ["basic-directives"] }
To get Inertia working, you'll need to ensure some peer dependencies are installed. Currently, inertia_rust is still under development and is working to support Actix Web. Therefore, ensure you have actix_web on your dependency section and "default" or "actix" feature is enabled at inertia_rust dependency properties.
"basic-vite-resolver" feature enables few basic vite-rust
directives. Currently, we
still do not have default support for template engines, even though you can easily set
it up by yourself.
The basic vite resolver is a template-resolver
function that uses (and thus require you
to install) vite-rust
basic directives (also must be enabled manually at features property)
to inject Vite's tags and Inertia's body and head into your HTML template.
Creating your own template resolver
A template resolver function must be provided during Inertia setup. The basic vite resolver might fit for most usages. If you need something more specific, you will need to create two functions: one to actually resolve the template and a wrapper function, so that the resolver can be stored inside Inertia structure.
use ;
// the actual resolver
async
// a function that wraps the resolver
You might have noted that the third parameter is a reference to SomeUsefulStruct
. This must be
some useful struct used by your resolver. For instance, our basic vite resolver requires a
static reference to a vite_rust::Vite
struct, because it's what provides the HTML tags of the modules,
HMR and other important stuff that must be injected into the HTML.
This struct will also be stored by static reference inside Inertia struct, and Inertia is the one who will call the resolver method when rendering your HTTP response.
If you don't need any extern struct, you can simply pass a &'static ()
on Inertia's template_resolver_data
field. Note that, Inertia requires template_resolver's third parameter to be of type T either.
Inertia setup
For this guide, I'll consider you're using vite-rust
and actix-web
, with the above Cargo.toml dependencies.
Inside your main.rs
, you'll have to:
- Declare Vite as a static constant;
- Initialize Vite;
- Initialize Inertia with a static reference to your Vite instance.
use Data;
use ;
use basic_vite_resolver;
use ;
use OnceLock;
use ;
static VITE: = new;
async
Server-side rendering
If you have Node.js available in the machine your Rust application is running at, you can enable server-side rendering. For this, you'll need to do some few changes in your code:
use Data;
use ;
use basic_vite_resolver;
use ;
use OnceLock;
use ;
static VITE: = new;
async
Page rendering and Responses
There are a few couple ways of rendering an Inertia page. Every provider will aim to give you as many facilities as possible.
The following application renders a component "Index" without any props at "/" endpoint.
use ;
use ;
async
async
The very same thing could be done in the following way:
use ;
use InertiaService;
async
However, it is not possible to render pages with props using inertia_route
method. It must
be done with an ordinary handler function and with render_with_props
helper:
use ;
use ;
use HashMap;
async
// ...
An InertiaProp
is an enum that can hold a serde_json::Value
or a callback that returns one of it.
A hash map of InertiaProp elements is an InertiaProps
set, and it's resolved during rendering (when
the needed props are evaluated).
Inertia Middleware and Shared Props
The Inertia Middleware comes from your opted provider. It has few responsibilities:
- allow you to share props, via
with_shared_props
method; - ensure that redirects for PUT, PATCH and DELETE requests always use a 303 status code;
- merge shared props with errors flash messages.
The middleware's with_shared_props
method requires a callback, wrapped in an Arc
, that
receives a reference to the current request. You can use it to extract any information you might want
to share.
use ;
use InertiaMiddleware;
use ;
async
It will also flash errors into the shared props. These props will be injected back into the request and will be further merged again with the page props during rendering, thus making all of them available to your client-side page component.
As inertia-rust is not made for one single framework and any of them actually have built-in sessions
management, you need to built by yourself a second middleware that injects in the request
context/extensions an InertiaTemporarySession
object:
Inertia Middleware tries to extract this from the request context and merge it with the shared props. This is how validation errors get available to your page components.
Check a sample middleware that extracts errors from the session and add to extensions:
use ;
use ;
use ;
use ;
async
Yet you need to enable your framework session middleware and manager (or your own). As errors
are retrieved by remove
method, they are only available for one request lifetime. Errors and
flash messages shouldn't persist across multiple requests.
[!WARNING] This is in the very first stages of development. A list of functionalities to be implemented and what have been so far is available in the REQUIREMENTS file.