wip

Author: joetannenbaum

quickstart.mdx

@@ -31,7 +31,7 @@ Inertia::version($version);
 Inertia::version(fn () => $version); // Lazily...
 ```
 
-## Cache busting
+## Cache Busting
 
 Asset refreshing in Inertia works on the assumption that a hard page visit will trigger your assets to reload. However, Inertia doesn't actually do anything to force this. Typically this is done with some form of cache busting. For example, appending a version query parameter to the end of your asset URLs.
 

v1/advanced/asset-versioning.mdx

@@ -4,7 +4,7 @@ title: CSRF Protection
 
 <Warning>This is documentation for Inertia.js v1, which is no longer actively maintained. Please refer to the [v2 docs](/v2) for the latest information.</Warning>
 
-## Making requests
+## Making Requests
 
 Laravel automatically includes the proper CSRF token when making requests via Inertia or Axios. However, if you're using Laravel, be sure to omit the `csrf-token` meta tag from your project, as this will prevent the CSRF token from refreshing properly.
 
@@ -70,7 +70,7 @@ Axios automatically checks for the existence of an `XSRF-TOKEN` cookie. If it's
 
 The easiest way to implement this is using server-side middleware. Simply include the `XSRF-TOKEN`cookie on each response, and then verify the token using the `X-XSRF-TOKEN` header sent in the requests from axios.
 
-## Handling mismatches
+## Handling Mismatches
 
 When a CSRF token mismatch occurs, your server-side framework will likely throw an exception that results in an error response. For example, when using Laravel, a `TokenMismatchException` is thrown which results in a `419` error page. Since that isn't a valid Inertia response, the error is shown in a modal.
 

v1/advanced/csrf-protection.mdx

@@ -6,7 +6,7 @@ title: Events
 
 Inertia provides an event system that allows you to "hook into" the various lifecycle events of the library.
 
-## Registering listeners
+## Registering Listeners
 
 To register an event listener, use the `router.on()` method.
 
@@ -84,7 +84,7 @@ document.addEventListener('inertia:start', (event) => {
 
 </CodeGroup>
 
-## Removing listeners
+## Removing Listeners
 
 When you register an event listener, Inertia automatically returns a callback that can be invoked to remove the event listener.
 
@@ -248,7 +248,7 @@ document.removeEventListener('inertia:start', startEventListener)
 
 </CodeGroup>
 
-## Cancelling events
+## Cancelling Events
 
 Some events, such as `before`, `invalid`, and `error`, support cancellation, allowing you to prevent Inertia's default behavior. Just like native events, the event will be cancelled if only one event listener calls `event.preventDefault()`.
 
@@ -846,6 +846,6 @@ router.on('navigate', (event) => {
 
 The `navigate` event is not cancelable.
 
-## Event callbacks
+## Event Callbacks
 
 In addition to the global events described throughout this page, Inertia also provides a number of [event callbacks](/manual-visits#event-callbacks) that fire when manually making Inertia visits.

v1/advanced/events.mdx

@@ -10,7 +10,7 @@ As an example, consider a "user index" page that includes a list of users, as we
 
 Partial reloads only work for visits made to the same page component.
 
-## Only certain props
+## Only Certain Props
 
 To perform a partial reload, use the `only` visit option to specify which data the server should return. This option should be an array of keys which correspond to the keys of the props.
 
@@ -50,7 +50,7 @@ router.visit(url, {
 
 </CodeGroup>
 
-## Except certain props
+## Except Certain Props
 
 In addition to the `only` visit option you can also use the `except` option to specify which data the server should exclude. This option should also be an array of keys which correspond to the keys of the props.
 
@@ -90,7 +90,7 @@ router.visit(url, {
 
 </CodeGroup>
 
-## Router shorthand
+## Router Shorthand
 
 Since partial reloads can only be made to the same page component the user is already on, it almost always makes sense to just use the `router.reload()` method, which automatically uses the current URL.
 
@@ -122,7 +122,7 @@ router.reload({ only: ['users'] })
 
 </CodeGroup>
 
-## Using links
+## Using Links
 
 It's also possible to perform partial reloads with Inertia links using the `only` property.
 
@@ -156,7 +156,7 @@ import { inertia, Link } from '@inertiajs/svelte'
 
 </CodeGroup>
 
-## Lazy data evaluation
+## Lazy Data Evaluation
 
 For partial reloads to be most effective, be sure to also use lazy data evaluation when returning props from your server-side routes or controllers. This can be accomplished by wrapping all optional page data in a closure.
 

v1/advanced/partial-reloads.mdx

@@ -102,7 +102,7 @@ router.on('finish', () => NProgress.done())
 
 That's it! Now, as you navigate from one page to another, the progress bar will be added and removed from the page.
 
-### Handling cancelled visits
+### Handling Cancelled Visits
 
 While this custom progress implementation works great for page visits that finish properly, it would be nice to handle cancelled visits as well. First, for interrupted visits (those that get cancelled as a result of a new visit), the progress bar should simply be reset back to the start position. Second, for manually cancelled visits, the progress bar should be immediately removed from the page.
 
@@ -121,7 +121,7 @@ NProgress.remove()
 })
 ```
 
-### File upload progress
+### File Upload Progress
 
 Let's take this a step further. When files are being uploaded, it would be great to update the loading indicator to reflect the upload progress. This can be done using the `progress` event.
 
@@ -135,7 +135,7 @@ NProgress.set((event.detail.progress.percentage / 100) * 0.9)
 
 Now, instead of the progress bar "trickling" while the files are being uploaded, it will actually update it's position based on the progress of the request. We limit the progress here to 90%, since we still need to wait for a response from the server.
 
-### Loading indicator delay
+### Loading Indicator Delay
 
 The last thing we're going to implement is a loading indicator delay. It's often preferable to delay showing the loading indicator until a request has taken longer than 250-500 milliseconds. This prevents the loading indicator from appearing constantly on quick page visits, which can be visually distracting.
 
@@ -187,7 +187,7 @@ return
 
 That's it, you now have a beautiful custom page loading indicator!
 
-### Complete example
+### Complete Example
 
 For convenience, here is the full source code of the final version of our custom loading indicator.
 

v1/advanced/progress-indicators.mdx

@@ -10,7 +10,7 @@ For example, if a user partially completes a form, then navigates away, and then
 
 To mitigate this issue, you can tell Inertia which local component state to save in the browser history.
 
-## Saving local state
+## Saving Local State
 
 To save local component state to the history state, use the `remember` feature to tell Inertia which data it should remember.
 
@@ -79,7 +79,7 @@ let form = remember({
 
 Now, whenever your local `form` state changes, Inertia will automatically save this data to the history state and will also restore it on history navigation.
 
-## Multiple components
+## Multiple Components
 
 If your page contains multiple components that use the remember functionality provided by Inertia, you need to provide a unique key for each component so that Inertia knows which data to restore to each component.
 
@@ -190,7 +190,7 @@ let form = remember({
 
 </CodeGroup>
 
-## Form helper
+## Form Helper
 
 If you're using the [Inertia form helper](/forms#form-helper), you can pass a unique form key as the first argument when instantiating your form. This will cause the form data and errors to automatically be remembered.
 
@@ -226,7 +226,7 @@ const form = useForm(`EditUser:${user.id}\
 
 </CodeGroup>
 
-## Manually saving state
+## Manually Saving State
 
 The `remember` property in Vue 2, and the `useRemember` hook in Vue 3, React, and Svelte all watch for data changes and automatically save those changes to the history state. Then, Inertia will restore the data on page load.
 

v1/advanced/remembering-state.mdx

@@ -4,13 +4,13 @@ title: Scroll Management
 
 <Warning>This is documentation for Inertia.js v1, which is no longer actively maintained. Please refer to the [v2 docs](/v2) for the latest information.</Warning>
 
-## Scroll resetting
+## Scroll Resetting
 
 When navigating between pages, Inertia mimics default browser behavior by automatically resetting the scroll position of the document body (as well as any [scroll regions](#scroll-regions) you've defined) back to the top.
 
 In addition, Inertia keeps track of the scroll position of each page and automatically restores that scroll position as you navigate forward and back in history.
 
-## Scroll preservation
+## Scroll Preservation
 
 Sometimes it's desirable to prevent the default scroll resetting when making visits. You can disable this behavior by setting the `preserveScroll` option to `false`.
 
@@ -142,7 +142,7 @@ import { inertia, Link } from '@inertiajs/svelte'
 
 </CodeGroup>
 
-## Scroll regions
+## Scroll Regions
 
 If your app doesn't use document body scrolling, but instead has scrollable elements (using the `overflow` CSS property), scroll resetting will not work.
 

v1/advanced/scroll-management.mdx

@@ -12,7 +12,7 @@ Server-side rendering pre-renders your JavaScript pages on the server, allowing
 
 Server-side rendering uses Node.js to render your pages in a background process; therefore, Node must be available on your server for server-side rendering to function properly.
 
-## Laravel starter kits
+## Laravel Starter Kits
 
 If you are using [Laravel Breeze or Jetstream](https://laravel.com/docs/starter-kits), you may install the starter kit's scaffolding with Inertia SSR support pre-configured using the `--ssr` flag.
 
@@ -21,7 +21,7 @@ php artisan breeze:install react --ssr
 php artisan breeze:install vue --ssr
 ```
 
-## Install dependencies
+## Install Dependencies
 
 If you are not using a Laravel starter kit and would like to manually configure SSR, we'll first install the additional dependencies required for server-side rendering. This is only necessary for the Vue adapters, so you can skip this step if you're using React or Svelte.
 
@@ -51,7 +51,7 @@ Then, make sure you have the latest version of the Inertia Laravel adapter insta
 composer require inertiajs/inertia-laravel
 ```
 
-## Add server entry-point
+## Add Server Entry-Point
 
 Next, we'll create a `resources/js/ssr.js` file within our Laravel project that will serve as our SSR entry point.
 
@@ -164,7 +164,7 @@ refresh: true,
 })
 ```
 
-## Update npm script
+## Update Npm Script
 
 Next, let's update the `build` script in our `package.json` file to also build our new `ssr.js` file.
 
@@ -182,7 +182,7 @@ Now you can build both your client-side and server-side bundles.
 npm run build
 ```
 
-## Running the SSR server
+## Running the SSR Server
 
 Now that you have built both your client-side and server-side bundles, you should be able run the Node-based Inertia SSR server using the following command.
 
@@ -192,7 +192,7 @@ php artisan inertia:start-ssr
 
 With the server running, you should be able to access your app within the browser with server-side rendering enabled. In fact, you should be able to disable JavaScript entirely and still navigate around your application.
 
-## Client side hydration
+## Client Side Hydration
 
 Since your website is now being server-side rendered, you can instruct <VueSpecific>Vue</VueSpecific><ReactSpecific>React</ReactSpecific><SvelteSpecific>Svelte</SvelteSpecific> to "hydrate" the static markup and make it interactive instead of re-rendering all the HTML that we just generated.
 

v1/advanced/server-side-rendering.mdx

@@ -6,15 +6,15 @@ title: Testing
 
 There are many different ways to test an Inertia application. This page provides a quick overview of the tools available.
 
-## End-to-end tests
+## End-to-end Tests
 
 One popular approach to testing your JavaScript page components is to use an end-to-end testing tool like [Cypress](https://www.cypress.io/) or [Laravel Dusk](https://laravel.com/docs/dusk). These are browser automation tools that allow you to run real simulations of your app in the browser. These tests are known to be slower; however, since they test your application at the same layer as your end users, they can provide a lot of confidence that your app is working correctly. And, since these tests are run in the browser, your JavaScript code is actually executed and tested as well.
 
-## Client-side unit tests
+## Client-side Unit Tests
 
 Another approach to testing your page components is using a client-side unit testing framework, such as [Jest](https://jestjs.io/) or [Mocha](https://mochajs.org/). This approach allows you to test your JavaScript page components in isolation using Node.js.
 
-## Endpoint tests
+## Endpoint Tests
 
 In addition to testing your JavaScript page components, you will likely want to also test the Inertia responses that are returned by your server-side framework. A popular approach to doing this is using endpoint tests, where you make requests to your application and examine the responses. Laravel [provides tooling](https://laravel.com/docs/http-tests) for executing these types of tests.