Weave Code
Laravel Inertia Dataproviders Laravel Package
foxbytehq/laravel-inertia-dataproviders
Laravel Inertia Data Providers lets you organize page props into reusable provider classes, keeping Inertia responses clean and predictable. Define and compose structured data from Laravel controllers to your frontend with less boilerplate.
Data providers encapsulate logic for Inertia views, keep your controllers clean and simple.
Frequently asked questions about Laravel Inertia Dataproviders
- How do I install laravel-inertia-dataproviders?
- Install it with Composer via composer require foxbytehq/laravel-inertia-dataproviders, then optionally publish the package config if you need to customise defaults. You then define provider classes and reference them from your Inertia controllers. There are no migrations, queue workers, or external services involved, so setup is mostly just Composer and a config publish.
- Does this package support Laravel 13?
- Yes. Version 4 is the Laravel 13 release line, and its headline change is framework support for Laravel 13. Before adopting it, check the actual illuminate/* and PHP constraints in the package's composer.json rather than inferring them from the changelog. Also confirm that inertiajs/inertia-laravel and your other packages are Laravel 13-ready at the same time.
- Can I use laravel-inertia-dataproviders on Laravel 11 or Laravel 12?
- Likely not with v4, since a major release that tracks a new Laravel major version almost certainly drops support for Laravel 11 and 12 and raises the PHP floor. Teams still on those versions should pin to ^3.3 and treat v4 as a forward-looking upgrade item. Keep in mind that pinning a major version behind usually means that line stops receiving fixes.
- What problem does this package solve compared to putting props in my controller?
- Data providers move prop construction out of controllers into named, testable classes that return the array of props for a page. That pays off when controllers have accumulated long blocks of array shaping, when the same prop set is needed by multiple entry points such as a page load and a modal refresh, or when frontend and backend prop contracts tend to drift. For small apps with simple Inertia usage, the extra indirection usually is not worth it.
- How do I use a data provider in an Inertia controller?
- You define a provider class that builds and returns the props array, then reference that provider when rendering the page from your controller instead of hand-writing the array inline. Providers can be composed so one page pulls structured data from several sources. The controllers stay thin, and the same provider can be reused by other controllers or refresh endpoints.
- Does it work with Inertia v2 partial reloads and deferred props?
- Providers ultimately return plain prop arrays, so Inertia v2's deferred, lazy, and optional prop behaviour is handled at the Inertia response level rather than by the provider itself. The thing to verify in your own app is whether provider resolution forces eager evaluation of every provider on every request, which would undermine deferred props. Test partial reloads explicitly before rolling it out broadly.
- How do I test data providers with Pest or PHPUnit?
- Because providers are plain classes that return arrays, you can unit test them directly with Pest or PHPUnit and assert on the resolved prop structure. Version 4 also adds a comprehensive test suite on the package side, which reduces regression risk when you upgrade. For confidence, add integration tests that hit the Inertia response and assert the rendered props.
- Does the package handle authorization for props?
- No. Data providers are focused on constructing prop arrays, so authorization is left to the caller. Keep using policies, middleware, FormRequests, or explicit checks in your controller or provider before exposing sensitive data. Do not assume the package will filter props based on the current user.
- Is this package production-ready, and how risky is its maintenance?
- It is a small open-source package with a narrow maintainer base, so bus-factor risk is real even though the added test suite is a genuine positive signal. Treat it like any single-maintainer dependency: pin versions, review changelogs before upgrading, and be ready to fork or replace it if maintenance stalls. The low ceremony and lack of runtime infrastructure reduce the operational risk.
- What are the alternatives to laravel-inertia-dataproviders?
- Common alternatives are hand-rolled private controller methods, Laravel view composers, shared data via the HandleInertiaRequests middleware, or API resources mapped into props. Those work fine, but they tend to become inconsistent as prop logic spreads across a codebase. Adopt this package only if you already have an Inertia commitment and enough prop complexity to justify the abstraction.
Weaver
How can I help you explore Laravel packages today?