Ferro Inertia
Server-side Inertia.js adapter for the Ferro framework.
Features
- Ferro integration - Seamlessly works with the Ferro framework
- Async-safe - No thread-local storage, safe for async runtimes like Tokio
- Partial reloads - Efficient updates via
X-Inertia-Partial-Dataheader - Shared props - Easily share auth, flash messages, CSRF tokens across all responses
- Version detection - Automatic 409 Conflict responses for asset version mismatches
- Vite integration - Development mode with HMR support
Installation
[]
= "0.2"
Quick Start
1. Implement the InertiaRequest trait
use InertiaRequest;
2. Render Inertia responses
use Inertia;
use json;
async
3. Add shared props via middleware
use ;
async
Configuration
use InertiaConfig;
// Development (default)
let config = new
.vite_dev_server
.entry_point;
// Production
let config = new
.version
.production;
// Custom HTML template
let config = new
.html_template;
Version Conflict Detection
// In middleware, check for version mismatch
if let Some = check_version
Partial Reloads
Partial reloads are handled automatically. When the client sends:
X-Inertia-Partial-Data: user,notifications
X-Inertia-Partial-Component: Dashboard
Only the requested props (user, notifications) will be included in the response.
Usage in Ferro
ferro-inertia is ferro-coupled: the Request and HttpResponse types come from the framework, and Inertia::render accepts a &Request directly. The ferro crate re-exports Inertia, InertiaProps, and SavedInertiaContext.
Basic render
use ;
pub async
Component paths ("Home") are validated at compile time against the frontend component tree.
Form handlers — SavedInertiaContext
req.input().await consumes the request, which means you lose access to the Inertia headers needed by render. Save the context first, then use render_ctx:
use ;
pub async
Shared props
use ;
let shared = new
.auth
.csrf
.flash;
render_with_shared
License
MIT License - see LICENSE for details.
Contributing
Contributions are welcome! Please feel free to submit a Pull Request.