You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/guide/pages.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -85,14 +85,14 @@ export default function Welcome({ user }) {
85
85
86
86
:::
87
87
88
-
Given the page above, you can render the page by returning an Inertia response from a controller or route. In this example, let's assume this page is stored at `app/frontend/pages/User/Show.(jsx|vue|svelte)` within a Rails application.
88
+
Given the page above, you can render the page by returning an Inertia response from a controller or route. In this example, let's assume this page is stored at `app/frontend/pages/user/show.(jsx|vue|svelte)` within a Rails application.
Copy file name to clipboardExpand all lines: docs/guide/responses.md
+51-36Lines changed: 51 additions & 36 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,52 +2,61 @@
2
2
3
3
## Creating responses
4
4
5
-
Creating an Inertia response is simple. To get started, just use the `inertia` renderer in your controller methods, providing both the name of the [JavaScript page component](/guide/pages.md) that you wish to render, as well as any props (data) for the page.
5
+
Creating an Inertia response is simple. By default, Inertia Rails follows convention over configuration: you simply pass the props (data) you wish to send to the page, and the component name is automatically inferred from the controller and action.
Within Rails applications, the `Event/Show` page would typically correspond to the file located at `app/frontend/pages/Event/Show.(jsx|vue|svelte)`.
16
+
Within Rails applications, the `UsersController#show` action would typically correspond to the file located at `app/frontend/pages/users/show.(jsx|vue|svelte)`.
22
17
23
18
> [!WARNING]
24
19
> To ensure that pages load quickly, only return the minimum data required for the page. Also, be aware that **all data returned from the controllers will be visible client-side**, so be sure to omit sensitive information.
25
20
26
-
### Automatically determine component name
21
+
### Customizing the Component Path
22
+
23
+
While the default convention works for most cases, you may need to render a specific component or change how component paths are resolved globally.
27
24
28
-
You can pass props without specifying a component name:
25
+
#### Explicit Component Names
26
+
27
+
If you wish to render a component that does not match the current controller action, you can explicitly provide the name of the [JavaScript page component](/guide/pages) followed by the props hash.
29
28
30
29
```ruby
31
-
classUsersController < ApplicationController
32
-
defshow
33
-
render inertia: { user:@user } # Will render '../users/show.jsx|vue|svelte'
30
+
classEventsController < ApplicationController
31
+
defmy_event
32
+
event =Event.find(params[:id])
33
+
34
+
render inertia:'events/show', props: {
35
+
event: event.as_json(
36
+
only: [:id, :title, :start_date, :description]
37
+
)
38
+
}
34
39
end
35
40
end
36
41
```
37
42
38
-
If the default component path doesn't match your convention, you can define a custom resolution method via the `component_path_resolver` config value. The value should be callable and will receive the path and action parameters, returning a string component path.
43
+
#### Custom Path Resolver
44
+
45
+
If the default automatic path resolution does not match your project's conventions, you can define a custom resolution method via the `component_path_resolver` config value.
46
+
47
+
The value should be callable and will receive the `path` and `action` parameters, returning a string component path.
39
48
40
49
```ruby
41
50
inertia_config(
42
51
component_path_resolver:->(path:, action:) do
43
-
"Storefront/#{path.camelize}/#{action.camelize}"
52
+
"storefront/#{path.camelize}/#{action.camelize}"
44
53
end
45
54
)
46
55
```
47
56
48
57
### Using instance variables as props
49
58
50
-
Inertia enables the automatic passing of instance variables as props. This can be achieved by invoking the `use_inertia_instance_props`function in a controller or in a base controller from which other controllers inherit.
59
+
For convenience, Inertia can automatically pass your controller's instance variables to the page component as props. To enable this behavior, invoke the `use_inertia_instance_props`method within your controller or a base controller.
51
60
52
61
```ruby
53
62
classEventsController < ApplicationController
@@ -56,18 +65,24 @@ class EventsController < ApplicationController
56
65
defindex
57
66
@events=Event.all
58
67
59
-
render inertia:'Events/Index'
68
+
render inertia:'events/index'
60
69
end
61
70
end
62
71
```
63
72
64
-
This action automatically passes the `@events` instance variable as the `events` prop to the `Events/Index` page component.
73
+
In this example, the `@events` instance variable is automatically included in the response as the `events` prop.
65
74
66
-
> [!NOTE]
67
-
> Manually providing any props for a response disables the instance props feature for that specific response.
75
+
Please note that if you manually provide a props hash in your render call, the instance variables feature is disabled for that specific response.
68
76
69
-
> [!NOTE]
70
-
> Instance props are only included if they are defined **after** the `use_inertia_instance_props` call, hence the order of `before_action` callbacks is crucial.
77
+
> [!WARNING]
78
+
> Security and Performance Risk
79
+
>
80
+
> When enabled, this feature serializes all instance variables present in the controller at the time of rendering. This includes:
81
+
> * Variables set by `before_action` filters (e.g., `@current_user`, `@breadcrumbs`) called **after**`use_inertia_instance_props`.
82
+
> * Memoized variables (often used for caching internal state, e.g., `@_cached_result`).
83
+
> * Variables intended only for server-side logic.
84
+
>
85
+
> This creates a high risk of accidentally leaking sensitive data or internal implementation details to the client. It can also negatively impact performance by serializing unnecessary heavy objects. We recommend being explicit with your props whenever possible.
71
86
72
87
## Root template data
73
88
@@ -89,7 +104,7 @@ Sometimes you may even want to provide data to the root template that will not b
Copy file name to clipboardExpand all lines: docs/guide/routing.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,12 +34,12 @@ end
34
34
35
35
Some server-side frameworks allow you to generate URLs from named routes. However, you will not have access to those helpers client-side. Here are a couple ways to still use named routes with Inertia.
36
36
37
-
The first option is to generate URLs server-side and include them as props. Notice in this example how we're passing the `edit_url` and `create_url` to the `Users/Index` component.
37
+
The first option is to generate URLs server-side and include them as props. Notice in this example how we're passing the `edit_url` and `create_url` to the `users/index` component.
0 commit comments