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

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:

JavaScript

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.

Previous Vue 3 Next Source maps