thoughts and inspiration on designing, programming, and writing for the web
When you need to set up a service in a Laravel app, service providers are generally the place to be. But, there's one problem with service providers: they're global. This usually doesn't matter, but in multi-section apps this can be problematic.
I last blogged about handling routes in a Laravel and Inertia app. The premise was that we don't have access to Laravel's URL generator functions with Inertia, so we need to pass our application's routes down differently.
The same problem exists with authorization: we don't have access to the can helper and other Gate methods. Here's a short post about dealing with authorization on the frontend.
Today I tagged v1 of a new package: Laravel Mix Preload. It automatically generates preload and prefetch links based on the contents of your mix-manifest.json file.
Both Inertia.js and Livewire have been in the spotlight the past few months. The two libraries often get put next to each other because of their (coincidentally) simultaneous releases.
I've seen many people compare the two, or ask if they can be used together. This post showcases their similarities and differences, and should help you understand which problems they each solve best.
If you're building an app with Laravel and Inertia, you don't have access to Laravel's helper methods because you're writing views in JavaScript. This means you lose the ability to generate URLs on the fly with Laravel's route and action helpers.
This short post outlines two ways to deal with routes in a Laravel and Inertia app.
Code splitting is bundler feature—if you're using Laravel Mix, you're bundling your assets with Webpack—that allows you to split application scripts in multiple files. These can then conditionally be loaded at a later stage.
Laravel 5.6 adds the ability to register alias directives for Blade components. Let's review some background information and examples.
Christoph Rumpel published his revamped site last week, built with Laravel and Tailwind CSS. He based the site's architecture on my personal site (yeah, the one you're reading now). I open sourced it about a year ago, and I'm glad to see that it provided value to someone!
Read the full article on Christoph Rumpel's new blog.
Laravel quick tip! The @extends Blade directive accepts a second (undocumented) parameter to pass data to the parent layout.
Every now and then I come accross a Class log does not exist exception in Laravel. This particular exception is thrown when something goes wrong really early in the application, before the exception handler is instantiated.
Whenever I come across this issue I'm stumped. Mostly it's related to an invalid configuration issue or an early service provider that throws an exception. I always forget how to debug this, so it's time to document my solution for tracking down the underlying error.
I'm building a multi-tenant Laravel application. One of the requirements of the project is that every client can have their own theme based on their corporate guidelines. By default a few css adjustments will suffice, but some clients request a completely different template.
Conditionally loading a different stylesheet per client is pretty trivial, but in order to use a completely different view per theme you quickly end up typing the same thing over and over across various parts of your application.
Since writing this post, TypeScript has become officially supported in Laravel Mix (version 0.12 and up). There's still some informative stuff in here if you're new to TypeScript, but use the official method if you're on a newer version of Mix!
In a recent Spatie project we decided to give TypeScript a shot for the business critical part of a new application. TypeScript provides static analysis to reduce the chance of introducing bugs, to have self-documenting code, and to improve our tooling (autocompletion!)
When admins create or update a news item—or any other entity—in our homegrown CMS, a url slug is generated based on it's title. The downside here is that when the title changes, the old url would break. If we wouldn't regenerate the url on updates, edited titles would still have an old slug in the url, which isn't an ideal situation either.
Our solution: add a unique identifier to the url that will never change, while keeping the slug intact. This creates links that are both readable and unbreakable.
When building a website for a client that wants to be able to manage content, Laravel's language files aren't ideal since you can't edit them without diving into a bundle of text files. We recently decided to drop all the lang files in our custom CMS in favor of persisting translations in the database, which allows us to build a custom interface for managing them.
This post is a quick overview on overwriting Laravel's default translation loader, which means you can keep using the lang method while fetching the translations from a database. Writing a custom loader is easier than it sounds. First we'll set up our translation models, then we'll write our loader, and finally register it in our application.