Multi-page Applications done right in Laravel and Vue. Part I

source: https://welcm.uk/blog/best-admin-templates-to-get-you-started-with-laravel-and-vuejs

Update: After another year and half of this writing I managed to write an updated version of this article that uses Vite instead of Laravel Mix, you can find it here.

This story could be the final chapter of the iterations I started as a php backend developer in entering the world of frontend development, which I believe to be the best approach in developing multi-page web applications, using Vue and other JavaScript components and libraries, in a backend project powered by Laravel — or possibly by any other framework or server programming language — . If you’re curious about my previous iterations you could read about it in this story.

The key of handling frontend development is to optimize the required assets and resources i.e. stylesheets — in whatever language they are in; css, scss, sass or, less — , JavaScript functionality that provides the interactivity of your application’s UI — whether through external libraries or manually developed implementations — and, finally other media files e.g. audio, video, images and, fonts.

The web is full of libraries that bundle all or some of the mentioned components to accelerate the development of your projects e.g. Bootstrap, Materialize and, Bulma as full interactive UI set, Flatpickr and, daternagepicker for date and / or time picking UI and functionality, fullcalendar.io for including interactive calendars in your app, jQuery that provides simplified approach to interact with your DOM beside other goodies and, lodash or underscore to make your life easier at dealing with complex arrays or objects, that’s just to name a very few of the plethora of libraries and kits available to use and reuse.

The issue that arise from that lot of usable functionality is in how to best include what’s required in each of our project’s pages, so that we don’t load what we won’t use in a way that poses an unnecessary overhead, which would increase load times and decrease overall performance of the UI.

And that’s where the concepts of asset bundling and, code splitting have come from, thus the creation of Webpack then, recently Vite, which their sole purpose is to build the required libraries and assets in the most effective and efficient way — they also do so for Single Page Applications as well.

Up to version 8.x of the Laravel framework, we got an asset bundler called Laravel Mix, which internally uses Webpack to compile and build the assets your application requires to function, in the latest versions of Laravel, Mix has been replaced with Vite — however you can migrate back to Mix, also older Laravel versions can migrate to Vite so, you can use whichever is simpler or serves you better.

Because I’m a little late to Vite’s welcoming party into the new Laravel installations, I’ll explain how I finally managed the frontend of my Laravel powered projects using Laravel Mix, I guess pretty similar setup would be the case for Vite — I’ll leave this for you to discover though.

The Project Layout

The setup of any Laravel + Vue MPA project is consisted of the following fundamental pillars — will explain each of them in further detail:

• webpack.mix.js file located in the root directory of any Laravel application which is initiated with Mix or migrated to it.
• The infamous packages.json file that includes a list of all the required JavaScript libraries, tools, frameworks, etc.. located in the root directory of the project as well.
• General purpose Vue components, personally I prefer to have them in resources/components directory — starting from the root directory of the project not public —, it’s up to you where to store them anyway.
• Specific purpose blade components, I put them in resources/views/components/{component_type} replacing {component_type} with something that represents the component e.g. modals, tables or, graphs, etc.. then, inside of each type’s directory I may have one or more component of that type.
• The project conventional blade views in other directories within resources/views or, within it directly which will be using the blade components mentioned in the previous point — master layouts yielding content sections from other views can still be used in this approach.
• JavaScript and stylesheet files that will require needed components for each page — blade view — and, will also include the business logic that runs them so, for every page there would be a JavaScript file that handles it.

Into the Details

In this part we’ll cover the first couple of pillars mentioned above, other points will be explained in Part II and Part III of this story.

I. The Mix Configuration file

The webpack.mix.js file is what Mix uses to configure Webpack, in it you can define where your assets are and, where — and what — you’d like to compile them into, take a look at the following example file:

The first line of the file simply requires Laravel Mix for us then, we use it to define our build preferences, the mix.options block tells Mix not to include comments written in any of the source files we’re compiling to reduce the size of the output files thus, reducing load times.

Then we’re requiring glob and path to use them in telling Mix where our source files are and, where to have them compiled into, as written in the last glob.sync blocks and, as you can see there is one block for stylesheets and another for JavaScript.

Basically each glob block scans for the files located in the resources directory and tells Mix to compile them into the public directory

Stepping back a little the mix.setPublicPath tells Mix the directory where the compiled assets should be built into, that’s the directory where your web app’s frontend should be able to access and, the path.normalize used within it is necessary to avoid file location misinterpretations.

Then the mix.isProduction condition is used to check whether we’re building the assets to be used in production environment or development, and it ensures that Mix adds version tags to the compiled files on production as a cache busting mechanism.

And finally the mix.extract line tells Mix to exclude required Vue framework source and, compile it into a separate file out of the bundled JavaScript files — will explain more on that later.

II. Required Tools in packages.json

Just like composer requiring necessary backend tools for our project, we have to use npm to require the frontend tools we need to build our assets — including Mix itself — so, let’s look at the following package.json file which is already included in our Laravel project’s root directory:

You might find this file a bit different than the default one but, generally if you modify your packages.json to the example above or, the one mentioned in Laravel Mix installation or migration guides you’ll be good to go then, all you have to do is to run npm install in your terminal provided that you have npm installed on your system.

After the installation is done, you’ll see the most popular giant node_modules directory created in your project’s root, at that point you can either run npm run production to build the assets for production — which will automatically compress the compiled files and version tag them — or, npm run development which will build uncompressed version of your assets for development and debugging.

That concludes this part of the story, you can continue reading the second part of the story here.