Forem: Kim Hallberg

How to use Bootstrap with Laravel and Vite

Kim Hallberg — Sun, 25 Dec 2022 02:19:42 +0000

While the Laravel community now mostly uses Tailwind CSS. Bootstrap - one of the most used CSS frameworks currently on the market, is still widely used by a portion of the community.

Since Laravel's switch to Vite, the status quo of Webpack and Mix was broken and a growing number of users struggle to add Bootstrap to their projects. This post was written to go over how to install Bootstrap in a fresh Laravel installation to ease that struggle.

Installing Bootstrap

Bootstrap and its dependencies are installed using npm, or your preferred node package manager. From the root of our Laravel application, run the following command.

npm install bootstrap @popperjs/core

Bootstrap relies on Popper for its dropdowns, popovers, and tooltips.

Another dependency that Bootstrap requires is Sass, which we will install as a development dependency.

npm install sass --save-dev

Restructuring our CSS

Since Laravel doesn't use Sass out of the box, we will rename our css directory and change our app.css extension to scss to follow that convention.

How you rename and change those is up to you, but I will use git to keep track of the changes.

git mv resources/css/ resources/scss/
git mv resources/scss/app.css resources/css/app.scss

After that is done we need to update our vite.config.js file to use the new path in its input array.

// vite.config.js
export default defineConfig({
    plugins: [
        laravel({
            input: ['resources/scss/app.scss', 'resources/js/app.js'],
            refresh: true,
        }),
    ]
});

Importing Bootstrap CSS

Our next course of action, before importing Bootstrap in our Sass file, is to set up an alias for Bootstrap in our vite.config.js file to make it simpler to import.

// vite.config.js
import path from 'path';

export default defineConfig({
    plugins: [/../],
    resolve: {
        alias: {
            '~bootstrap': path.resolve(__dirname, 'node_modules/bootstrap')
        }
    }
});

With our alias configured all we have to do now is import Bootstrap's CSS in our Sass file.

// resources/scss/app.scss
@import "~bootstrap/scss/bootstrap";

This will import all the stylesheets Bootstrap offers, to import individual stylesheets, please refer to the documentation for Sass imports.

Importing Bootstrap JavaScript

The last job we need to do is to import Bootstrap's JavaScript. And that is done in either your bootstrap.js file or app.js. For this example, I've gone with app.js.

// resources/js/app.js
import * as bootstrap from 'bootstrap';

Finishing up

With that done, all that is left is to add our Vite Blade directive and build our assets. For this example, we're updating the default welcome.blade.php with some Bootstrap example code.

<!-- resources/views/welcome.blade.php -->
<head>
    @vite(['resources/scss/app.scss', 'resources/js/app.js'])
</head>

Header example

Bootstrap offers some great examples for you to quickly get started on a project. With that in mind, let's use one of their headers to test whether our Bootstrap installation is working correctly.

<!-- resources/views/welcome.blade.php -->
<body>
    <header class="p-3 mb-3 border-bottom">
        <div class="container">
            <div class="d-flex flex-wrap align-items-center justify-content-center justify-content-lg-start">
                <a href="/" class="d-flex align-items-center mb-2 mb-lg-0 text-dark text-decoration-none">
                    <svg fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" class="bi me-2" width="40" height="32" role="img" aria-label="Storefront">
                        <path stroke-linecap="round" stroke-linejoin="round" d="M13.5 21v-7.5a.75.75 0 01.75-.75h3a.75.75 0 01.75.75V21m-4.5 0H2.36m11.14 0H18m0 0h3.64m-1.39 0V9.349m-16.5 11.65V9.35m0 0a3.001 3.001 0 003.75-.615A2.993 2.993 0 009.75 9.75c.896 0 1.7-.393 2.25-1.016a2.993 2.993 0 002.25 1.016c.896 0 1.7-.393 2.25-1.016a3.001 3.001 0 003.75.614m-16.5 0a3.004 3.004 0 01-.621-4.72L4.318 3.44A1.5 1.5 0 015.378 3h13.243a1.5 1.5 0 011.06.44l1.19 1.189a3 3 0 01-.621 4.72m-13.5 8.65h3.75a.75.75 0 00.75-.75V13.5a.75.75 0 00-.75-.75H6.75a.75.75 0 00-.75.75v3.75c0 .415.336.75.75.75z" />
                    </svg>
                </a>

                <ul class="nav col-12 col-lg-auto me-lg-auto mb-2 justify-content-center mb-md-0">
                    <li><a href="#" class="nav-link px-2 link-secondary">Overview</a></li>
                    <li><a href="#" class="nav-link px-2 link-dark">Inventory</a></li>
                    <li><a href="#" class="nav-link px-2 link-dark">Customers</a></li>
                    <li><a href="#" class="nav-link px-2 link-dark">Products</a></li>
                </ul>

                <form class="col-12 col-lg-auto mb-3 mb-lg-0 me-lg-3" role="search">
                    <input type="search" class="form-control" placeholder="Search..." aria-label="Search">
                </form>

                <div class="dropdown text-end">
                    <a href="#" class="d-block link-dark text-decoration-none dropdown-toggle"
                        data-bs-toggle="dropdown" aria-expanded="false">
                        <img src="https://github.com/mdo.png" alt="mdo" class="rounded-circle" width="32"
                            height="32">
                    </a>
                    <ul class="dropdown-menu text-small" style="">
                        <li><a class="dropdown-item" href="#">New project...</a></li>
                        <li><a class="dropdown-item" href="#">Settings</a></li>
                        <li><a class="dropdown-item" href="#">Profile</a></li>
                        <li>
                            <hr class="dropdown-divider">
                        </li>
                        <li><a class="dropdown-item" href="#">Sign out</a></li>
                    </ul>
                </div>
            </div>
        </div>
    </header>
</body>

If we now build our assets, we should see our new Bootstrap headers working when we enter our site.

npm run build

Conclusion

With that, you now know how to install and import Bootstrap with Laravel and Vite. 🎉

The finished code is available on my GitHub in the laravel-vite-and-bootstrap repository and can be stepped through commit by commit.

Til next time, have a great day. 👋

How to use jQuery with Laravel and Vite

Kim Hallberg — Mon, 26 Sep 2022 22:03:32 +0000

jQuery is one of the OG JavaScript libraries still in heavy use in the Laravel community to this day. It was a breeze to add with Laravel Mix, but since Laravel v9.2.0 Vite is now the default and a lot of users have had trouble getting it to work.

Fret not, because in this post we will go over how to install it, import it, and how to use it with Laravel 9 and Vite.

Installing jQuery

jQuery is installed with a single command from your terminal using your preferred node package manager. We will use npm in this post.

Travel to the root of your Laravel application and run the following command.

npm install jquery --save-dev

We use the --save-dev flag since Laravel added all its node dependencies as development dependencies by default, so why not follow their lead?

Importing jQuery

Now that we have jQuery installed, we will import it in our bootstrap.js file. That's where Laravel imports its dependencies, so again, why not do the same? We can import jQuery anywhere really, but for this example, we will add it below the lodash import.

import $ from 'jquery';
window.$ = $;

We will also add jQuery to the window object. This will be useful for when we need to access jQuery directly in a Blade file.

This step is optional though, if you never intend on using jQuery directly in a Blade file and plan to use it in your app.js file only, then there is no need to add it to the window object.

Using the Vite directive

Now jQuery is installed and imported, but we still won't have access to it in our application. For that, we need to load our app.js script using the @vite Blade directive.

@vite('resources/js/app.js')

For this simple example, we are only loading our app.js asset. If you want to load your app.css asset as well, then you will have to use an array and load both.

@vite(['resources/css/app.css', 'resources/js/app.js'])

For more information, I recommend you read Laravel's documentation on Asset Bundling with Vite.

Using jQuery?

We now have jQuery installed, imported, and loaded in our application. But how do we actually use it? Before we could access jQuery using the $ in a blocking inline <script> tag.

If you try to do that now, it will result in the following console error.

Uncaught ReferenceError: $ is not defined

So how do we prevent this from happening? It's rather simple, the first thing you need to understand is a bit about how browsers load JavaScript. Specifically how it loads JavaScript modules, because that is how Laravel loads JavaScript with Vite.

JavaScript modules are deferred by default. So a blocking inline script tag, even added at the bottom of your <body> is executed before your JavaScript modules.

Since the browser hasn't loaded in the app.js module yet, jQuery hasn't yet been added to the window object, so trying to access it before that results in the reference error.

jQuery and Inline Scripts

So you might think that we cannot use jQuery with inline scripts. We can, the only difference from before is that now your inline <script> tag also needs to be a JavaScript module. By doing that, we fix the loading issue.

Add the following line in your welcome.blade.php view, somewhere after your @vite directive call.

<script type="module">
    $('body').html('<h1>Hello World!</h1>');
</script>

Now when we load our landing page, we should see the words - Hello World!

jQuery and App.js

What if you want to access jQuery in your app.js file? We can use the $ in there as well, and we can demonstrate that with this little snippet.

$(() => {
    setTimeout(() => {
        alert('jQuery triggered via app.js')
    }, 2500);
});

If you've ever wanted to test some JavaScript this might look familiar. This simple snipper sets a timer that when finished triggers an alert.

Finishing up

If you've followed along we now have two jQuery calls, that both demonstrate accessing jQuery in different situations. If you now build your assets, with the following command.

npm run build

And access the site, you will see the default Laravel landing page disappear and be replaced with Hello World! , and after about 2 seconds the alert should pop up.

Conclusion

Now you know how to install, import, and access jQuery with Larvel and Vite. 🎉

As always, the finished code is available on my GitHub in the laravel-vite-and-jquery repository and can be stepped through commit by commit.

Til next time, have a great day. 👋

Getting Started with TALL stack

Kim Hallberg — Tue, 13 Sep 2022 09:11:50 +0000

TALL stack is a full-stack development solution used for building powerful, modern, and reactive Laravel applications. This stack can be used to build a multitude of applications, in fact, you're reading this on a platform built with the TALL stack.

Built with a foundation in Laravel, it uses Livewire for dynamic interfaces, Tailwind CSS for smooth and rapid designing, and Alpine.js for composing client-side interactions. Hence the name - TALL stack.

There are several ways to create a TALL stack app, but all begin with installing Laravel, so that's what we're going to start with.

Installing Laravel

To start using the stack, we first need to install our foundation, which is Laravel. We can install Laravel in several ways, but the quickest way is using Composer, and we can do that with the following command.

composer create-project laravel/laravel tallstack

This command will create a new folder wherever you ran the command using the project name as the directory name. In this example, the directory will be tallstack.

Now that we have installed a Laravel application, we can start adding the rest of our stack. We can install the rest of our stack using different ways, the easiest would be to use a Laravel starter as our base.

Installing via starter kit

Laravel makes available two different starter kits, Breeze and Jetstream. If you've used Laravel UI before you'll be right at home with Breeze. If you want something heftier with profile management, two-factor authentication, browser sessions, and more you want to choose Jetstream.

Using Laravel Breeze

To install Breeze we use Composer to require it, in the root of your newly created Laravel application, run the following command.

composer require laravel/breeze --dev

With this, we can now use Artisan to install Breeze's default stack (Breeze & Blade), which will scaffold authentication and install Tailwind CSS and Alpine.js for us.

php artisan breeze:install

To finish Breeze you will have to migrate your migrations using Artisan.

php artisan migrate

Your last step will be to install Livewire, which we go over further down in the manual section. The installation steps are the same the only difference is you add Livewire's JavaScript and CSS directives in your app.blade.php and guest.blade.php layout files.

Using Laravel Jetstream

To use install Jetstream we first need to require it by using Composer.

composer require laravel/jetstream

Next, we have to install Jetstream using Artisan and let it scaffold our application and install the necessary dependencies.

php artisan jetstream:install livewire

And with that we are nearly complete with Jetstream, all that is left is to migrate our migrations.

php artisan migrate

With that you have a newly created TALL stack application, you don't have to read anymore and can go create your next big project.

Installing each dependency

If you choose not to use a starter kit and want to install the rest of the stack manually, you can do that by following the steps down below.

Installing Livewire

Livewire will be the next part of our stack and we can install Livewire using the same tool as before, Composer. Open your Laravel application in your terminal and use Composer to require Livewire.

composer require livewire/livewire

With Livewire installed as a dependency, we can add the necessary JavaScript and CSS files to our view or layout file.

Note that if you have a layout file, add the following to the <head> of your layout file instead of each individual view. In this example we don't have a layout, so we're adding it directly to the bottom of our welcome.blade.php view <head>.

@livewireStyles

To finish up Livewire we have one more line to add to the end of our <body>. The same applies here, if you have a layout file, add it to the layout file. We only want to load Livewire's JavaScript and CSS files once.

@livewireScripts

To make sure our assets rebuild when we're developing locally, we have to update your vite.config.js file to include Livewire in its refresh paths. We do that by deconstructing the default paths and adding Livewire's paths into the new list.

import { defineConfig } from 'vite';
import laravel, { refreshPaths } from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel({
            input: [
                'resources/css/app.css',
                'resources/js/app.js',
            ],
            refresh: [
                ...refreshPaths,
                'app/Http/Livewire/**',
            ],
        }),
    ],
});

And with that, we are up and running with Livewire. If you did this step after using Breeze you are now finished and have a fully-fledged TALL stack application. If you're doing this manually then Tailwind CSS is up next.

Installing Tailwind

Setting up Tailwind CSS in a Laravel application is a breeze, the team at Tailwind CSS even has a guide for it. A guide that we will follow by installing Tailwind CSS and its dependencies as described.

npm install -D tailwindcss postcss autoprefixer

Next, we need to generate our Tailwind CSS and PostCSS config file using npx.

npx tailwindcss init -p

With those steps finised we can configure our Tailwind CSS template paths by adding to the content array in our tailwind.config.js file.

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./resources/**/*.blade.php",
    "./resources/**/*.js",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

I am omitting Vue files here since we are not using Vue, so Blade and JavaScript files are enough here.

Now we can add the Tailwind directives to our app.css file, located in ./resources/css/app.css.

@tailwind base;
@tailwind components;
@tailwind utilities;

With this, we can update our view or layout file to use Laravel's Vite directive. Add the following line in your <head> by replacing an existing <style> as we have in our welcome.blade.php, or by adding it above our Livewire CSS directive.

@vite('resources/css/app.css')

Visiting our site now should result in the following error - Vite manifest not found at: /tallstack/public/build/manifest.json. We can fix this by starting a Vite development server using the following command.

npm run dev

This is great when working locally, our assets update when we make changes in our views, but it does come with a caveat. When we stop our development server the error will be back. We can solve that by starting the server again or building for production by using build instead of dev.

npm run build

Now we can use both Livewire and Tailwind CSS, our last step in Alpine.js

Installing Alpine.js

Our final dependency to install is Apline.js. And we will install Alpine.js as a module using NPM just like Tailwind CSS and following the installation guide.

npm install alpinejs

We can now import Alpine in our boostrap.js file, located in ./resources/js/bootstrap.js. Let's import Alpine at the bottom of our bootstrap file.

import Alpine from 'alpinejs'

Now, all we need do to is initialize Alpine using its start method.

Alpine.start()

If you want more flexibility with Alpine, like accessing Alpine using the Alpine.js devtools, you can add Alpine to the window object, though it is not required for Alpine to work.

window.Alpine = Alpine

Our last step is to update our Vite directive to include our app.js file. We do that by placing our existing string argument inside an array and adding our app.js path as an array item.

@vite(['resources/css/app.css', 'resources/js/app.js'])

And as with Tailwind CSS, you can either start a Vite development server or build for production to generate new asset files.

Conclusion

And with that, you now have a TALL stack application. Your next step will be to create a Livewire component and perhaps build an Alpine.js dropdown.

What you will build is up to you and your imagination, so go out and create your next big project. 🤘

Source code for this article is available on my GitHub - thinkverse/tallstack-example - if you are more comfortable reading commits and code. You can find the Breeze and Jetstream examples in their respective branches. 👍

How to Add Sign in With GitHub to Wave

Kim Hallberg — Fri, 12 Nov 2021 21:26:04 +0000

Introduction

In this tutorial, we will cover how to add social login to Wave. For this example, we will use GitHub as our OAuth provider.

We will start by adding Laravel's Socialite package. This package is designed for quickly and conveniently authenticating with an OAuth provider.

composer require laravel/socialite

Boostrapping Socialite

Next, we will follow the steps given to us via the Socialite documentation. Namely, setting up our environment variables. Linking those together with our services config. Creating our controllers and lastly our routes.

Let's start by updating our .env and .env.example by adding these three variable keys.

GITHUB_CLIENT_ID=
GITHUB_CLIENT_SECRET=
GITHUB_REDIRECT_URL=

Note that we're not adding the secret keys to the .env.example file and only empty placeholders.

Moving on to our config/services.php file, let us add the correct configuration so that Socialite gets the GitHub OAuth keys.

'github' => [
    'client_id' => env('GITHUB_CLIENT_ID'),
    'client_secret' => env('GITHUB_CLIENT_SECRET'),
    'redirect' => env('GITHUB_REDIRECT_URL'),
],

Before we go over to GitHub and get our secret keys, let us generate a new empty controller and add some routes.

php artisan make:controller Auth\\GitHubSocialiteController

This command will generate an empty controller in our existing Controller\Auth folder. We will quickly add two empty methods called redirect and callback to it. There will be the ones our routes will call when hit.

class GitHubSocialiteController extends Controller
{
    public function redirect() {}

    public function callback() {}
}

Now in our routes/web.php, we can add our two routes. Adding a name to our redirect endpoint makes it easier to generate a URL for it later.

Route::middleware('guest')->group(function () {
    Route::get('auth/github/redirect', [GitHubSocialiteController::class, 'redirect'])->name('github.login');
    Route::get('auth/github/callback', [GitHubSocialiteController::class, 'callback']);    
});

The reason for adding the guest middleware is that we don't want authenticated users to try and logged-in again when they're already logged in.

Registering a GitHub OAuth App

Now that we have the boilerplate for Socialie done, we can head over to GitHub and register our new OAuth app.

Fill out the information with your application's name and appropriate URLs. The callback URL should match the URL you gave to the callback route.

After registering the new app with GitHub, we get redirected to the applications' general settings. Here we can grab our applications' client ID and generate a new client secret.

Keep in mind that you'll only see the applications' client secret ones. So make sure you copy it after generating it. Otherwise, you'll have to delete the old secret and generate a new one.

With these keys generated, we can now update our .env variables with those keys. Of course, your keys and callback URL will be different.

GITHUB_CLIENT_ID=4f636859a54b7410a51f
GITHUB_CLIENT_SECRET=26ba921db4bb0a8dca6c733de5705266ed28346d
GITHUB_REDIRECT_URL='https://wave.test/auth/github/callback'

With these keys set, Laravel Socialite can now create the correct payload to send to GitHub when a user's trying to authenticate via our application.

Extending our User Model

Now that we've done the Socialite boilerplate and registered our new OAuth application. Our next step is to prepare our user model to store our id provided by GitHub.

We do this by generating a new migration where we add our new column.

php artisan make:migration AddProviderIdToUsersTable

This command will generate a new migration named Y_m_d_His_add_provider_id_to_users_table.php. Modify the new file and add the new varchar column named provider_id.

The column should be nullable since not all users will use the feature. Add unique since GitHub will not return the same id for different users so we will reflect that in our column.

class AddProviderIdToUsersTable extends Migration
{
    public function up()
    {
        Schema::table('users', function (Blueprint $table) {
            $table->string('provider_id')->nullable()->unique();
        });
    }

    public function down()
    {
        Schema::table('users', function (Blueprint $table) {
            $table->dropColumn('provider_id');
        });
    }
}

Last but not least, add the provider_id to the App\Users' fillable property. That way, we can easily add it when creating our user later.

/**
 * @var array
 */
protected $fillable = [
    ...,
    'verified',
    'trial_ends_at',
    'provider_id',
];

Authenticating with GitHub

The time has finally come to connect these pieces together and start authenticating against GitHub when a user hits the auth/redirect endpoint.

We will start with the simplest of additions to our code, a single line in our GitHubSocialiteController controller.

Update your redirect method and add the following line of code.

public function redirect()
{
    return Socialite::driver('github')->redirect();
}

Lets' not forget to also use the Socialite facade, if your IDE or editor has auto-complete you can skip this since it's already there.

use Laravel\Socialite\Facades\Socialite;

With this Socialite will generate the necessary payload so when a user travels to the auth/redirect endpoint.

It will then redirect to GitHub, ask for the user permission to authenticate the application, and grant them access to the users' identity.

Handling the OAuth Callback

Our last section will be the one with the most code. That is because we have things to consider in this callback state.

We first need to get the user identity provided by GitHub, we also need to consider Wave's trial functionality and give the user our default role.

Luckily, that isn't so difficult. Since the code for that has already been written by the maintainers of Wave we can simply copy that to match the functionality.

Update the callback method in your GitHubSocialiteController controller and add the following code.

public function callback()
{
    $github = Socialite::driver('github')->user();
    $role = Role::where('name', '=', config('voyager.user.default_role'))->first();

    $trial_days = setting('billing.trial_days', 14);
    $trial_ends_at = null;

    if (intval($trial_days) > 0) {
        $trial_ends_at = now()->addDays(setting('billing.trial_days', 14));
    }
}

Stepping through the code a bit. Firstly using the Socialite facade to get the identity provided by GitHub. Secondly, we use Voyager's Role model, and using the config we can find the default role, we'll need that soon.

Last but not least we get the trial days defined in our site settings. We will also set the trial_ends_at variable to null as a default. We will only overwrite that if our trial days are greater than 0.

Meaning if we've set our trial days to -1, effectively negating them we don't set an end date and leave it null.

We're almost done with this tutorial. We are finally going to tackle the last real hard part. Consider this scenario, we've already registered several users before we add this feature.

Now, what happens when an already existing user tries to sign in with GitHub on our application? Well, their email is probably the same, maybe their username is also the same? So adding them again will create a duplicate entry error.

Maybe we only add the provider_id to their record? That will only work for existing users though. For new, users signing up for the first time via GitHub, we need to add their email, username, etc.

We will have three states to contend with, existing users, new users, and returning users. Lets' handle all three scenarios step-by-step, starting with returning users.

First, we need to check if any user in our records already has the id added, if that's the case we can simply return that user and sign them in.

Update your callback method with the following code.

$user = User::query()
    ->where('provider_id', $github->getId())
    ->first();

if ($user !== null) {
    return $this->login($user, 'Successfully logged in.');
}

For now, you don't have to worry about the login method, I will show that last since it's a method we will call in more than one place.

Next, we will tackle existing users. This is for the most part a carbon copy of the last scenario concerning returning users. The difference is we're checking for a matching email address, and if found we add the provider id and log the user in.

Add the snippet below the last one in your callback method.

$user = User::query()
        ->where('email', $github->getEmail())
        ->first();

if ($user !== null) {
    $user->update([
        'provider_id' => $github->getId(),
    ]);

    return $this->login($user, 'Successfully logged in.');
}

Two scenarios have not been handled. we'll now handle the last and final scenario, the new user. This scenario is where we'll use the $role and $trial_ends_at variables we defined before.

Add this final code snippet to your callback method.

$user = User::query()->create([
    'provider_id' => $github->getId(),
    'email' => $github->getEmail(),
    'name' => $github->getName(),
    'password' => bcrypt(str_random()),
    'username' => $github->getNickname(),
    'verified' => 1,
    'trial_ends_at' => $trial_ends_at,
    'role' => $role->id,
]);

event(new Registered($user));

return $this->login($user, 'Thanks for signing up!');

Taking full advantage of the identity provided for us by GitHub, we get an email for the user that's already verified by GitHub, a name, and a username. We only need to add the default role using the id and add the calculated trial end date.

A caveat here though, new users will get a randomly generated password. For safety reasons we won't email it to them since it's never a good idea to send plain text passwords over the wire.

So new users added via GitHub will have to reset their password via the forgot your password feature.

Before logging the new user in we send off Laravel's registered event.

Now before I end this post off. I will give you the last piece of this puzzle.

The login method, it's simply a DRY private method used to log the user in and redirect to the wave dashboard with a success toast message.

private function login($user, $message) {
    auth()->guard()->login($user, false);

    return redirect()
        ->route('wave.dashboard')
        ->with([
            'message' => $message,
            'message_type' => 'success',
        ]);
}

Conclusion

And there you have it, now all you need to do is add some sign-in or sign-up with GitHub buttons on your website, here's a quick example that works with Wave out-of-the-box.

<a href="{{ route('github.login') }}" class="flex w-full items-center justify-center space-x-4 mt-4 py-4 px-8 text-white bg-gray-800 shadow-lg rounded-md font-medium text-lg">
    <svg class="w-8 h-8 fill-current" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg">
        <path d="M12 .297c-6.63 0-12 5.373-12 12 0 5.303 3.438 9.8 8.205 11.385.6.113.82-.258.82-.577 0-.285-.01-1.04-.015-2.04-3.338.724-4.042-1.61-4.042-1.61C4.422 18.07 3.633 17.7 3.633 17.7c-1.087-.744.084-.729.084-.729 1.205.084 1.838 1.236 1.838 1.236 1.07 1.835 2.809 1.305 3.495.998.108-.776.417-1.305.76-1.605-2.665-.3-5.466-1.332-5.466-5.93 0-1.31.465-2.38 1.235-3.22-.135-.303-.54-1.523.105-3.176 0 0 1.005-.322 3.3 1.23.96-.267 1.98-.399 3-.405 1.02.006 2.04.138 3 .405 2.28-1.552 3.285-1.23 3.285-1.23.645 1.653.24 2.873.12 3.176.765.84 1.23 1.91 1.23 3.22 0 4.61-2.805 5.625-5.475 5.92.42.36.81 1.096.81 2.22 0 1.606-.015 2.896-.015 3.286 0 .315.21.69.825.57C20.565 22.092 24 17.592 24 12.297c0-6.627-5.373-12-12-12" />
    </svg>
    <span>
        Sign in with GitHub
    </span>
</a>

As before, thank you for reading and the full source code is available on my GitHub under the wave-with-socialite repository.

Have a great day. 👋

How to use BuyMeACoffees webhooks with Laravel.

Kim Hallberg — Sun, 01 Aug 2021 17:17:52 +0000

In this post, I will demonstrate how to use BuyMeACoffees Webhooks in Laravel. BMCs Webhooks allows you to get near-instant notifications when an event happens on your account, as said by BMC themselves.

When the event occurs—a supporter buys coffee for you, or someone purchases your coffeelink, etc.—BMC creates an Event object.

When an account event is triggered, BMC will send a POST request to your desired URL with the event as its payload. Those payloads will be a JSON object with the event-specific values being under the response key.

{
  "response": {
    "supporter_email": "supporter@buymeacoffee.com",
    "number_of_coffees": "1",
    "total_amount": "5",
    "support_created_on": "2021-08-01 16:00:00"
  }
}

So, let us receive this event in Laravel by creating a POST route that will be our webhook URL, a controller to handle the event, and a middleware that will verify its authenticity. We will begin by using artisan to make our controller and middleware.

php artisan make:controller BuyMeACoffeeWebhookController --invokable
php artisan make:middleware VerifyBuyMeACoffeeWebhook

I will use an invokable controller simply because this controller will only handle one thing. Now we will register our POST route and attach our controller and middleware.

Route::post('/buymeacoffee', BuyMeACoffeeWebhookController::class)->middleware(VerifyBuyMeACoffeeWebhook::class);

To verify that our webhook is authentic and is sent from BMC, we will use hash_hmac to verify that the SHA256 signatures match, this is done by hashing the incoming request and using our webhook secret as the hashing key, and checking that the resulting hash matches the given signature.

You can find your webhook secret in the webhook dashboard, each webhook you add will have its own secret, and can be regenerated by removing the webhook and adding it back again. It is best not to add our secret directly into our code, so we will create a new file under /config/webhooks.php which will get our secret from our environment variables.

<?php

return [
  'buymeacoffee' => [
    'secret' => env('BUYMEACOFFEE_WEBHOOK_SECRET'),
  ]
];

Now when we need our secret we can use Laravels config function to grab it.

So, time now to move along and update our middleware to verify the request.

use Illuminate\Http\Response;
use Illuminate\Http\Request;
use Closure;

class VerifyBuyMeACoffeeWebhook
{
  private array $headers = [
    'x-bmc-event', 'x-bmc-signature',
  ];

  public function handle(Request $request, Closure $next)
  {
     return $this->verify($request) ? $next($request) : response("Webhook signature didn't match!", Response::HTTP_BAD_REQUEST);
  }

  private function verify(Request $request)
  {
    if (! collect($request->headers)->has($this->headers)) {
      return false;
    }

    $signature = $request->header('X-Bmc-Signature');
    $request->headers->remove('X-Bmc-Signature');

    return hash_equals(hash_hmac('sha256', $request->getContent(), config('webhooks.buymeacoffee.secret')), $signature);
  }
}

Let me step over what we've done here. When the request first comes in we immediately pass it along to a private verify function that returns a boolean indicating if the request has been verified. If it has we let the request pass through to the next middleware and then on to our controller. Otherwise, we break the middleware chain by returning a 400 bad request response.

The private verify function will start by checking if the request has the necessary headers present that a BMC webhook request should have, mainly X-Bmc-Event and X-Bmc-Signature. We store those in a private array property on the middleware, so should the headers increase in the future we have an easy way of checking for those too.

This piece of logic is made easier with the help of Laravels collect method. Turning the headers into a collection gives us an easy method to call and check if the headers are present and if they're not we return false breaking the chain.

We could've also added a check in here for the BMC user-agent, which I omitted in favour of keeping this post shorter. Never the less that piece of logic could look something like this.

if (! str_contains($request->userAgent(), 'BMC-HTTPS-ROBOT')) {
  return false;
}

Moving along to our next piece which is the signature check. We start by first storing the request signature and then removing it from our header bag. This is done to prevent the signature from leaking out of our middleware and into our controller.

Lastly, as mentioned previously we use hash_hmac to hash the request content using our secret and check if it matches our signature. Since this is the last piece of logic we can simply return the outcome of this check.

If all of those checks pass, we can safely assume the request is valid and pass the request along the chain.

Now with a verified request, we can use our controller to delegate what we should do based on a given event. While you could handle both events together, I've chosen to separate them in this post to show how can be done. This is how our controller will look.

use Illuminate\Http\JsonResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Str;

class BuyMeACoffeeWebhookController extends Controller
{

  public function __invoke(Request $request)
  {
     $event = Str::camel($request->header('x-bmc-event'));
     $payload = $request->json('response');

     if (method_exists($this, $event)) {
       return call_user_func([$this, $event], $payload);
     }

     return response()->json("The event {$request->header('x-bmc-event')} is unsupported.");
  }

  public function coffeePurchase(array $payload): JsonResponse
  {
     return response()->json("Thank you for your support {$payload['supporter_email']}.");
  }

  public function coffeeLinkPurchase(array $payload): JsonResponse
  {
     return response()->json("Thank you for your support {$payload['supporter_email']}.");
  }
}

We start by transforming our event into a camel case version using Laravels string facade, this is done because PHP doesn't allow dashes in function names. Next, we use the json method on the request to grab the event-specific values from the response key, as mentioned in the beginning.

We then move along and check if we have a function to handle that event. This step might be redundant and unnecessary even in this context considering everything is located inside our controller.

I think it's useful to show how this check is done because. If this was implemented by yourself or another developer, these methods might be located in another class, or use snake case instead of camel case, maybe a method was misspelled of you haven't implemented a method to handle a specific event.

This simple check makes sure the event you want to handle can actually be handled, if it couldn't be handled, we return a message saying the event is unsupported. If a method was found, we pass in the payload into the method and call it.

Now it is up to each developer to decide how to handle this payload. Whether that is to associate the supporter_email to a user in your system, maybe give access to a private GitHub repository if the amount supported reaches a certain threshold, or simply send them an email thanking them.

Thank you for reading, I hope you enjoyed it. 🙌

Solving Multisoft's Monthly Code Challenge

Kim Hallberg — Tue, 06 Jul 2021 11:18:19 +0000

Swedish software company Multisoft does a code challenge each month, where it provides a fun little challenge for developers to solve. They do this in hopes of finding new candidates for potential employment.

In this post, we will go over and solve this month's following code challenge.

input = "0219247151", output = ""

for (i in 1 .. length(input))
    if (input[i]%2 == input[i-1]%2)
        output += max(input[i], input[i-1])

The challenge is written in pseudo-code and we want to know what will be stored in the output variable when the algorithm is finished.

The algorithm in itself is relatively simple and doesn't have very many working parts, but can be tricky if you're not paying close attention to the setup.

The setup for the algorithm creates two variables, we will call them input and output for simplicity. Our input stores our initial numbers, and output will store the result set of our for operation.

The Algorithm.

The algorithm will step over each number in the input string starting from the second index through to the last number, in each iteration we will check if the current and previous index have the same remainder when divided by 2.

When both indexes have the same remainder, we add the maximum value to our output variable.

The Solution.

Given the above algorithm, we could expect different results based on how a language handles string and integer concatenation.

If for instance, our language coerces the string returned from max to integers during the concatenation assignment, we could end up adding each result to each other instead of concatenating them.

+= usually indicated an arithmetic addition of the previous value added to our new value. In this instance though it indicated a string concatenation assignment.

Given that, stepping through the algorithm will look something like this.

Storing the final string value of 294755 in to the output variable.

In Conclusion.

This was a fun little challenge done by Multisoft, and I look forward to next month's challenge.

More challenges.

If you're interested is solving coding challenges, check out some of the links below.

How to create a simple CLI app with MiniCLI.

Kim Hallberg — Thu, 10 Jun 2021 14:12:21 +0000

In this post we're covering how to create a simple CLI app with the help of MiniCLI. What we'll be creating is a small CLI tool to ping websites.

Setting up our requirements.

The first thing we do is to create a folder for our new tool, which I'll name ping-cli and require the minicli/minicli package.

composer require minicli/minicli

Let's also create a .gitignore to make sure the /vendor folder doesn't get added to source control.

vendor/
composer.lock

Creating our entry-point.

With the requirements done we can continue on to creating our entry-point. This is what'll be called from the command-line. Create a bin folder and a file named ping-cli.

mkdir bin && touch bin/ping-cli

Now we can use bash and the minicli package to create our new tool. Start by using a shebang to load our new ping-cli file in a php environment, and add out opening php tags.

#!/usr/bin/env php
<?php declare(strict_types = 1);

You can omit declare if you don't want strict typing.

Before moving on to using minicli, we must first make sure we're calling this file from the CLI. We do this with the php_sapi_name functions, which returns the string of our current interface.

if (php_sapi_name() !== 'cli') {
    exit;
}

Integrating with MiniCLI.

To integrate minicli we include the composer autoloader and instantiate a new Minicli class.

We do this by establishing a new variable $root to hold the parent directory of the directory bin/ping-cli. Adding a check to see if we can grab the autoloader using that path. Should that operation be false, we will set the $root to be 4 levels up from our parent directory.

This is done so that if our tool is required and is symlinked to vendor/bin/ping-cli, we use the autoloader generated by the outside project correctly.

Lastly we require the autoloader and instantiate a new Minicli\App.

$root = dirname(__DIR__);

if (! is_file($root . '/vendor/autoload.php')) {
    $root = dirname(__DIR__, 4);
}

require $root . '/vendor/autoload.php';

use Minicli\App;

$app = new App();

To get the CLI tool to run, we have to call the runCommand method on our $app. Add the following line to the end of our ping-cli file.

$app->runCommand($argv);

The $argv variable is a reserved variable provided to us by PHP, you can read more about it in the documentation.

Running our command now will output ./minicli help to the console, try it yourself by running the command.

./bin/ping-cli

Updating our CLI signature.

Before embarking on the journey of creating the new command, let us first update our signature. This signature will replace the default ./minicli help signature ran when running our tool with no input.

We set our new signature using the setSignature method on the minicli $app.

$app->setSignature(<<<EOD
           _                        ___ 
    ____  (_)___  ____ _      _____/ (_)
   / __ \/ / __ \/ __ `/_____/ ___/ / / 
  / /_/ / / / / / /_/ /_____/ /__/ / /  
 / .___/_/_/ /_/\__, /      \___/_/_/   
/_/            /____/ \e[0;32m Ver. 0.0.1

EOD);

This will give us the following signature.

Registering our command.

With the basic setup out-the-way, let's continue on by registering our ping command. Since this tool will only have a single command, we will forgo registering a namespace and just register a single command with the registerCommand method.

To register the command, we pass it the name and the callable which will get passed the $input. For convenience we will also use the $app in out callable.

use Minicli\Command\CommandCall;

$app->registerCommand('ping', function (CommandCall $input) use ($app) {
    $app->getPrinter()->success('We have lift-off! 🚀');
});

Calling the getPrinter method access the output handler, which we then use to print a success message to the console.

Running ./bin/ping-cli ping will now print back We have lift-off! 🚀 in our console.

Updating our command.

With the command registered, let us move swiftly along to implementing our real ping command.

This command will take a url parameter, in either of two formats, HTTP or HTTPS. With this parameter, we will send a request to the url and see if it's accessible.

To grab the parameter we call getParam on our $input and specify which parameter we want. Let's store our url parameter in a $url variable, or default to null.

With this we can sent a error output using getPrinter and exit early if no url was provided.

$url = $input->getParam('url') ?? null;

if (! $url) {
    $app->getPrinter()->error('Parameter <url> was not provided');
    return 1;
}

Now we can continue on and validate the incoming $url parameter. To do that we will use RegEx and filter_var.

We first check for a valid URL - since URLs can be valid even without the HTTP protocol, we add this check first. Returning early is the check fails.

Next we use RegEx to check if the $url provided starts with a valid HTTP(s) protocol. Returning early with a message if that fails.

if (! filter_var($url, FILTER_VALIDATE_URL)) {
    $app->getPrinter()->error('Parameter <url> not a valid URL.');
    return 1;
}

if (! preg_match('#^https?://#i', $url)) {
    $app->getPrinter()->error('Parameter <url> has to include a valid HTTP protocol.');
    return 1;
}

While this isn't the end-all be-all of validating the $url, it'll do for a simple ping command.

A streaming context

Before we try and access the $url provided, we need to create a stream context for file_get_contents to use. In this context we will set the HTTP method and some HTTP headers.

To keep things a bit separated, let's create a new function called getStreamContext where we'll create our new context.

function getStreamContext() {
    $headers = implode("\r\n", [
        'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36',
        'Accept: text/html,application/xhtml+xml,application/xml;q=0.9',
        'Accept-Language: en-US,en;q=0.9',
        'Upgrade-Insecure-Requests: 1',
        'X-Application: PingCLI/0.0.1',
        'Sec-GPC: 1',
    ]);

    return stream_context_create([
        'http' => [
            'method' => 'GET', 
            'header' => $headers,
        ]
    ]);
}

We set some headers so the $url we're accessing thinks the site is being used from a Chrome browser running on a Mac.

Finishing up the command.

With the context created we can now use file_get_contents to ping the $url. Since we won't use the returning content for anything, we can use file_get_contents directly in our if statement.

if (! @file_get_contents($url, context: getStreamContext())) {
    $app->getPrinter()->error('Parameter <url> could not be reached.');
    return 1;
}

The reasoning being the silencing (@) is because we can provide a valid URL that file_get_contents might not be able to access, that will give of warnings unless silenced.

If all those checks are cleared, we can safely assume the site is reachable and up. Let's give the user an indication the site was reached by adding the following code to the end of our callable.

$app->getPrinter()->success(sprintf('URL <%s> is up.', $url));

We can now test our ping command by running the following.

./bin/ping-cli ping url=https://devdojo.com

This will produce the following result.

Extending our command.

Before I leave you, I'd like to add one more feature to our command. That's the estimated ping time, which is an estimate of how long it took to access the website.

We'll do this with the microtime function and some subtraction. We'll Add the following right above our file_get_contents check.

$start_time = microtime(as_float: true);

Below our if, and before we output our success message we add the following.

$end_time = microtime(as_float: true);

These two variables will now be used to estimate how long it took to access the site. Since they're places in between file_get_contents we should get a fairly close estimate.

Let's print that estimate to our user below out success output.

$app->getPrinter()->display(sprintf('Est. ping time: %.02f sec', ($end_time - $start_time)));

This will now add an estimated ping time to the end of our output, as displayed below.

Conclusion.

This is how you can create a simple CLI tool with the help of MiniCLI. You can read up more about minicli on their GitHub page, or their documentation, also follow the creator Erika Heidi on twitter.

That's all for me folks, thank you for reading. 👋

Complete source available on my ping-cli repository.

Troubleshooting.

If you're having issues running your new CLI tool, make sure the permissions are turned on to use the file as an executable. On Linux system this can be done with chmod, use the equivalent command for windows.

ping-cli ~ chmod +x bin/ping-cli

The future of Responsive Design with Container Queries.

Kim Hallberg — Sat, 22 May 2021 09:42:56 +0000

When we write responsive design using CSS today, we use the media at-rule, more commonly known as a Media Query. This at-rule queries the device or user-agent to grab the values it needs for our media condition. That condition can be a multitude of conditions based on the provided media type or media feature.

One thing that media cannot do sadly, is query DOM elements directly. This is where the container at-rule proposal from Miriam Suzanne comes in. A new at-rule specification that is currently being proposed, affectionately called Container Query Proposal.

The TL:DR; version of this proposal is to query an elements parent container for context based dimensions instead of the viewport dimensions. For instance if the parent container has a min-width: n do the following.

How to test the new at-rule.

Currently, there is only one browser that has released a prototype for the proposed specification and that is Chrome. Available in their nightly build - Chrome Canary, under the flag “CSS Container Queries”. Here are the steps on how to enable the flag.

Download Chrome Canary.
Go to chrome://flags in the URL bar.
Search for “CSS Container Queries”, enable the feature.
Restart the browser.

Miriam, the author of the proposal has a put together a CodePen collection of Container Queries demos for your testing pleasure. For more information on Container Queries, I recommend reading Container Queries Explainer & Proposal also written by the proposals author.

Creating a Container.

To make Container Queries work, we need to have a container available to query. That is done by creating a container. For that we use the CSS contain property along with the layout and size values.

selector {
    contain: layout inline-size;
}

The size value inline-size uses the inline-axis on the container. A quick note here, there is a block-size in the prosposal. That is currently not available in the Chrome prototype, there is still a discussion if this axis is even needed so keep that in mind.

Writing Container Queries.

With a new container established, we can now query for it using the container at-rule.

@container (<container-query-list>) {
    <stylesheet>
}

That is the proposed syntax, similar to @media except it uses @container instead. Your <container-query-list> uses queries based on the containment context i.e min-width, max-width, width etc, similar to Media Queries.

The <stylesheet> will now be responsive to the nearest ancestor container if finds.

@container (min-width: n) {
    selector {
        display: none;
    }
}

The above example for instance, will set the display to none for the given selector, when it finds an ancestor container that matched the provided Container Query min-width of n.

More examples.

That will be our brief overview of the Container Query Proposal. For more examples of Container Queries, I recommend watching Una Kravets talk; The new responsive: Web design in a component-driven world.

Kevin Powell video; Container Queries are going to be a game changer! and, of course. Take a peek at the proposal itself.

You don’t necessarily need Composer

Kim Hallberg — Sat, 15 May 2021 22:49:39 +0000

Don't get me wrong, Composer is an amazing product. It has an easy-to-use API for quick autoloading, supports multiple standards, and has autoloading optimization built-in - it even lets you search and require packages easily. It's a reason Composer is the most used package manager for PHP.

If your project is a lightweight OOP project with no external packages though. Using Composer might be a bit overkill, you could easily implement autoloading using a simple array and PHP's spl_autoload_register function.

For those not familiar, spl_autoload_register is what we can use to add to our own autoloading function to PHPs autoloading queue. We can use that together with a simple array $classmap to autoload our small project. Here's our project structure.

/public/index.php
/src/*/.php
autoload.php

/public will be our front-facing entry point, /src will hold our classes, and autoload.php will handle our autoloading. Our classes will be formatted in PSR-4, with our vendor namespace prefix being used as the key for our internal $classmap.

Let's create our autoload.php file and add some autoloading to our project.

define('PHPNEXUS_VERSION', '0.0.1');

$classmap = [
    'PHPNexus' => __DIR__ . '/src/',
];

spl_autoload_register(function(string $classname) use ($classmap) {
    $parts = explode('\\', $classname);

    $namespace = array_shift($parts);
    $classfile = array_pop($parts) . '.php';

    if (! array_key_exists($namespace, $classmap)) {
        return;
    }

    $path = implode(DIRECTORY_SEPARATOR, $parts);
    $file = $classmap[$namespace] . $path . DIRECTORY_SEPARATOR . $classfile;

    if (! file_exists($file) && ! class_exists($classname)) {
        return;
    }

    require_once $file;
});

Going over our code shows we first define a new constant - PHPNEXUS_VERSION, this will be used to check if our autoload file has already been loaded later. $classmap is an associative array - as previously mentioned our vendor namespace is our key. The value of which is the location to our source files, in this case, that is /src. And since autoloading.php is in our root, we can take advantage of the __DIR__ constant.

The first argument of spl_autoload_register is the callback function - that's our autoloading function. That function will take a string parameter - when you instantiate a class with new, the FQCN gets passed as that parameter's argument.

Next, we are destructuring our $classname argument by separating each value into an array $parts variable. Since we know our first $parts value is our vendor namespace, we use array_shift to grab it and use array_pop to grab the actual filename since we also know that's the last part of our $classname.

We then do a quick check to see if the $namespace is in our $classmap so we can handle the file location, if that's not the case we simply do an early return out of the function.

$path will be the variable holding the remaining parts of our $parts array, since the filename and namespace are already removed, we can assume the rest of the pieces are the rest of our file path.

We then reassemble our file path info into a temporary $file variable and check if that file exists. As a precaution, we also include a check to see if the class has already been defined. If either fails - as before, we return out of the function and be on our merry way.

Lastly, if nothing fails all we do is require the $file that contains our class so PHP can now initialize it.

To then use our simple autoloading file, in our public/index.php we simply add the following if statement.

if (! defined('PHPNEXUS_VERSION')) {
    require_once dirname(__DIR__) . '/autoload.php';
}

This does a check for the earlier constant to see if the file has already been included or required earlier, if that fails we require our autoload.php file and now we can use our classes, e.g. if we had a PHPNexus\Request\Request class located in /src/Request/Request.

if (! defined('PHPNEXUS_VERSION')) {
    require_once dirname(__DIR__) . '/autoload.php';
}

use PHPNexus\Request\Request;

$request = new Request($_SERVER);

And that's how we can create simple autoloading for our project without having to rely on Composer. As mentioned above though, if your project already requires packages from other sources via Composer, then it's best to stick with Composers autoloader instead.

To leave off, have you ever written your own function to handle autoloading before? Perhaps you didn't know how to do it and you know do, let me know by replying to the topic. Would love to hear your thought on implementing simple autoloading for projects.

Laravel Quickie: Basic Controllers

Kim Hallberg — Wed, 02 Dec 2020 06:33:35 +0000

Introduction

Welcome to Laravel Quickie!

In this section, we will go over the two basic controllers used in Laravel. The regular controller and the single-action controller.

Prerequisites

If you don't already have a Laravel project up and running. I'd suggest using a DigitalOcean Ubuntu Droplet. Use my affiliate code to get free $100 DigitalOcean credit over 60 days to spin up your own server!

If you do not have that yet. You can follow the How to Install Laravel on DigitalOcean with 1-Click tutorial on how to do set that up.

Alternatively, you could use the awesome LaraSail script to do the installation.

Regular Controller

The regular controller. A simple controller that is used in every Laravel application. Usually extending the BaseController that comes with a new Laravel project.

Generate Controller

To generate a regular controller instead of creating one manually you can use the following artisan command.

php artisan make:controller {name}

This command will generate a blank controller with the given name argument; for instance.

php artisan make:controller ProductController

Will generate a blank ProductController class located under app/Http/Controllers.

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class ProductController extends Controller
{
    //
}

Use Controller

To use our newly created controller we need to give it a method we can access somewhere in our code, our routes/web.php perhaps.

Let's add a quick public index() method on our new ProductController. We can return Laravel's default welcome view.

class ProductController extends Controller
{
    public function index()
    {
        return view('welcome');
    }
}

Now that our controller has been updated. We can update the route file to use that instead of returning the view.

use Illuminate\Support\Facades\Route;

use App\Http\Controllers\ProductController;

Route::get('/', [ProductController::class, 'index']);

Single Action Controller

Now a ProductController isn't really the place to return a welcome view from. That sounds like a single action. And that's a perfect way to use invokable controllers.

An invokable controller is a single action - or method, controller.

Generate Controller

We can use artisan to create those controllers as well using the --invokable flag. Let's generate a single action controller to return our view instead.

php artisan make:controller WelcomeController --invokable

This type of controller comes with a php magic method called __invoke. The method in question gets called whenever the class is called as a function.

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class WelcomeController extends Controller
{
    /**
     * Handle the incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return \Illuminate\Http\Response
     */
    public function __invoke(Request $request)
    {
        //
    }
}

Use Controller

Now we can move the return view statement to that controller instead.

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class WelcomeController extends Controller
{
    public function __invoke()
    {
        return view('welcome');
    }
}

Now our controllers look mostly the same except for the method signature. You might think we call this by simply adding __invoke as the second array value.

Route::get('/', [WelcomeController::class, '__invoke']);

While that works. There an even cleaner and shorter way to use single-action controllers.

use Illuminate\Support\Facades\Route;

use App\Http\Controllers\WelcomeController;

Route::get('/', WelcomeController::class);

Controller Parameters

Let's finish by talking a bit about parameters.
Used to pass information to our controller. The most basic usage is for URL parameters and the current incoming Request object.

As you've most likely noticed all generated controllers come with the Request already imported using the use keyword.

Let's add a new public show() method to our ProductController that takes that Request and a $product as parameters.

class ProductController extends Controller
{
    public function show(Request $request, string $product)
    {
        //
    }
}

We can now update our routes yet again and add a new /products/{product} route.

use Illuminate\Support\Facades\Route;

use App\Http\Controllers\WelcomeController;
use App\Http\Controllers\ProductController;

Route::get('/', WelcomeController::class);

Route::get('/products/{product}', [ProductController::class, 'show']);

Most others might use {id} here. But by using{product}` instead, illustrates the point that the name you give the route parameter will be the name of the controller parameter.

To see the arguments passed to the parameters. We use Laravel's built-in die dump function.

php class ProductController extends Controller { public function show(Request $request, string $product) { dd($product, $request); } }

Passing our two arguments into the die dump function will give you similar output to this when visiting /products/laravel-quickie in a browser.

The same would work for a single-action controller too, just add your parameters to the __invoke() method, and use it as a regular controller method.

Conclusion

I hope this little quickie answers any questions you have about basic controllers. And, as always, code is available on my GitHub under the /laravel-quickie repository.

For this section take a gander under the quickie-basic-controllers branch.

Thank you for reading and, till next time.

Note

The last code block won't render correctly, but as stated above. The code is available in the repository.

Laravel Quickie: How to install and build TailwindCSS v2 with Laravel Mix 😎

Kim Hallberg — Mon, 30 Nov 2020 17:28:17 +0000

Introduction

Welcome to another Laravel Quickie!

In this quickie, we will go over how to install and build TailwindCSS v2 with the help of Laravel Mix. If you've already tried and have run into issues, hopefully, this post will solve those issues for you.

Prerequisites

If you do not have that yet. You can follow the How to Install Laravel on DigitalOcean with 1-Click tutorial on how to do set that up.

Alternatively, you could use the awesome LaraSail script to do the installation.

Current issues

Before we go on with the installation and building of TailwindCSS v2, let's go over some of the current issues that arise when installing TailwindCSS v2 into an existing project running Laravel Mix v5.

With the newest version on TailwindCSS v2. They've upped their PostCSS dependency to ones compatible with PostCSS 8, being a relatively new version. Most tools haven't yet updated, as explained in their documentation.

"Tailwind CSS depends on PostCSS 8. Because PostCSS 8 is only a few months old, many other tools in the ecosystem haven't updated yet"

So with that in mind, let's go over installing TailwindCSS v2 with Laravel Mix 5.

Tailwind v2 and Laravel Mix 5

Setup a test view

Let's start with setting up a test view that will contain code from TailwindCSS v2 so we can test if we've successfully built it correctly.

If you're following along with a new Laravel project, you can open your default welcome.blade.php file and update accordingly.

<!DOCTYPE html>
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">
    <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">

        <title>Laravel</title>

        <link rel="stylesheet" href="{{ mix('/css/app.css') }}">
    </head>
    <body class="antialiased">
        <div class="flex items-center min-h-screen pl-20 bg-gray-100 dark:bg-gray-900">
            <h1 class="font-black text-9xl">
                Welcome to <span class="text-transparent bg-clip-text bg-gradient-to-tr from-blue-700 to-indigo-400">TailwindCSS v2</span>
            </h1>
        </div>
    </body>
</html>

This snippet of code introduces the new text-9xl class from TailwindCSS v2. Opening this in our browser should result in the following exception; The Mix manifest does not exist. (View: /./resources/views/welcome.blade.php).

With our test view out of the way let's install TailwindCSS.

Installing TailwindCSS

To install TailwindCSS v2 you need only run the following command.

npm install tailwindcss --save-dev

This will install the latest version of TailwindCSS as a developer dependency.

We can now update our webpack.mix.js file and our /resources/css/app.css file to include TailwindCSS v2.

mix.js('resources/js/app.js', 'public/js')
    .postCss('resources/css/app.css', 'public/css', [
        require('tailwindcss')
    ]);

@tailwind base;
@tailwind components;
@tailwind utilities;

Let's now run our development build process and see what happens when we try and build.

npm run dev

Whoops! While Laravel Mix starts to build - it even downloads a new dev dependency in vue-template-compiler. In the end, it fails due to our incompatibility with the current version.

PostCSS plugin tailwindcss requires PostCSS 8.

This is the issue I was talking about in the beginning, while I explained it. It's always best to see it in action.

Let's solve the build

We can solve this build issue rather simply. Let's first uninstall our current TailwindCSS dependency.

npm uninstall tailwindcss

Thankfully the amazing developers over at TailwindLabs have released a compatible version. So let's install that instead.

npm install tailwindcss@npm:@tailwindcss/postcss7-compat --save-dev

With a version installed that's compatible with Laravel Mix 5, we can now run our build process again.

npm run dev

Success! You have now successfully build TailwindCSS v2 with Laravel Mix 5! 🎉

Going to our page now - if you've followed along, should look similar to this.

TailwindCSS v2 and Laravel Mix 6 Beta

You've successfully build TailwindCSS v2 already with Laravel Mix 5. But if you'd like to use Laravel Mix 6 - which is currently in its beta stage and is running PostCSS 8. We will have to uninstall some dependencies.

npm uninstall tailwindcss laravel-mix vue-template-compiler

Next, we need to install the Laravel Mix 6 beta and the latest version of TailwindCSS.

npm install tailwindcss laravel-mix@next --save-dev

You might see some resolve errors in your console about overriding dependencies. They shouldn't give you any problems, and the installation should work just fine.

Now we can run our development build as before.

npm run dev

With this, you've successfully installed and built using the Laravel Mix 6 beta. 🎉

Going to our page now - if you've followed along, should look similar to this.

Production build

To run a production build with Laravel Mix 6 you need to update your build script a bit.

    "scripts": {
        "prod": "npm run production",
        "production": "cross-env NODE_ENV=production node_modules/webpack/bin/webpack.js --config=node_modules/laravel-mix/setup/webpack.config.js"
    },

With this, you can not run your production build using.

npm run prod

Bonus: Purging with TailwindCSS

As I mention production runs, let me show you how to purge your CSS classes to not make your production build too large. This will for both versions.

First - if you haven't generated your tailwind.config.js file yet. Let's run the following command at the root of our project.

npx tailwindcss init

With this file generated, we can add the resources we want TailwindCSS to purge on a production run by updating the purge array.

module.exports = {
  purge: [
    'resources/views/**/*.blade.php',
    'resources/js/**/*.js',
  ],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
}

TailwindCSS will look for the tailwind.config.js file in the root of your project by default, so you're not required to pass it in as you did in the past.

But if you want to do that just update your webpack.mix.js file in the following way.

mix.js('resources/js/app.js', 'public/js')
    .postCss('resources/css/app.css', 'public/css', [
        require('tailwindcss')('./tailwind.config.js')
    ]);

With this next time you run npm run prod TailwindCSS will use PurgeCSS to remove unused CSS classes.

Conclusion

There you have it, two ways to install and build TailwindCSS v2 in Laravel with the help of Laravel Mix 5 and, 6 beta.

I hope that helped you in some way, and as before. Till next time.

TL:DR; Show me code

Like most of my articles, the code is available publicly on my GitHub, the following article can be found in the repository named /tailwind-and-laravel-mix, separated into a master branch and another called laravel-mix-beta.

You will find the Laravel Mix 5 version in the master and the latter in the beta branch.

Useful HTML codes with a quick click. 👍

Kim Hallberg — Fri, 06 Nov 2020 09:20:47 +0000

Just found out that we can use HTML codes to create arrows - e.g. a right-pointing arrow "→". There are a lot of useful HTML codes out there. Here is a quick CodePen of some I think might be useful. 😀