DEV Community: David Berri

So, let's retry that?

David Berri — Sat, 24 Sep 2022 13:08:35 +0000

A few weeks ago, I had to implement some code that would need to retry an operation with different parameters if it failed on the first run but only if it did with a specific exception. I thought about it for a few minutes and before I tried to implement it myself, I decided to search Laravel's documentation to see if there was a helper or something that I could use. Turns out there is a helper called: retry. Yes, it was exactly what I was looking for and more.

According to the docs, retry accepts the number of attempts, the callback where your implementation goes and a third (optional) parameter that can either be a number of milliseconds or a closure to change the time it will wait before the next attempt. It also accepts a fourth (also optional) parameter: a closure that returns the condition in which the method should retry. For example, if you want to retry only if a specific exception was thrown.

If the callback you implement throws an exception, the retry method will catch that and if it still has more attempts, it will retry, otherwise it will throw that exception. On the other hand, if your callback is successful, the retry method will return the value your callback returned. Very straightforward, huh?

Ok, now that you have an overview of how it works, let's see some code. As an example, let's create a function that gives you three chances of guessing a random number:

function guessTheNumber($num) {
    $value = rand(0, 10);
    if ($value === $num) {
        return true;
    }
    throw new \Exception('You guessed the wrong number!');
}

function tryYourLuck() {
    return retry(3, function() {
        return guessTheNumber(5);
    }, 100);
}

The first function (guessTheNumber) accepts a value and compares it to a random one. If they are equal, return true, otherwise throw an exception. It is just a silly example to show how retry works. The second function (tryYourLuck) is where we call guessTheNumber with our guessed value (5) and since we have three chances, we call retry with 3 as the first parameter. Just to show you how it works, I'm also passing a third parameter to retry which is the amount of milliseconds the function should wait before retrying. Now, if we call tryYourLuck and it guessTheNumber returns true in any of the three attempts, tryYourLuck will also return true. But, if it retries three times and all of them threw an exception, then tryYourLuck will throw the last exception.

The feature that really helped me was the option to pass a closure as the fourth argument and use that to decide if we the method should retry. The closure accepts the exception as its first parameter, so we can do something like:

class MyException extends Exception { }

function guessTheNumber($num) {
    $value = rand(0, 10);
    if ($value === $num) {
        return true;
    }
    throw new MyException('You guessed the wrong number!');
}

function tryYourLuck() {
    return retry(3, function() {
        return guessTheNumber(5);
    }, 100, function($exception) {
        return $exception instanceof MyException;
    });
}

Here we are telling the retry method that it should only retry if the exception if caught was MyException. If it catches any other exception, it should not retry at all.

And with that, I wrap up this blog post. Until next time!

Build validation that you can be proud of in Laravel

David Berri — Sun, 08 May 2022 13:22:00 +0000

Today I wanted to bring you the topic of validation in the backend using Laravel. For me, this is part of what makes this framework so elegant and fluent. Even though it allows you validate your input data using multiple approaches, it gives you guard rails to ensure that it will work well and will stay organized as your application grows.

Let's jump into the code. I created a starter project that you can use to follow along. Just clone the repo from here. It's a simple CRUD project with a Rest API to show, store, update and remove bird sightings from the application. Currently it doesn't have any validation at all. Whatever it receives from the clients, it will try to store or update in the database, which is can be very bad even if you have validation on the client code. Let's start fixing that with Form Requests.

Form Requests

To be honest, if you have only a couple of rules, you might not need a Form Request, you can just validate the request inside the controller method like:

// app/Http/Controllers/BurdSightingController.php

public function create(Request $request)
{
    $request->validate([
        'common_name' => 'required|string|max:255',
    ]);

    $sighting = BirdSighting::create($request->validated());
    return response()->json($sighting, 201);
}

But if you want a cleaner interface with the controller and a special place where all the validation happens, then you can create a FormRequest using an artisan command:

php artisan make:request CreateBirdSightingRequest

This will create the following file:

// app/Http/Requests/CreateBirdSightingRequest.php

class CreateBirdSightingRequest extends FormRequest
{
    public function authorize()
    {
        return false;
    }

    public function rules()
    {
        return [
            //
        ];
    }
}

The authorize method can be used to determined if the current user is authorized to perform that operation, so you can, for example, make use of Gates and Policies or even simpler rules like if the user has a specific property. Make sure to return a boolean in that method: true means that the user is authorized and false means the user is not authorized and will respond with a 403 HTTP status response.

The rules method is where the actual validation rules go. Laravel has dozens of built-in validation rules to add here. So, in our case, we want to validate fields in order to create a bird sighting:

    public function rules()
    {
        return [
            'common_name' => 'required|string|max:255',
            'species' => 'required|string|max:255',
            'sighted_at' => 'required|date',
            'quantity' => 'nullable|integer|min:1',
            'latitude' => 'required|numeric',
                        'longitude' => ['required', 'numeric'],
        ];
    }

You will notice that for longitude I used a different syntax. Laravel supports both strings with rules a separated by |and arrays with rules are separated by commas. As far as I know, the string syntax can only be used with built-in rules. If you create a custom validation rule (and I'll show you how) then you have to use the array syntax.

Custom validation messages

Form Requests also allow you to add custom validation messages for each field and rule. TO do that you need to override the messages method in the Form Request you created, for example:

    public function messages()
    {
        return [
            'common_name.required' => 'A common name for the bird you saw is required',
            'sighted_at.required' => 'An approximate date and time for the sighting is required',
        ];
    }

These messages will override the default validation message for the required rule which you can find in resources/lang/validation.php.

Finally, you have to use this Form Request in your method, so go back to the controller and replace Request $requestwith CreateBirdSightingRequest $request

    public function create(CreateBirdSightingRequest $request)
    {
        $sighting = BirdSighting::create($request->validated());
        return response()->json($sighting, 201);
    }

You will also notice that we replaced $request->all() with $request->validated() to retrieve the validated fields from the request.

Now if you send data to that endpoint and it does not conform to the rules you added, you'll get a 422 HTTP status response with the error messages for each field.

Organizing rules

Now you will need another form request for the update method which might have a different set of rules and speaking of set of rules, when the application starts to grow and rules start to get too "scattered" in the form request, we can create rule classes that make those sets reusable and more legible. I like to create a Rules directory inside app/ and create a class that will provide the rules I need:

// app/BirdSightingRules.php

class BirdSightingRules
{
    public static function birdRules()
    {
        return [
            'common_name' => 'required|string|max:255',
            'species' => 'required|string|max:255',
            'quantity' => 'nullable|integer|min:1',
        ];
    }

    public static function locationRules()
    {
        return [
            'sighted_at' => 'required|date',
            'latitude' => 'required|numeric',
            'longitude' => ['required', 'numeric'],
        ];
    }

    public static function updateRules()
    {
        return [
            // 
        ];
    }
}

Then back in the form request:

    public function rules()
    {
        return array_merge(
            BirdSightingRules::birdRules(),
            BirdSightingRules::locationRules()
        );
    }

Custom rules

Laravel has so many built-in rules that it might take some time for you to need to build a custom rule, but sometimes your application might just have a specific trait that requires a custom validation rule. If that's the case, artisan has you covered:

php artisan make:rule SightedInMarch

It will create a file under app/Rules which contains a custom rule with the following methods:

// app/Rules/SightedInMarch.php

class SightedInMarch implements Rule
{
    public function passes($attribute, $value)
    {
        //
    }

    public function message()
    {
        return 'The validation error message.';
    }
}

Inside the passes method you can create your custom rule which needs to return a boolean and inside message you just need to return a string with an explanation of why it failed the validation:

    public function passes($attribute, $value)
    {
        return preg_match('/^[0-9]{4}-03-[0-9]{2}/', $value);
    }

    public function message()
    {
        return 'Why are you watching birds in March?';
    }

Then you go back to you set of rules and use this custom rule with the sighted_at attribute:

// app/Rules/BirdSightingRules.php

    public static function locationRules()
    {
        return [
            'sighted_at' => ['required', 'date', new SightedInMarch],
            'latitude' => 'required|numeric',
            'longitude' => ['required', 'numeric'],
        ];
    }

Now all form requests that use locationRules will automatically validate the sighted_at attribute using that new custom rule. And with that, we wrap another article. See you on the next one!

How this pattern made me write reusable Vue components with little effort

David Berri — Sat, 07 May 2022 18:54:37 +0000

A long time ago, when I started to learn Vue.js, I reached out to people who were experienced in the framework to ask for tips and get directions on what to learn and how to structure code. One tip that stuck with me was: "Always separate the logic from the presentational component”. I thought, well that seems reasonable, I'll try that. But to be honest, at that time, I did not actually understand what they meant specifically. So, with time, I wrote more and more Vue code, and got to write large SPAs until I finally understood why people told me to separate logic from the presentational layer, and most importantly, I found a great pattern that solves that problem.

Let's say you have a Vue SFC (single file component) which sends a request to the server, stores the items in state (like VueX or Pinia) and then renders a list of items. More experienced developers might already see the problem just by reading that sentence, but I took me some time. I started to have problems writing components like this because when you create unit tests for these components you have to mock so many things: the request to the server, the response, the state... the same thing happens if you want to add the component to a component library like Storybook. It's a pain. Now, if the component only take the list of items to render, render them and emit events, your life becomes a lot easier because you can test only the interface of the component i.e. if it renders x when you pass x as a prop and it emits event y when you interact in some way with the component.

The same thing happens with the logic you took away from the presentational component. When you want to test it, you can test just the bits that are important to the logic. You don't need to worry about how or who is going to render what. You just care about the functions and the flow of data.

Did I peak your interest? Ok, great! Let's see some code. I created a repo with a starter project so that you can follow along, you can clone the repo here.

To reach the point of that starter project you can run npm init vue@latest and when asked to “Add Pinia for state management” you select "Yes". After it finishes, go to the project directory and install the dependencies (npm install) and then you can run the project (npm run dev). Even though this is a Vue 3 example, I already applied this same pattern in Vue 2 and it works the same (and it will probably work the same in any other frontend framework).

If you cloned the repository, open it in your code editor and you should see a very simple example:

// src/components/PetList.vue
<script setup>
import { storeToRefs } from 'pinia'
import { onMounted } from 'vue';
import { usePets } from '../stores/pets'

const store = usePets();
const { pets } = storeToRefs(store)

onMounted(() => {
    store.fetchCats();
})

const emit = defineEmits(['click']);

function handleClick(index) {
    emit('click', index);
}

defineExpose({
    pets,
    handleClick
})
</script>

<template>
  <ul>
      <li v-for="(pet, i) in pets">
          <button @click="handleClick(i)">
              <img :src="pet" />
          </button>
      </li>
  </ul>
</template>

First, don't worry about the template style or anything like that. Let's focus on the script tag first:

the App.vue file only renders a PetList component and this Vue component basically renders an image list, but in the script part, it sends a request to an API through Pinia when the component is mounted, which returns a list of cat images and uses the state to get this list and finally expose them to the template to render.

This is the store:

// src/stores/pets.js
import { defineStore } from 'pinia';

export const usePets = defineStore('pets', {
    state: () => {
        return {
            pets: [],
        };
    },

    actions: {
        async fetchCats() {
            try {
                const cats = await fetch(
                    '<https://api.thecatapi.com/v1/images/search?limit=10&order=DESC>'
                ).then(res => res.json());
                this.pets = cats.map(cat => cat.url);
            } catch (e) {
                //
            }
        },
        }
})

What happens if later the business wants to render another list but this time with images of dogs?

Well, one option would be to copy the entire component, replace the logic to fetch and render dogs and call it a day. You still would have problems to test the component and now if something changes in the template, you have to change in both components. You won't forget it, right?

Another option would be to pass a prop to the component which works as a flag: catOrDog and based on this prop you could use if/else everywhere to render cat or dog images. You keep the template in one place but honestly the script might becomes very messy and full of “this vs that” paths.

Enter "Container/Presentational pattern" 🎉

As its name suggest, this pattern will allow us to separate the presentational component from the business logic, encouraging separation of concerns. The container can fetch, handle and modify the data that will be shown to the user. Their responsibility is to pass that data (which they contain) to a presentational component. The presentational component will actually display (present) that data to the user.

Let's refactor this code to use containers for the logic and keep the presentational component (the template) very clean and with a clear interface of props and events:

// src/components/PetList.vue
<script setup>
const props = defineProps({
  pets: {
    type: Array,
    default: () => [],
  }
});

const emit = defineEmits(['click']);

function handleClick(index) {
    emit('click', index);
}

defineExpose({
    pets: props.pets,
    handleClick
})
</script>

<template>
  <ul class="pet-list">
      <li v-for="(pet, i) in pets">
          <button @click="handleClick(i)" class="pet-list__button">
              <img :src="pet" class="pet-list__img" />
          </button>
      </li>
  </ul>
</template>

Notice that the template part almost didn't change. The script part on the other hand is a lot simpler: you define props and events that the component might emit and that's it. If your pass cat images it will render cat images, if you pass dog images it will render dog images. If in the future the business decides to render a list for an entire zoo, you're covered. Component unit tests become a breeze and you can add the component to Storybook or other component libraries very easily.

Now, let's create a container for the CatList:

// src/components/CatList.container.js
import { storeToRefs } from 'pinia';
import { onMounted, h } from 'vue';
import { usePets } from '../stores/pets';
import PetList from './PetList.vue';

export default {
    setup() {
        const store = usePets();
        const { cats } = storeToRefs(store);

        onMounted(() => {
            store.fetchCats();
        });

        function handleOnClick(index) {
            console.log('Clicked on cat picture #' + index);
        }

        return () =>
            h(PetList, {
                pets: cats.value,
                onClick: handleOnClick,
            });
    },
};

This container is responsible for fetching the cat images when it is mounted, get the images from state and render the PetList SFC component passing the list as a prop. It also listens for events that the PetList component might emit and handles them.

I like to use a convention for naming containers: [Name of the component].container.js so I know what to expect when I'm working on these files.

Now, in your App.vue, instead of importing PetList.vue you will have to import CatList.container.js and render that just like you render a regular Vue component. For any purposes, it is a regular Vue component, but instead of rendering a template, it returns an h function which actually renders the component.

Now, let's create the DogList container:

// src/components/DogList.container.js
import { storeToRefs } from 'pinia';
import { onMounted, h } from 'vue';
import { usePets } from '../stores/pets';
import PetList from './PetList.vue';

export default {
    setup() {
        const store = usePets();
        const { dogs } = storeToRefs(store);

        onMounted(() => {
            store.fetchDogs();
        });

        function handleOnClick(index) {
            console.log('Clicked on dog picture #' + index);
        }

        return () =>
            h(PetList, {
                pets: dogs.value,
                onClick: handleOnClick,
            });
    },
};

Notice that this almost identical to CatList.container but instead of fetchCats it calls fetchDogs in the onMountedhook. This is just a simple example, in the wild the logic inside these containers can vary a lot but the important part is that your PetList.vue is still the same. It still accepts the same props and as long as other containers respect this interface, it should render a nice list of images.

That's it for today! I hope that with this article you now have a better understanding of this pattern and can take a "shortcut" with this knowledge so you don't go into the same pitfalls I went :)

Formatting numbers in JavaScript

David Berri — Wed, 03 Nov 2021 09:00:00 +0000

In the last couple of posts, I showed you how you can format dates and relative dates using the native Internationalization API. Today, I'll we're going to format regular numbers using the same API. Yes, Intl is not only used for date formatting, there's a whole range of use cases including numbers, lists and plurals.

So, when I say we are going to format numbers, what I mean is: numbers are not represented the same way in different cultures. For example, in Brazil we the most common way to represent numbers is like so: 1.234.567,89. The comma is the decimal separator and the period is the thousands separators. In other cultures those are switched, or the thousands separator is not used. If your application is served in other locales, you can use the Intl API to resolve these for you and you don't even need to plug in another dependency.

Let's see how we can use it:

const myNumber = 1234657.89;

const formatter = new Intl.NumberFormat('pt-BR');

console.log(formatter.format(myNumber)); // 1.234.567,89

const formatterUS = new Intl.NumberFormat('en-US');

console.log(formatter.format(myNumber)); // 1,234,567.89

If you've read the previous posts, you'll probably be familiar with the syntax. You first instantiate the formatter with the locale and then pass the parameters you want to format. Of course, you can also pass an options object to the formatter if you want to further customize the number format. Let check out a few options:

const myNumber = 1234567.89;

let formatter = new Intl.NumberFormat('pt-BR', {
    style: 'currency',
    currency: 'BRL'
});
console.log(formatter.format(myNumber)); // R$ 1.234.567,89

formatter = new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD'
});
console.log(formatter.format(myNumber)); // $ 1,234,567.89

formatter = new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD',
    currencyDisplay: 'code' // default: 'symbol'
});
console.log(formatter.format(myNumber)); // USD 1,234,567.89

formatter = new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD',
    currencyDisplay: 'name'
});
console.log(formatter.format(myNumber)); // 1,234,567.89 US dollars

There are also options to customize the way it displays negative values, for example instead of using $ -1.00 it can display ($1.00):

const myNumber = -1234567.89; // notice the negative sign
const formatter = new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD',
    currencySign: 'accounting'
});
console.log(formatter.format(myNumber)); // ($1,234,567.89)

And, if you are working with currencies or percentages, the number of fraction digits is already set using ISO 4217, but if you're working with regular numbers, you can set that option too:

const myNumber = 1234567.00;
formatter = new Intl.NumberFormat('en-US');
console.log(formatter.format(myNumber)); // 1,234,567

formatter = new Intl.NumberFormat('en-US', {
    minimumFractionDigits: 2
});
console.log(formatter.format(myNumber)); // 1,234,567.00

formatter = new Intl.NumberFormat('en-US', {
    maximumFractionDigits: 3
});
const myNumber2 = 1234567.891011
console.log(formatter.format(myNumber2)); // 1,234,567.891

You can customize the notation as well:

formatter = new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD',
    notation: 'standard' // default
});
console.log(formatter.format(myNumber)); // $1,234,567.89

formatter = new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD',
    notation: 'scientific'
});
console.log(formatter.format(myNumber)); // $1,23E6

formatter = new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD',
    notation: 'engineering'
});
console.log(formatter.format(myNumber)); // $1,23E6

formatter = new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD',
    notation: 'compact'
});
console.log(formatter.format(myNumber)); // $1.2M

There are still plenty of options we did not cover but I think the most popular ones are those in the examples, but if you can check out the full list here. And this is it for this post. See you on the next one!

How to format relative dates using native JavaScript

David Berri — Tue, 02 Nov 2021 08:30:00 +0000

In the previous post, I showed you how you can leverage the Internationalization API to format dates using the user's locale. In this post, I'll show you how you can use the same API to create relative dates.

Relative dates are very common in applications where you want show the user the amount of time that has passed or will pass until something happens rather than the specific date and time when something happened. For example, instead of showing that a post was published on 01/11/2021, or Nov 1st, 2021, you can show: "published yesterday" or "published 1 day ago" or if it's in the future: "this post will be published in 2 days". All of this can be achieved with the Intl API, although you might need to check browser support because this feature is relatively new.

To create the relative date formatter, you need to pass two arguments: the locale and an object with options:

const formatter = new Intl.RelativeTimeFormat('en-US', {
    numeric: 'always',
    style: 'long'
})

And to actually format a date you need to pass the number which represents the relative difference (this can be positive for the future and negative for the past) and the "unit" you want your output to be displayed ("day", "month", etc...):

formatter.format(1, "day") // "in 1 day"
formatter.format(-2, "month") // "2 months ago"
formatter.format(4, "year") // "in 4 years"
formatter.format(5, "hour") // "in 5 hours"

You can also use the option: numeric: auto for a more "natural" language:

const formatter = new Intl.RelativeTimeFormat('en-US', {
    numeric: 'auto',
})

formatter.format(1, "day") // "tomorrow"
formatter.format(-1, "day") // "yesterday"
formatter.format(-1, "month") // "last month"
formatter.format(1, "year") // "next year"

An then there's the short and narrow options for style (which can be similar depending on the locale):

let formatter = new Intl.RelativeTimeFormat('en-US', {
    style: 'short',
})

formatter.format(-2, "month") // "2 mo. ago"
formatter.format(4, "year") // "in 4 yr."

formatter = new Intl.RelativeTimeFormat('en-US', {
    style: 'narrow',
})

formatter.format(-2, "month") // "2 mo. ago"
formatter.format(4, "year") // "in 4 yr."
formatter.format(-2, "minute") // "2 min. ago"

And that's it for the relative date formatter. Of course, you still have to do some of the "heavy lifting" of coming up with the date difference, but that can be as simple as:

const diff = new Date(2021, 9, 10) - new Date();
const seconds = diff / 1000; // -1937124.765
const minutes = seconds / 60; // -5158.739066666666
const hours = minutes / 60; // -85.97898444444444

const formatter = new Intl.RelativeTimeFormat('en-US', {
    numeric: 'auto',
})

formatter.format(hours, 'hour'); // 85.979 hours ago

Which you can then round or improve as per your application's requirements.

Ok, that's it for relative date formatting using the Intl API. See you on the next post!

Formatting dates in JavaScript using the user's locale

David Berri — Mon, 01 Nov 2021 12:12:42 +0000

Currently, there are multiple libraries to format dates in JavaScript. I used moment.js for a long time, but the bundle size was always a turn down for me. Then I switched to date-fns, which has a simple API and supports tree-shaking, and I have one project where I'm using luxon. They all work fine and have their use-cases, but in my opinion some times we end up bringing external libraries into our projects without really needing them, or without checking for a native approach first. I am guilty of that 😉 but lately I've tried to always search for a native approach first, before bringing in a dependency, making sure to assess whether the bigger bundle size is worth it or not.

So, let's get into it. What I want to show you is a simple use case where we need to format dates differently depending on user locale. In Brazil, the most common date format is DD/MM/YYYY or DD/MM/YY where D = Day, M = Month and Y= Year. In the US, day and month switch places and sometimes you don't add the leading zero and in Germany, it's common to use dots instead of slashes as dividers (DD.MM.YYYY). To make sure we account for all these formats, we can leverage ECMAScript Internationalization API in our application.

Let me show you an example:

const myDate = new Date(2021, 10, 1);
let formatter = new Intl.DateTimeFormat('en-US');
console.log(formatter.format(myDate)) // "11/1/2021"

formatter = new Intl.DateTimeFormat('pt-BR');
console.log(formatter.format(myDate)) // "01/11/2021"

formatter = new Intl.DateTimeFormat('de-DE');
console.log(formatter.format(myDate)) // "1.11.2021"

You can also do it with a one-liner if you are not going to use the formatter later:

const myDate = new Date(2021, 10, 1);
console.log(new Intl.DateTimeFormat('pt-BR').format(myDate)) // "01/11/2021"

Now, instead of hard coding the language code, you can either use the user's preferred language (from the browser) or your the language the user set for your website:

const myDate = new Date(2021, 10, 1);
const langCode = document.documentElement.lang || navigator.language;
const formatter = new Intl.DateTimeFormat(langCode);
console.log(formatter.format(myDate)) // "01/11/2021"

You can also specify options for the date format:

const myDate = new Date(2021, 10, 1);
const formattedDate = new Intl.DateTimeFormat('en-US', {
    dateStyle: 'short',
    timeStyle: 'short'
}).format(myDate);
console.log(formattedDate) // "11/1/21, 12:00 AM"

const formattedDateMedium = new Intl.DateTimeFormat('en-US', {
    dateStyle: 'medium',
    timeStyle: 'medium'
}).format(myDate);
console.log(formattedDateMedium) // "Nov 1, 2021, 12:00:00 AM"

const formattedDateLong = new Intl.DateTimeFormat('en-US', {
    dateStyle: 'long',
    timeStyle: 'long'
}).format(myDate);
console.log(formattedDateLong) // "November 1, 2021 at 12:00:00 AM GMT-3"

const formattedDateFull = new Intl.DateTimeFormat('en-US', {
    dateStyle: 'full',
    timeStyle: 'full'
}).format(myDate);
console.log(formattedDateFull) // "Monday, November 1, 2021 at 12:00:00 AM Brasilia Standard Time"

The options are very flexible: you can set different formats for calendar, week, year (2-digit or numeric), month (numeric, 2-digit, long, short and narrow), weekday, wheter to use the 12-hour time, timezone. You can checkout the full list here.

I hope that after reading this post you will be better equipped to make a decision on whether or not you need an external library for handling date formatting. See you on the next post!

Useful JavaScript array methods

David Berri — Mon, 02 Aug 2021 12:35:14 +0000

Let's walk through the array methods I find more useful and that I use on a daily basis. Each of these methods has their own use case, and even though you can achieve the same results using a combination of a for loop and a few auxiliary variables, understanding them and using them where appropriate will make your code a lot more readable and simpler.

forEach

The first one we'll talk about is the forEach. This one resembles a for loop the most, but you can call it directly on a an array and have the each item of the array passed to the callback along with the current index. In other words, it will execute the provided function once for each element. For example:

['cat', 'dog', 'fish'].forEach((animal, index) => {
    console.log([index, animal]);
})
// [0, 'cat']
// [1, 'dog']
// [2, 'fish']

You can also create the function to be executed, beforehand and pass it to the method (the same applies to all the other array methods:

function printIndexAndAnimal(index, animal) {
    console.log([index, animal]);
}

['cat', 'dog', 'fish'].forEach((animal, index) => printIndexAndAnimal(index, animal))

Also useful to note is that the forEach method (and all the other methods mentioned in this article) also passes the array itself as the third argument in the callback.

filter

This is a very handy method and I think I use it almost everyday. Like the name suggests, you can use it to filter an array, and it outputs another array with the elements that pass the test you provide in the callback function. For example, if you have an array of numbers, you can create another array with only the numbers that are greater than a threshold. Or if you have an array of objects that contain an id, you can create another array that does not contain an element with a specific id using filter. E.g.

const filteredArray = [1, 2, 3].filter(element => element > 1);

console.log(filteredArray)
// [2, 3]

const products = [
    { id: 1, name: 'Computer' },
    { id: 2, name: 'Pen' },
    { id: 3, name: 'Guitar' },
]

const filteredProducts = products.filter(product => product.id !== 2)

console.log(filteredProducts)
// [{ id: 1, name: 'Computer' }, { id: 3, name: 'Guitar' }]

find

You can use this method when you want to find one element in an array that satisfy a test function. This method will return either the first element that matches that test function otherwise it will return undefined.

const products = [
    { id: 1, name: 'Computer' },
    { id: 2, name: 'Pen' },
    { id: 3, name: 'Guitar' },
]

const pen = products.find(product => product.id === 2)

console.log(pen)
// { id: 2, name: 'Pen' }

const cat = products.find(product => product.id === 'cat')
console.log(cat)
// undefined

some

This method returns either true or false if at least one element in the array matches a provided test function. It's useful when you want to make sure that at least one of the elements in the array satisfy a condition but you don't really want to manipulate that element or filter it out of the array:

function hasOneCat(element) {
    return element === 'cat';
}

cosnt hasCat = ['fish', 'cat', 'dog'].some(animal => hasOneCat(animal))
console.log(hasCat)
// true

cosnt hasCat = ['fish', 'tiger', 'dog'].some(animal => hasOneCat(animal))
console.log(hasCat)
// false

every

This one behaves similarly to some but in order to return true, all elements in the array must satisfy the condition in the test function:

function isAboveFreezingCelsius(temperature) {
    return temperature > 0;
}

cosnt allElementsAreAboveFreezing = [10, 2, 1, 3, 5, 100].every(temp => isAboveFreezingCelsius(temp))
console.log(allElementsAreAboveFreezing)
// true

cosnt hasCat = [0, 1, 8, 10, -1].every(temp => isAboveFreezingCelsius(temp))
console.log(allElementsAreAboveFreezing)
// false

map

This is another method I use almost everyday and it's very useful when you want to manipulate items in the array and return another array in which the function has been applied. One use case could be convert every element in an array to a different format and output that to a different variable without changing the original array:

function fromFahrenheitToCelsius(temperature) {
    return (temperature - 32) / (9/5) 
}

const converted = [212, 98.6, 32, 0, -40].map(temp => fromFahrenheitToCelsius(temp))
console.log(converted)
// [100, 37, 0, -17.78, -40]

reduce

Reduce is a little more complicated than the others. You can manipulate the array in a deeper level. I like to think of it as a mix of filter and map on the same method, but this can be used for so much more. You can use reduce to create another array with filtered and converted elements or you can even use it to reduce an array of numbers into a single result. When using reduce, not only you provide a function (called reducer) but you can also provide an initial value. Reduce's callback provides the current value in the itereation and an accumulator. The result of your function is assigned to the accumulator which carries on to the next iteration.

Let's start with a simple example, summing an array:

cosnt initialValue = 0;
cosnt result = [1, 2, 3, 4, 5].reduce((accumulator, currentValue) => {
    accumulator += currentValue
    return accumulator;
}, initialValue);
console.log(result);
// 15

Now, on to a more complex one. Let's split an array into two groups removing duplicates using reduce:

const originalArray = [2, 2, 43, 5, 11, 7, 9, 4, 20, 0, 4];
const initialValue = { lessThanTen: [], greaterThanTen };

function reducer(acc, value) {
    if (acc.lessThanTen.includes(value) || acc.greaterThanTen.includes(value)) {
        return acc;
    }

    if (value < 10) {
        acc.lessThanTen.push(value);
    } else {
        acc.greaterThanTen.push(value);
    }
    return acc;
}

const result = originalArray.reduce((acc, value) => reducer(acc, value))
console.log(result)
// { lessThanTen: [2, 5, 7, 9, 4, 0], greaterThanTen: [43, 11, 20] }

I hope this article gave you a better idea of how all these methods work and after some practice you will have more tools on your belt and can help you improve your code's readability and performance. The best part about these methods is that besides the language syntax, the logic works the same in other languages, not only JavaScript :)

Destructuring Assignment in JavaScript

David Berri — Fri, 04 Jun 2021 14:16:04 +0000

Today, I wanted to bring you one of my favorite modern JavaScript features: Destructuring Assignment! I use it almost everyday because it is so helpful in so many situations. So, let's get started. The destructuring assingment is an expression that allows you to extract values from arrays and properties from object into variables. To give you a very simple example:

const obj = { a: 1, b: 2 }
const { a } = obj
console.log(a) // 1

const arr = [1, 2]
const [firstValue, secondValue] = arr
console.log(firstValue) // 1
console.log(secondValue) // 2

In the first example, we define an object with properties "a" and "b" and in the second line we use destructuring assignment to extract property "a" into a variable with the same name. In the second example we do something similar with an array. We define a new variable called "firstValue" which holds the value in the first position in the array and "secondValue" for the value in the second position. It's the equivalent of doing:

const arr = [1, 2]
const firstValue = arr[0]
const secondValue = arr[1]
console.log(firstValue) // 1
console.log(secondValue) // 2

By default, when destructuring an object you use the name of the property, but you can also rename it in the same expression if you need:

const obj = { language: 'JavaScript' }
const { language: lang } = obj
console.log(lang) // 'JavaScript'

We extract the "language" property from the object but define a variable "lang" to hold its value.

You can also combine the destructuring assignment with the spread operator (another favorite of mine) to hold multiple values like this:

const arr = [1, 2, 3, 4]
const [firstValue, secondValue, ...rest] = arr
console.log(rest) // [3, 4]

When destructuring arrays, you have to pay attention to the order of variables. In the code snippet above, firstValue holds the value in the first position of arr, secondValue holds the value in the second position and rest holds all the other values. Knowing this, how can we ignore one value if we need the value in position one and the value in position three? Simple:

const arr = [1, 2, 3, 4]
const [firstValue, , thirdValue] = arr
console.log(firstValue) // 1
console.log(thirdValue) // 3

I tend to use object destructuring more often to get a nested value inside an API response object, for example:

const response = {
    data: {
        user: {
            name: "David",
        }
    }
}

// instead of
const name = response.data.user.name

// you can do
const { name } = response.data.user

Let's say you have a promise called fetchUser that returns that same response object in the code snippet above but you only need "name" of the user which is nested deep inside the response, you can do something like this:

const { data: { user: { name } } } = await fetchUser()

In this snippet, the only constant that will be declared is name which is useful when you only want part of the object returned by the function. If you want to use the same expression for function parameters, you can:

fetchUser().then(({ data: { user: { name } } }) => name)

Or you can define a function that destructures it's arguments, so you can pass the full object to the function call:

const user = {
    name: "David"
}

function printName({ name }) {
    console.log(name)
}

printName(user) // 'David'

Another cool use case for destructuring arrays is swapping variables in a one liner:

let a = 1
let b = 2

[a, b] = [b, a]

One last thing I want to show you is that you can give these variables a default value if, for example, the extracted value is undefined:

const arr = [1]
const [first, second = 2] = arr;
console.log(first) // 1
console.log(second) // 2

const obj = { a: '1' }
const { a, b = '2' } = obj
console.log(a) // '1'
console.log(b) // '2'

And that's a wrap for today. I hope you can see now how helpful this JavaScript expression is, and can incorporate in your day to day coding :) If you have any questions, reach out to me 👋

The different ways to do routing in Laravel

David Berri — Thu, 03 Jun 2021 13:42:01 +0000

Routing in Laravel is very flexible. You can define the routes to your app in so many ways, with so many modifiers, each with a different purpose or better suited to a specific use case. Today, I want to show you a few ways that helped me and that I use very frequently while working with Laravel.

The most basic one, is the first one shown in the documentation:

use Illuminate\Support\Facades\Route;

Route::get('/greeting', function () {
    return 'Hello World';
});

This uses a closure and means that when a user hits navigates to [your app host]/greeting they will be greeted with a simple "Hello World" string. Technically, you can implement your entire application in this closure. Nothing will stop you if you try to add all your bussiness logic in there, but of course that's not very effective and if you have more routes it becomes very ugly.

When you just create a new Laravel application, it already comes with one basic route defined for / which looks like this:

use Illuminate\Support\Facades\Route;

Route::get('/', function () {
    return view('welcome');
});

This is a more elaborate version of the first one, but in this case, it is going to return a view. This view is a Blade file located in resources/views which is named welcome.blade.php. So, now you can start composing views using blade and if there's not much going on in your view (e.g. it's a static page) you don't need to create a controller just to return a view.

Speaking of controllers, there are a few ways you can point your route to a controller or controller method. The default way that appears in the documentation looks like this:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\UserController;

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

When a request hits /user the method "index" in the UserController class will be called. Previously, I used to define routes with a different syntax (which as far as I know is still valid and working in Laravel 8:

use Illuminate\Support\Facades\Route;

Route::get('/user', 'UserController@index');

Notice that it's the same controller and method, but instead of an array, you pass a string declaring the controller and method separated by a @ symbol. Another thing you'll notice is that we don't need the use statement for this class because Laravel will automatically try to find that the UserController class in the App\Http\Controllers namespace. Even though this works the same way as the previous example, I prefer the previous one because the it comes with some IDE niceties, like clicking on a class and navigating to its definition, or if you move the class file to another directory, it will warn you the use statement is not valid anymore.

Just a quick and related note, you can do the same with model relationships:

class User {
    public function books() {
        return $this->hasMany('Book');
    }
}

use App\Book;

class User {
    public function books() {
        return $this->hasMany(Book::class);
    }
}

Invocable controllers

Now, if your controller is a little complex and you use it for a single action with the __invoke method, you don't need to pass an array with controller and method to the route declaration, you can just pass the class as an argument, like this:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\UserController;

Route::get('/user', UserController::class);

Resource routes

You can also do a similar route declaration with resource controllers. This type of controller is that classic "CRUD" class, where you have index, show, create, store, edit, update, and destroy methods. Then you can define the route to this controller like this:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\UserController;

Route::resource('users', UserController::class);

This will create a route for each of the controller methods and will name them, just like if you had created them manually following this pattern:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\UserController;

Route::get('/users', [UserController::class, 'index'])->name('users.index');
Route::get('/users/{user}', [UserController::class, 'show'])->name('users.show');
Route::get('/users/create', [UserController::class, 'create'])->name('users.create');
Route::post('/users', [UserController::class, 'store')->name('users.store');
Route::get('/users/{user}/edit', [UserController::class, 'edit'])->name('users.edit');
Route::patch('/users/{user}', [UserController::class, 'update'])->name('users.update');
Route::delete('/users/{user}', [UserController::class, 'destroy'])->name('users.destroy');

And if you don't want a few of those routes you can tell the resource method which ones you don't need:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\UserController;

Route::resource('users', UserController::class)->except(['edit', 'udpate']);

Or the other way around, if you only need a few routes:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\UserController;

Route::resource('users', UserController::class)->only(['index', 'show']);

And finally, if you are developing an API, you probably don't need the create and edit routes which usually navigate the user to a form. If that's the case, you can define the routes like this:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\UserController;

Route::apiResource('users', UserController::class);

There is also a plural form of each one of these two methods, if you want to define multiple resource controllers:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\UserController;
use App\Http\Controllers\BookController;

Route::resources([
    'users' => UserController::class
    'books' => BookController::class
]);

// or

Route::apiResources([
    'users' => UserController::class
    'books' => BookController::class
]);

One last case we can cover is nested resources. For example, if you want to update a specific book of a specific user, you could define the route as:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\UserBookController;

Route::update('/users/{user}/books/{book}', [UserBookController::class, 'update']);

Or, using the resource syntax:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\UserBookController;

Route::resource('users.books', UserBookController::class);

Much cleaner!

And that's it! I mean, there is a lot more to cover like middlewares, route grouping, namespaces, Route Model Binding, rate limiting, and so on. But I'll write more about those in the future. If you're curious and want to dig deeper, I suggest you dive into Laravel's documentation. See you next time 👋

How to create a toast notification with Alpine.js

David Berri — Sat, 29 May 2021 15:02:30 +0000

Today I’ll show how to create a piece of UI that comes up very often when we want to communicate the result of an action to the user: toast notifications! For those who don’t know, this is supposed to be a small message bubble/dialog that shows up for a few moments and go away and it’s commonly used to show the user the result of an action like an Ajax request. Like in other Alpine.js tutorials, we will use TailwindCSS to style it, so here’s the basic markup:

<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Alpine Toast Notification</title>
    <link href="https://unpkg.com/tailwindcss@^2/dist/tailwind.min.css” rel=“stylesheet">
    <script src="https://cdn.jsdelivr.net/gh/alpinejs/alpine@v2.x.x/dist/alpine.min.js" defer></script>
</head>
<body>
    <div x-data="toastNotification()"></div>
    <script>
        function toastNotification() {
            return {}
        }
  </script>
<body>

You probably noticed that this time we will manage Alpine.js from the script tag instead of doing it inline like we did previously. This is because we want to add a little more functionality to it and doing it inline would be a mess.

So, the idea is to have a small dialog that slides up from the bottom right corner of the screen and then slides down after a few seconds. The title, the message and the color will be customizable and we also need something to trigger it. I’ll just create a button for now, but you’ll see that you can improve it and use it in an Ajax request easily. Here’s the markup for the button:

<button x-on:click=“openToast()” class=“bg-purple-200 hover:bg-purple-300 text-purple-500 rounded px-6 py-4 m-4”>Open Toast</button>

With this, we know that we will need an openToast inside our toastNotification object which will be called when clicking the button (x-on:click). If you are using it with Ajax, you would call this function after the request was finished.

The toast notification itself will have this markup:

<div
    x-show="open"
    class="w-96 p-4 rounded h-32 fixed bottom-4 right-4 transform-gpu transition-transform duration-400 ease"
    x-class="success ? 'bg-green-500' : 'bg-red-500'"
    x-transition:enter-start="translate-y-full"
    x-transition:enter-end="translate-y-0"
    x-transition:leave-start="translate-y-0"
    x-transition:leave-end="translate-y-full"
    >
    <p class="text-white"><strong x-text="title"></strong></p>
    <p class="mt-2 text-sm text-white" x-text="message"></p>
</div>

Remember that the notification and the button markup must go inside the div that declares x-data="toastNotification()" otherwise it won’t work.

Let’s go step by step:

x-show="open": This means that we will need a variable called open which will be a boolean and when it's true, the notification is open, and when it's false the notification will be closed.

There's nothing too interesting about the classes, but notice that we're using fixed which positions the div fixed in relation to the viewport. Then we use bottom-4 and right-4 to make it stick to the bottom right of the screen with a little margin. We also define a dynamic class using x-class: if a boolean variable called success is true, then it will be a green notification, otherwise it will be red.

Next, we use x-transition to declare that the toast will slide up when opening and slide down when closing.

Finally, we have two p tags that represent the notification title and the message. Both use variables to define those attributes and they are injected into the tags using x-text.

Now we can go back to our toastNotification function and defined all of these variables and functions.

function toastNotification() {
    return {
        open: false,
        title: "Toast Title",
        message: "Toast message",
        success: false,
        openToast() {
            this.open = true
            setTimeout(() => {
                this.open = false
            }, 5000)
        }
    }
}

We start with the boolean property that controls when the notificaation is open. Then we define the title and message strings which hold the data that is displayed by the notification. We then define the boolean success property which toggles the notification between green (true) and red (false). Finally we have the openToast function which sets the open property to true, opening the notification, and 5 seconds later it sets it back to false, effectivelly closing the notification.

And this is it. One could improve this little snippet by adding the possibility of changing the title, message and success properties on demand, for example after a successful update or after a failed Ajax request. Until the next post 👋

Let’s build an accessible modal with Alpine.js

David Berri — Sun, 28 Mar 2021 13:07:28 +0000

The simplest example of a modal is the one you can find in Alpine.js’ own documentation, and it is for a dropdown modal which would be like this:

<div x-data="{ open: false }">
    <button @click="open = true">Open Dropdown</button>

    <ul
        x-show="open"
        @click.away="open = false"
    >
        Dropdown Body
    </ul>
</div>

Very straight forward, you will just control the "open" state of the modal and change with the button click event. There’s also something very cool which is the "away" event modifier. That ensures that when the modal is open, if a click happens outside of the modal tree, it will hide the it. We will use these basic concepts and build a "regular" modal. As in other Alpine.js' posts, I’ll use TailwindCSS for the styling, so all you need to do is add these two lines in the <head> section of your page (just remember that it is not a purged version of TailwindCSS, so don’t really use it for production):

<link href="https://unpkg.com/tailwindcss@^2/dist/tailwind.min.css" rel="stylesheet">
<script src="https://cdn.jsdelivr.net/gh/alpinejs/alpine@v2.x.x/dist/alpine.min.js" defer></script>

Ok, now, we’re ready to start building stuff. Let’s begin by adding a container that will hold Alpine.js' state:

<div x-data="{ open: false }">
</div>

Everything that Alpine.js controls and is related to the modal will need to be inside this <div>. You can have multiple containers like this to control different aspects of the page, but they would be independent. So, inside this container, we will add a button to open the modal and the modal’s markup as well:

<div x-data="{ open: false }">
    <button x-ref="modal1_button"
            @click="open = true"
            class="w-full bg-indigo-600 px-4 py-2 border border-transparent rounded-md flex items-center justify-center text-base font-medium text-white hover:bg-indigo-700 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-indigo-500 sm:w-auto sm:inline-flex">
            Open Modal
    </button>

    <div role="dialog"
         aria-labelledby="modal1_label"
         aria-modal="true"
         tabindex="0"
         x-show="open"
         @click="open = false; $refs.modal1_button.focus()"
         @click.away="open = false; $refs.modal1_button.focus()"
         class="fixed top-0 left-0 w-full h-screen flex justify-center items-center">
        <div class="absolute top-0 left-0 w-full h-screen bg-black opacity-60"
             aria-hidden="true"
             x-show="open"></div>
        <div @click.stop=""
             x-show="open"
             class="flex flex-col rounded-lg shadow-lg overflow-hidden bg-white w-3/5 h-3/5 z-10">
          <div class="p-6 border-b">
            <h2 id="modal1_label">Header</h2>
          </div>
          <div class="p-6">
            Content
          </div>
        </div>
    </div>
</div>

This will get you a very simple modal window when you click on the "Open modal" button. No transitions, no flair, just a plain modal. Let's break down the markup:

<button data-modal-open="modal_1"
        @click="open = true"
        class="...">
  Open Modal
</button>

This is the button that will trigger the modal to open (classes ommited), other than the known @click="open = true" which you are probably familiar with, we have the x-ref="modal1_button" attribute. This is there so we can retrieve a reference to the button element and set focus to it once the modal is closed which is helpful for people who use the keyboard to navigate around the page. Onto the next part:

<div role="dialog"
     aria-labelledby="modal1_label"
     aria-modal="true"
     tabindex="0"
     x-show="open"
     @click="open = false; $refs.modal1_button.focus()"
     @click.away="open = false; $refs.modal1_button.focus()"
     class="...">
     ...
</div>

This is the modal container. You'll notice the role attribute and it's set to "dialog" which according to W3 is a way to identify the element that serves as the dialog container. Then, we have the aria-labelledby attribute, which will set the accessible name of the container to the modal title (h2 tag). Next is aria-modal attribute which tells accessibility technologies that the content underneath this dialog won't be available for interaction while it's open. x-show is probably self-explanatory and then we have $refs.modal1_button.focus() which will use the x-ref we set in the button to set focus to it once the modal is closed.

Next we have this empty div which is used as a modal backdrop, nothing special about it so we add the aria-hidden attribute which just hides this div from accessbility technologies:

<div class="absolute top-0 left-0 w-full h-screen bg-black opacity-60"
     aria-hidden="true"
     x-show="open"></div>

Then, we finally reach the modal contents:

        <div @click.stop=""
             x-show="open"
             class="...">
          <div class="p-6 border-b">
            <h2 id="modal1_label">Header</h2>
          </div>
          <div class="p-6">
            Content
          </div>
        </div>

The only important parts here are the id we set in the h2 tag, which must be equal to the one we set in aria-labelledby earlier and the stop event modifier set to the @click event. This will prevent the click event from bubbling up to the modal container, which would listen to it and close the modal.

That covers the markup, now let's tackle the animations:

<div role="dialog"
     aria-labelledby="modal1_label"
     aria-modal="true"
     tabindex="0"
     x-show="open"
     @click="open = false; $refs.modal1_button.focus()"
     @click.away="open = false"
     class="fixed top-0 left-0 w-full h-screen flex justify-center items-center">
        <div aria-hidden="true"
             class="absolute top-0 left-0 w-full h-screen bg-black transition duration-300"
             :class="{ 'opacity-60': open, 'opacity-0': !open }"
             x-show="open"
             x-transition:leave="delay-150"></div>
        <div data-modal-document
             @click.stop=""
             x-show="open"
             x-transition:enter="transition ease-out duration-300"
             x-transition:enter-start="transform scale-50 opacity-0"
             x-transition:enter-end="transform scale-100 opacity-100"
             x-transition:leave="transition ease-out duration-300"
             x-transition:leave-start="transform scale-100 opacity-100"
             x-transition:leave-end="transform scale-50 opacity-0"
             class="flex flex-col rounded-lg shadow-lg overflow-hidden bg-white w-3/5 h-3/5 z-10">
          <div class="p-6 border-b">
              <h2 id="modal1_label" x-ref="modal1_label">Header</h2>
          </div>
          <div class="p-6">
              Content
          </div>
        </div>
</div>

Here we set an opacity animation to the modal backdrop: it starts with the opacity-0 class and once the open property changes to true, it will replace opacity-0 with opacity-60. This transition is handled by the TailwindCSS classes transition duration-300 which should be self-explanatory, but if you want more details, check it out here. An interesting in this element is that we use Alpine's x-transition:leave to add a delay when closing the modal. This will make sure that the backdrop will start to fade out after the rest of the modal is already half way through its transition.

In the modal dialog itself, we use a more granular approach to transition it using various x-transition properties:

x-transition:enter will set the classes that will be will be attached to element the entire "enter" transition. So we use it to add the transition property, duration and easing.

x-transition:enter-start set the classes that define the initial state of the elements and x-transition:enter-end are the classes that defined the end state of the "enter" transition. Here we're saying that the modal should start with a 0% opacity and scaled down to 50% its size and should end with a 100% opacity and scaled up to its original size.

x-transition:leave-start and x-transition:leave-end will do the opposite of the enter transitions, so we also do the opposite with the dialog box: start from original size and 100% opacity to 50% its size and 0% opacity.

And that wraps it! If you're new to Alpine.js, check out this post and I'll see you in the next one =)

How to use Twig in Laravel

David Berri — Wed, 27 Jan 2021 21:05:44 +0000

Laravel comes bundled with its own templating engine called Blade which is very powerful and a breeze to use, but there are times when it's not the best tool for the job. In my case, I first had to replace Blade with Twig in Laravel in order to use Miyagi for component development, and that made me spend a few hours out of my comfort zone learning how to integrate it in Laravel and because of that I'll share my lessons with you.

First you need to install Twig itself and a package called TwigBridge which will allow you to seamlessly use it in Laravel. Open your terminal (who am I kidding, it's probably already open) and navigate to your application root folder, and run the following command:

composer install rcrowe/twigbridge twig/twig

After the installation is complete, you can run php artisan vendor:publish --provider="TwigBridge\ServiceProvider" which will publish the pacakge's configuration file at config/twigbridge.php. In this file you will be able to tweak a few things like which Laravel Facades are made available to Twig, as well as filters and global functions. With that, you are ready to start using Twig templates, so go ahead and create a new view inside resources/views called welcome.twig (if you don't already have one) to test that:

<!DOCTYPE html>
<html lang="{{ app.getLocale }}">
    <head>
        <!-- other regular head stuff -->
    </head>
    <body class="antialiased">
        <div class="relative flex items-top justify-center min-h-screen bg-gray-100 dark:bg-gray-900 sm:items-center sm:pt-0">        
            {% if Route.has('login') %}
                <div class="hidden fixed top-0 right-0 px-6 py-4 sm:block">
                    {% if auth_check() %}
                        <a href="{{ url('/home') }}" class="text-sm text-gray-700 underline">Home</a>
                    {% else %}
                        <a href="{{ route('login') }}" class="text-sm text-gray-700 underline">Login</a>

                        {% if Route.has('register') %}
                            <a href="{{ route('register') }}" class="ml-4 text-sm text-gray-700 underline">Register</a>
                        {% endif %}
                    {% endif %}
                </div>
            {% endif %}

            <div class="max-w-6xl mx-auto sm:px-6 lg:px-8">
                <div class="mt-8 bg-white dark:bg-gray-800 overflow-hidden shadow sm:rounded-lg">
                    <!-- irrelevant content -->

                    <div class="ml-4 text-center text-sm text-gray-500 sm:text-right sm:ml-0">
                        Laravel v{{ app.version }}
                    </div>
                </div>
            </div>
        </div>
    </body>
</html>

I adapted the original welcome.blade.php view that comes with a fresh installation to show you how it would like like when using Twig. Notice the "Route" facade is readily available but instead of using the static method call like Route::has() you use Twig's dot notation: Route.has(). Other global functions like route, url and app are also available.

If it's a fresh install of Laravel, your base route will already point to the "welcome" view, otherwise just create a route in the routes/web.php file like this:

Route::get('/', function () {
    return view('welcome');
});

Now, let's go a little bit further and use components in the application. Go ahead and create resources/views/components/navbar/navbar.twig and add this content:

<nav>
  <ul>
    <li>
      <a href="{{ url('/') }}">Home</a>
    </li>
    {% for item in items %}
      <li>
        <a href="{{ item.url }}">{{ item.label }}</a>
      </li>
    {% endfor %}
  </ul>
</nav>

and in the welcome.twig view, you can include it just after opening the body tag:

{% include "./components/navbar/navbar.twig" with {
    items: [
      {
        url: url('/nachos'),
        label: 'Nachos'
      },
      {
        url: url('/tacos'),
        label: 'Tacos'
      }
    ]
} %}

And just like that, now you're able to include, embed and extend Twig templates in Laravel. Though, the more your application grow and the more components you have, it might become unwieldy to write all those paths to components. To fight that, you can use Twig namespaces. Instead of writing ../../components/component-name.twig you can write it like this: @components/component-name.twig. All you need to do is add this snippet to the boot method in app/Providers/AppServiceProvider.php:

$loader = new \Twig\Loader\FilesystemLoader();
$loader->addPath(base_path() . '/resources/views/components', 'components');
\Twig::getLoader()->addLoader($loader);

where base_path() . '/resources/views/components' is the path to the component directory and components is how you will call it (i.e. @components). You can add multiple paths like this that point to different (or the same) directories.

If you need to add some custom functionality that is not provided by a built in filter or function, you can create it in a plain php file, something like app/Twig/Functions.php and inside you could add:

<?php

namespace App\Twig;

use Twig\Extension\AbstractExtension;
use Twig\TwigFunction;

class Functions extends AbstractExtension
{
    public function getFunctions()
    {
        return [
            new TwigFunction('now', [$this, 'now']),
        ];
    }

    public static function now()
    {
      return date('d/m/Y H:i:s');
    }
}

Then, go to config/twigbridge.php and add 'App\Twig\Functions', to enabled extensions like:

'extensions' => [
    'enabled' => [
        // ... other enabled extensions ...
        'App\Twig\Functions'
    ]
]

And then in your views you can use your function like:

<p>{{ now() }}</p>

You can do the same with filters in app/Twig/Filters.php:

<?php

namespace App\Twig;

use Twig\Extension\AbstractExtension;
use Twig\TwigFilter;

class Filters extends AbstractExtension
{
    public function getFilters()
    {
        return [
            new TwigFilter('count_words', [$this, 'countWords']),
        ];
    }

    public static function countWords($sentence)
    {
      return count(explode(' ', $sentence));
    }
}

then in config/twigbridge.php:

'extensions' => [
    'enabled' => [
        // ... other enabled extensions ...
        'App\Twig\Functions',
        'App\Twig\Filters'
    ]
]

and you will be able to use it like this in your views:

<p>{{ 'Laravel has wonderful, thorough documentation covering every aspect of the framework. Whether you are new to the framework or have previous experience with Laravel, we recommend reading all of the documentation from beginning to end.'|count_words }}</p>

And that pretty much covers lots of use cases you would need with Twig in Laravel. Hope this article helps you save some hours of searching for answers in StackOverflow and documentation. If you find any other use cases not covered in this post, let me know and I'll update it. Until the next post!