Skip to main content
When you create your inertia helper, you are ready to handle incoming inertia requests. 
const inertia = createHelper({ request })

​
Rendering pages

The fundamental unit of inertia request is the page object returned from your app routes. On first request, inertia server will respond with a rendered HTML, and on subsequent requests, it will respond with a JSON payload with information on how to update the client-side app. To create a page response, use the render function. 
inertia.render(page);
It takes a page context as the first argument. To create it we invoke a page definition with the required props. Page definitions are created using the definePage function that you set up during the package configuration. It’s thanks to page definitions that we can provide type safety between the client and server code.
Working with pages is covered in detail in the pages section.
import { prop } from 'inertia-server';
import { definePage } from '~/server/inertia';

const homePage = definePage({
  component: 'Home',
  props: {
    title: prop<string>(),
  },
});

const requestPage = homePage({
  title: 'Welcome',
});

const response = await inertia.render(page);

​
Redirects

If we return normal redirect response from our server, it doesn’t take inertia features into account. Make sure to use a dedicated function that creates an appropriate Response object for the current inertia request. 
return inertia.redirect('/users');

​
State

Every server application comes with global data associated with the request. It would be cumbersome to pass errors, user objects or flash messages manually to every page. Server helper has dedicated functions to make this process easier.

​
Shared data

Shared keys are available to all pages in the application. To provide them, you can call the share function somewhere during your request lifecycle. Middleware is the most common place to do this. 
inertia.share({
  user: {
    id: 1,
    name: 'John Doe',
  },
});
Inertia can memoize your shared data on the client, and not reload it on navigation. To do this, the shareOnce function. 
inertia.shareOnce({
  appHeader: 'Loaded!',
});
Both presented calls will result in type error. We make sure that our data is type safe and available to the client, and it is not obvious where, or if, the shared keys will be provided. To fix it, you will have to register those types globally.
~/server/inertia.ts
declare module "@inertiajs/core" {
  export interface InertiaConfig {
    sharedPageProps: {
      auth: { user: { id: number; name: string } };
      appName: string;
    };
  }
}
Now you will get type hints when using the share function. Every page props will have access user and appName keys.
Shared keys will be marked as optional, so in addition to their base type they will get a undefined added to it.
If you want to make sure that a share key is available to a page, you can use the requireShared option when defining the page. Then it won’t be optional in the generated page prop types. Also, a server error will be thrown if the key was not provided. 
const page = definePage({
  requireShared: ['user'],
});

​
Errors

If any errors are caught during the request, you can pass them your page with errors function.
For errors to work correctly, you have to configure sessions when creating your inertia helper
inertia.errors({
  email: 'Invalid email',
});
Some pages may have multiple forms, and if they are posted to the same route, you don’t want to mix errors from different forms. In those cases, users may send an inertia request that will request only the global errors and ones from a specific error bag. By passing a second argument to the errors function, you can assign errors to a specific error bag. They won’t be included in the response unless the request specifically asks for them. 
inertia.errors({
  email: 'Invalid email',
}, 'login');
You can configure error value type globally to provide type safety: 
declare module "@inertiajs/core" {
  export interface InertiaConfig {
    errorValueType: string[];
  }
}
Error bags are merged into your page object as a single errors object. Error bags are nested under their own keys inside of it. So if you call inertia.errors({ email: 'Invalid email' }, 'login'), you can access your page errors.login.email key.

​
Flash messages

Flash messages are a way to share some keys with your client in the next response. They are added with the flash function and are available under the flash key in the page props.
For flashing to work correctly, you have to configure sessions when creating your inertia helper
inertia.flash('success', 'User created successfully');
Flash messages are merged into your page props as a single flash object. Yes, you have guessed it, they have to be typed too :> 
declare module "@inertiajs/core" {
  export interface InertiaConfig {
    flashDataType: {
      toast?: { type: "success" | "error"; message: string };
    };
  }
}