Add more docs

Author: skryukov

docs/guide/responses.md

@@ -23,77 +23,51 @@ Within Rails applications, the `Event/Show` page would typically correspond to t
 > [!WARNING]
 > 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.
 
-### Using instance variables as props
+### Automatically determine component name
 
-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.
+You can pass props without specifying a component name:
 
 ```ruby
-class EventsController < ApplicationController
-  use_inertia_instance_props
-
-  def index
-    @events = Event.all
-
-    render inertia: 'Events/Index'
+class UsersController < ApplicationController
+  def show
+    render inertia: { user: @user } # Will render '../users/show.jsx|vue|svelte'
   end
 end
 ```
 
-This action automatically passes the `@events` instance variable as the `events` prop to the `Events/Index` page component.
-
-> [!NOTE]
-> Manually providing any props for a response disables the instance props feature for that specific response.
-
-> [!NOTE]
-> 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.
-
-### Automatically determine component name
-
-Rails conventions can be used to automatically render the correct page component by invoking `render inertia: true`:
+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.
 
 ```ruby
-class EventsController < ApplicationController
-  use_inertia_instance_props
-
-  def index
-    @events = Event.all
-
-    render inertia: true
+inertia_config(
+  component_path_resolver: ->(path:, action:) do
+    "Storefront/#{path.camelize}/#{action.camelize}"
   end
-end
+)
 ```
 
-This renders the `app/frontend/pages/events/index.(jsx|vue|svelte)` page component and passes the `@events` instance variable as the `events` prop.
-
-Setting the `default_render` configuration value to `true` establishes this as the default behavior:
+### Using instance variables as props
 
-```ruby
-InertiaRails.configure do |config|
-  config.default_render = true
-end
-```
+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.
 
 ```ruby
 class EventsController < ApplicationController
   use_inertia_instance_props
 
   def index
     @events = Event.all
+
+    render inertia: 'Events/Index'
   end
 end
 ```
 
-With this configuration, the `app/frontend/pages/events/index.(jsx|vue|svelte)` page component is rendered automatically, passing the `@events` instance variable as the `events` prop.
+This action automatically passes the `@events` instance variable as the `events` prop to the `Events/Index` page component.
 
-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.
+> [!NOTE]
+> Manually providing any props for a response disables the instance props feature for that specific response.
 
-```ruby
-inertia_config(
-  component_path_resolver: ->(path:, action:) do
-    "Storefront/#{path.camelize}/#{action.camelize}"
-  end
-)
-```
+> [!NOTE]
+> 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.
 
 ## Root template data
 
@@ -236,3 +210,37 @@ You can find the default templates in the gem's source code:
 To enable client-side history navigation, all Inertia server responses are stored in the browser's history state. However, keep in mind that some browsers impose a size limit on how much data can be saved within the history state.
 
 For example, [Firefox](https://developer.mozilla.org/en-US/docs/Web/API/History/pushState) has a size limit of 16 MiB and throws a `NS_ERROR_ILLEGAL_VALUE` error if you exceed this limit. Typically, this is much more data than you'll ever practically need when building applications.
+
+## Detecting Inertia Requests
+
+Controllers can determine if a request was made via Inertia:
+
+```ruby
+def some_action
+  if request.inertia?
+  # This is an Inertia request
+  end
+
+  if request.inertia_partial?
+  # This is a partial Inertia request
+  end
+end
+```
+
+## Inertia responses and `respond_to`
+
+Inertia responses always operate as a `:html` response type. This means that you can use the `respond_to` method to handle JSON requests differently, while still returning Inertia responses:
+
+```ruby
+def some_action
+  respond_to do |format|
+    format.html do
+      render inertia: 'Some/Component', props: { data: 'value' }
+    end
+
+    format.json do
+      render json: { message: 'This is a JSON response' }
+    end
+  end
+end
+```

docs/guide/routing.md

@@ -9,7 +9,25 @@ When using Inertia, all of your application's routes are defined server-side. Th
 If you have a page that doesn't need a corresponding controller method, like an "FAQ" or "about" page, you can route directly to a component via the `inertia` method.
 
 ```ruby
-inertia 'about' => 'AboutComponent'
+# In config/routes.rb
+Rails.application.routes.draw do
+  # Basic usage - maps 'dashboard' URL to 'Dashboard' component
+  inertia 'dashboard' => 'Dashboard'
+
+  # Using a symbol - infers component name from route
+  inertia :settings
+
+  # Within namespaces and scopes
+  namespace :admin do
+    inertia 'dashboard' => 'Admin/Dashboard'
+  end
+
+  # Within resource definitions
+  resources :users do
+    inertia :activity, on: :member
+    inertia :statistics, on: :collection
+  end
+end
 ```
 
 ## Generating URLs

docs/guide/shared-data.md

@@ -26,6 +26,23 @@ class EventsController < ApplicationController
 end
 ```
 
+### Inheritance and Shared Data
+
+Shared data defined in parent controllers is automatically inherited by child controllers. Child controllers can also override or add to the shared data:
+
+```ruby
+# Parent controller
+  class ApplicationController < ActionController::Base
+  inertia_share app_name: 'My App', version: '1.0'
+end
+
+# Child controller
+class UsersController < ApplicationController
+  # Inherits app_name and version, adds/overrides auth
+  inertia_share auth: -> { { user: current_user } }
+end
+```
+
 ### Conditional Sharing
 
 You can control when data is shared using Rails-style controller filters. The `inertia_share` method supports these filter options: