Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
This is one of those cross-category questions. I am migrating a Laravel app (not a SPA) from Vue 2 to Vue 3, and am taking the opportunity to revisit to component structure that's been used up to now. In brief, each Laravel page that uses vue has its own "app.js", or parent component file -- all uniquely named, of course. Some pages do share some components; others use components that are not shared. Each page (there are 15 or 20) has a different function. Some contain one or more forms that use ajax, some mainly display or sort data stored in Pinia, etc.
I have two questions:
is having a separate root component for each entry point a reasonable approach to take? I've seen some people describe using a single app.js file and then loading other components dynamically based on location, but that sounds like it would be difficult to maintain, even if it might save repeating code in spots.
regarding root components, what kinds of questions should I be thinking about in deciding what responsibilities to give to the parent component? Should it do nothing except create and mount the app, and import all of the child components, and leave all of the logic and data handling to the latter? I've always struggled with this question.
I haven't been able to find much discussion about to structure Laravel-Vue non-SPA apps, and how to integrate single-file vue components into a site like this. So any thoughts or comments would be greatly appreciated.
better to do it in SPA way. There are several benifits when you have a front-end and back-end within a same domain, one is you don't have to deal with cors problems , which is very painful.
laravel back-end could be api server , provide data to vue front-end
@MaverickChan I'm actually looking into using inertia as a possible solution -- maybe use it only for pages that rely heavily on vue, and stick with more traditional blade-type pages where there's no js. I'm also noticing that most stuff I see about SPAs and inertia ignore the extra steps you need to take to make page and content changes accessible. That's some extra work, but it's part of the job. Thank you. Both replies have given me some good suggestions and stuff to think about. Very helpful!
@pweil You don’t need to move to a full-on SPA. But you can improve your set-up a little.
Instead of having different “apps” per page, yes, you can have a single app.js file but then lazily-load components only as and when they’re actually required on a page (rather than checking the page location).
So, given an app.js file like this:
import { createApp, defineAsyncComponent } from 'vue';
const app = createApp({});
app.component('foo-component', defineAsyncComponent(() => import('./components/Foo.vue')));
app.component('bar-component', defineAsyncComponent(() => import('./components/Bar.vue')));
app.component('baz-component', defineAsyncComponent(() => import('./components/Baz.vue')));
app.mount('#app');
Now if you call <foo-component></foo-component> in a Blade template, it’ll be loaded asynchronously.
Vue async component docs: https://vuejs.org/guide/components/async.html
@martinbean thanks -- I'd much rather not switch to SPA at this point. I've done lazy loading of components before but it didn't occur to me that I could use this in the way you describe. But yes, why not?
Question: Can lazy loading of components be done with vite the same way as if you have webpack? is it "bundler-agnostic"?
One other question comes to mind: what about loading non-component libraries, etc., such as Pinia? Or perhaps I should relegate loading Pinia to one of the SFCs?
Question: Can lazy loading of components be done with vite the same way as if you have webpack? is it "bundler-agnostic"?
@pweil Don’t know. I’m still using Mix in a lot of projects. I’m sure the Vite docs will have a section on lazy loading components, though.
One other question comes to mind: what about loading non-component libraries, etc., such as Pinia? Or perhaps I should relegate loading Pinia to one of the SFCs?
I’m not sure why you’d be using a state library like Pinia for disparate components sprinkled across various server-rendered pages?
@martinbean I'm using Pinia for a particular section of the site where users are creating and editing records stored in a database. It involves multiple components, and I turned to a state library only after the sharing/passing of data among components became unwieldy. Thanks for your helpful suggestions!
Please or to participate in this conversation.