inertia-rails-controllers
Master server-side Inertia patterns in Rails controllers. Learn when to use render inertia with explicit props, how to defer expensive queries, share data across pages, and handle validation errors correctly. Covers prop types, flash messages, and the critical inertia_location rule for external redirects.
inertia-rails-controllers teaches you to pass data as props using render inertia: { key: data }, never relying on instance variables.
AI-generated summary based on this skill's SKILL.md
Install
inertia-rails/skills/inertia-rails-controllers
git clone https://github.com/inertia-rails/skills
cp -r skills/skills/inertia-rails-controllers ~/.claude/skills/inertia-rails-controllersnpx skillfed install inertia-rails/skills/inertia-rails-controllersFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
How do you pass data as props from Rails controllers to Inertia pages?
inertia-rails-controllers uses the `render inertia:` syntax in your controller action. Pass props as keyword arguments: `render inertia: 'ComponentName', prop_name: value`. Each prop is serialized and sent to your Vue/React component. Use instance variables or method calls as prop values—Rails will serialize them automatically. For large datasets, consider using the `defer:` prop type to load data only when needed.
What are the prop types in inertia-rails-controllers and when should you use each?
inertia-rails-controllers supports four prop types: `defer` delays loading until the component requests it (ideal for expensive queries); `optional` omits the prop if nil; `once` caches the prop value across navigation (useful for rarely-changing data); and `merge` combines prop values across page visits. Use `defer:` for slow database calls, `optional:` for conditional data, `once:` for auth state, and `merge:` for accumulated filters or search state.
How does inertia-rails-controllers handle validation errors and flash messages?
inertia-rails-controllers automatically captures validation errors via `errors.to_hash` and flash messages, making them available as props on the client. After a failed form submission, render the same component with `render inertia: 'FormComponent', errors: @model.errors.to_hash`. Flash messages persist across redirects and appear as props on the next page load. Use `redirect_with_errors` helper to combine redirect and error passing in one step.
What is inertia_location and how does it differ from redirect_to for external redirects?
inertia-rails-controllers provides `inertia_location` for external redirects (Stripe, OAuth, external URLs) that bypass the normal Inertia response cycle. Use `inertia_location 'https://external-url.com'` instead of `redirect_to` when leaving your Inertia app entirely. `redirect_to` works for internal routes; `inertia_location` ensures the browser navigates directly without attempting an Inertia page load, preventing client-side errors.
How do you set up shared data and authorization props across all inertia-rails-controllers responses?
inertia-rails-controllers supports middleware-level shared data via `Inertia.share` in your layout or initializer. Define shared props once—typically auth user, CSRF token, and permissions—and they appear on every page automatically. Use `Inertia.share(current_user: current_user, can_admin: current_user&.admin?)` in a before_action or middleware. This avoids repeating common props in every controller action.
What is the render inertia syntax and how do you structure a basic inertia-rails-controllers response?
inertia-rails-controllers uses `render inertia: 'ComponentName', prop1: value1, prop2: value2` to render a page. The component name maps to your frontend file (e.g., 'Posts/Index' → Posts/Index.vue). Props are passed as keyword arguments and automatically serialized to JSON. Example: `render inertia: 'Users/Show', user: @user, posts: @user.posts.limit(10)`. Each prop becomes a reactive prop in your component.
SKILL.md
rendered from the published skill — quoted content, verbatim
Inertia Rails Controllers
Server-side patterns for Rails controllers serving Inertia responses.
Before adding a prop, ask:
- Needed on every page? → inertia_share in a base controller (InertiaController), not a per-action prop
- Expensive to compute? → InertiaRails.defer — page loads fast, data streams in after
- Only needed on partial reload? → InertiaRails.optional — skipped on initial load
- Reference data that rarely changes? → InertiaRails.once — cached across navigations
NEVER:
- Use redirect_to for external URLs (Stripe, OAuth, SSO) — it returns 302 but the Inertia client tries to parse the response as JSON,
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 4 files
skills/inertia-rails-controllers/SKILL.md
skills/inertia-rails-controllers/references/authorization.md
skills/inertia-rails-controllers/references/configuration.md
skills/inertia-rails-controllers/references/prop-types.md