# Inertia

`@larabug/inertia` sits alongside `@larabug/vue` or `@larabug/react` and adds what Inertia knows: which page you were on, which visit failed, and the Laravel context behind it.

## Install the plugin

```js resources/js/app.js
import { createInertiaApp } from '@inertiajs/vue3'
import { createInertiaLaraBugPlugin } from '@larabug/inertia'
import { LaraBugVuePlugin } from '@larabug/vue'
import { createApp, h } from 'vue'

createInertiaApp({
  resolve: name => resolvePageComponent(name),
  setup ({ el, App, props, plugin }) {
    createApp({ render: () => h(App, props) })
      .use(plugin)
      .use(LaraBugVuePlugin, { dsn: import.meta.env.VITE_LARABUG_DSN })
      .use(createInertiaLaraBugPlugin({
        trackPageVisits: true,
        trackErrors: true,
      }))
      .mount(el)
  },
})
```

| Option | Default | What it does |
| --- | --- | --- |
| `trackPageVisits` | see the package | Record each visit as a breadcrumb, so a report says how the reader got there. |
| `trackErrors` | see the package | Report Inertia's own errors. |
| `trackNavigations` | see the package | Record navigation events. |
| `includeRequestData` | `false` | Attach `page.props` to reports. |

## Leave includeRequestData alone

It is off on purpose. Inertia page props routinely carry the authenticated user, CSRF tokens and flashed session data, and attaching them to every error means storing all of that with every error.

When you do want something from them, take the piece you want rather than the lot:

```js
import { setUserFromInertia, attachLaravelContext } from '@larabug/inertia'

setUserFromInertia(page.props.auth.user)
attachLaravelContext(page.props)
```

Turning `includeRequestData` on does run the props through the data filter first, but the filter is a safety net, not a plan.