DEV Community: Rachid

Use Storybook with Laravel Jetstream, Inertia and TailwindCSS

Rachid — Wed, 13 Apr 2022 14:03:32 +0000

Do you want to use Storybook in your Laravel App using Jetstream and Inertia ?
Have you met some resistance and gave up because of Webpack ?

Then this post might help you. It is the result of frustrating search over the web to make it work. Hope you'll enjoy it.

Foreword

Before we begin, I'd like to emphasis that my knowledge in frontend is extremely limited. As Jon Stark, I know nothing Webpack-related and this post is really here to help people struggling to make Storybook work with Jetstream, Inertia and Tailwind. If you spot some horrendeous mistakes or anything that could be improved, please contact me through Twitter and I'll gladly update this post.

I wrote this post using this stack:

Laravel v9.2
Jetstream v2.7
Inertia v0.11
TailwindCSS v3
Storybook v6.4.21

Install Storybook

npx sb init
This command will snoop inside your package.json dependencies in order to determine which starting scripts Storybook will use. It will also install some dependencies, build a default configuration and sprinkle some default stories to begin with.

After installing it, you'll realize running Storybook will fail dramatically.

info @storybook/vue3 v6.4.21
info
info => Loading presets
info => Using implicit CSS loaders
info => Using prebuilt manager
info => Using default Webpack4 setup
ERR! TypeError: Cannot read property 'NormalModule' of undefined

It is using the wrong version of Webpack. Let's fix this.

Use the proper Webpack version

Let's start by adding two dependencies that sb init missed while snooping our project.

In package.json, I'll add these two devDependencies:

"@storybook/manager-webpack5": "^6.4.21",
"@storybook/builder-webpack5": "^6.4.21",

Then, we tell Storybook to use the proper builder by adding a new key in the object declared in .storybook/main.js:

"core": {
    "builder": "webpack5",
  },

Let's run npm install && npm run storybook and this time, you should be able to check your brand new Storybook !

Now let's add a story for a Jetstream's component, let's say.. the button.

Create a story

Remove the default stories that come by installing Storybook and inside a stories/Button.stories.js let's create our button's story:

import Button from '@/Jetstream/Button.vue';

export default {
  title: 'Jetstream/Button',
  component: Button,
};

const Template = (args) => ({
  components: { Button },
  setup() {
    return { args };
  },
  template: '<Button v-bind="args">Test Button</Button>',
});

export const MyButton = Template.bind({});

It shouldn't work because Storybook can't resolve '@/Jetstream/Button.vue'.

Let's fix this.

Fixing aliases

Inside .storybook/main.js, right after the core key we declared some steps ago, we'll add a new one called webpackFinal and put the aliases we have in our webpack.mix.js, like this:

"webpackFinal": async (config) => {
      config.resolve = {
          ...config.resolve,
          alias: {
              ...config.resolve?.alias,
              '@': '../resources/js',
          }
      }
      return config;
  }

Now we can restart our Storybook with npm run storybook and it should be good !

Well.. not totally. Where is Tailwind ?

Importing Tailwind

We need to tell Storybook to do some fancy stuff with postcss because.. well I don't know and frankly I'm afraid to ask. But adding this rule to the webpackFinal key we added previously makes it work. It's cool right? Right..?

config.module.rules.push({
          test: /\.css$/,
          use: [
              {
                  loader: 'postcss-loader',
                  options: {
                      postcssOptions: {
                          implementation: 'postcss',
                          plugins: {
                              tailwindcss,
                          }
                      },
                  },
              },
          ],
          include: path.resolve(__dirname, '../'),
      });
      config.resolve = {
          ...config.resolve,
          alias: {
              ...config.resolve?.alias,
              '@': '../resources/js',
          }
      }
      return config;
  }

I assume it is telling webpack to use postcss with a Tailwind's plugin to compile our css. Let me know if you got a better definition of what's going on here and I'll update it.

For this to work, we need to import some stuff, so at the top of the file:

const path = require('path');
const tailwindcss = require('../tailwind.config');

And we'll also import the app.css inside .storybook/preview.js:

import '../resources/css/app.css';

Now we restart again Storybook et voilà! Bim! You've got your story-nertia-wind up and running.

Final files

Get a look at the final files here

Bonus: Use Storybook on Lando

You're using Lando ? I wrote a little post to make Storybook works with Lando.

Use Storybook with Lando

Rachid — Wed, 13 Apr 2022 14:01:21 +0000

If you're using Lando to manage your containers because you're that cool, I'll show you my way to make Storybook works painlessly with Lando.

First open your .lando.yml, and add the mandatory node service:

services:
  node:
    type: node

Then, you're gonna need some tools to install Storybook and run it:

tooling:
  npm:
    service: node
  npx:
    service: node

Now you can install Storybook. If you're using TailwindCSS and Laravel, you can follow my guide over here.

In order to provide access to it, you need to add a proxy to the port, like this:

proxy:
  node:
    - storybook.my-lando-app.lndo.site:6006

Final file:

name: storynertia
recipe: laravel
config:
  webroot: app/public
  php: '8.1'
proxy:
  node:
    - storybook.storynertia.lndo.site:6006
services:
  node:
    type: node
tooling:
  npm:
    service: node
  npx:
    service: node

Enjoy your containerized Storybook!

Laravel Greedy Queries - a bad habit

Rachid — Fri, 04 Mar 2022 15:53:56 +0000

Photo by Colin Maynard on Unsplash

Vous parlez français ? Lisez ce billet sur mon blog :)

When I started using Laravel, I really enjoyed the fact that I could simply grab all my data with a simple line of code:

$products = Product::get();

All my products, in a beautiful little collection, waiting to be deliciously presented in an appealing view or handled with care in an data processing algorithm.

The problem is that sometimes / often (pick the right one) I only need a few informations from my products, like the name and price and no more. I don't need the extra informations my database could hold. And the code above is loading everything: name, price, description, maybe a picture and so on.

Get into the habit of specifying the desired columns when executing queries to the database, even if they are simple or not very demanding. This is a reflex that can offer us precious seconds of optimization during more complex operations.

For instance, if my view only needs name and price :

// 👎 I am loading every columns
$products = Product::get();

// 👍 I only load the specific columns I need
$products = Product::select(‘name’, ‘price’)->get();

The benefit is imperceptible on such simple queries and a small dataset, but it becomes essential at a certain level and helps to make the difference between a slow and fast query.

See you soon for another trap I fell for.

Organize your models scopes better in Laravel

Rachid — Wed, 08 Dec 2021 22:36:11 +0000

🥖🇫🇷🏴󠁣󠁡󠁱󠁣󠁿 Si vous préférez le français, cet article est disponible dans la langue de Molière sur mon blogue.

Intro

Sometimes I find my models cluttered with a lot of things: relationships, attributes casting, scopes, custom methods, etc.

When this happens, one thing I like to do is move my scopes in a dedicated builder. This post will show you how I do that.

We are working with bunnies because cats are all over the place already and because of the pressure I get from Coton the Tige. 🐰

Setup

Let's spin up our artisan command to create the model with the migration flag (-m) and the factory flag (-f):

php artisan make:model Bunny -mf

Now let's define the data structure of our fleecy table (gist):

Schema::create('bunnies', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->tinyInteger('fluffiness');
    $table->date('birth_date');
    $table->timestamps();
});

Great, now let's fill in the definition of our factory class (gist):

public function definition(): array
{
    return [
        'name' => $this->faker->userName,
        'fluffiness' => $this->faker->numberBetween(1, 100),
        'birth_date' => $this->faker->date(),
    ];
}

Wonderful. So now, you can create various random bunnies using the factory:

Bunny::factory()->count(10)->create();

Using scopes

Scopes are a great way to add filters (ie. query constraints) that can be easily reused all across your application.

For instance we could have a scope that says:

I want only the old bunnies (those that are 5 years old and up)

For that I can create a method in the Bunny model that goes like this (gist):

public function scopeOld(Builder $query): Builder
{
    return $query->where('birth_date', '<=', now()->subYears(5));
}

A scope method name must start with the word scope, this is how Eloquent can find it. (More details about this in the Illuminate\Database\Eloquent\Builder class, see API definition here)

That way I can grab all my old bunnies simply by executing this query:

Bunny::old()->get()

You can check this gist to get the Test Case I used while writing this velvety blog post.

This is all fun and games until you start getting a lot of stuff in that model and it goes from fluffy to shaggy. We don't want that.

This is why I like to create custom Builder, but before that, let's talk briefly about the Eloquent Builder.

The Eloquent Builder

When you do something like this:

Bunny::old();
Bunny::where('name', 'Arnaboun');
Bunny::latest();

You're not calling the Bunny model but the underlying Eloquent Builder class. This is the one in charge of building the query that will hit the database.

So when you're creating scopes for your fluffy models, what you are actually doing is provide new shortcuts to query your database. So, in my opinion, those scopes have a better spot right inside the Builder class.

Let's see how to make this a reality.

Creating a custom Builder

To create a custom builder, you need to create the appropriate class and it should extend Illuminate\Database\Eloquent\Builder.
A custom builder should concern one, and only one, model.

Feel free to put this class wherever it makes more sense to you, I usually create a Builders folder inside app.

This is how it looks:

<?php

namespace App\Builders;

use Illuminate\Database\Eloquent\Builder;

class BunnyBuilder extends Builder
{
    // hi mom.
}

Now I can migrate the scopes, go check the gist so that this post isn't too much scrollable.
Here is a sneak peek onto our previous scope:

public function old(): self
{
    return $this->where('birth_date', '<=', now()->subYears(5));
}

You'll notice two things:

We don't need the scope in our method's name anymore
We don't need to inject the Eloquent Builder because its now our context. ~ yaii, computer!~

Using our custom builder

Okay great, we have a custom builder but now how can we tell our model to use it ?

Laravel offers us a method that can create an instance of a custom builder (see its API definition). So we can simply drop this into our model:

public function newEloquentBuilder($query)
{
    return new BunnyBuilder($query);
}

And now, if we re-run our tests, it will still works meaning we didn't break anything. Our scopes can now live into their new realm and free up a bit the models responsibilities.

Thanks for reading me, this is my first attempt at writing in dev.to in english. Let me know how I did and how I can improve and progress and in the meantime, I hope you have a wonderful day.