DEV Community: Faruk Nasir

Laravel 9.0: An Exhaustive Rundown Of What Is To Be Expected

Faruk Nasir — Wed, 19 Jan 2022 21:37:19 +0000

The Laravel release cycle was updated to include one major release every year. Due to this change, Laravel 9––the next LTS version of Laravel––was expected to be released in September of 2021.

That didn't happen.

Taylor wrote in the Laravel blog that the Laravel team had decided to postpone the release of Laravel 9 to early 2022––couple of months after the release of Symphony 6.0––as that will allow them to upgrade the underlying Symphony components utilised by Laravel. Otherwise, they'd have to wait until September of 2022 for such upgrade. This means that we should expect the release of L10 in January of 2023.

With L9 release nearly on us, I've decided to put together all that is contained within so far.

PHP8.0: The Minimum Version of PHP For Laravel 9 Applications
Symphony components will be updated to version 6.0 in L9. The minimum supported version of php in Symphony 6.0 is 8.0. So, automatically, the minimum supported version of PHP in L9 will, also, be 8.0.

A Slick Upgrade For php artisan route:list
route:list is that artisan command that allows for quick navigation of all routes in the terminal. But, If you have used it before, you'd agree with me that it's really been short in the navigation aspect, especially, on smaller screens. Routes are, extremely, difficult to spot––and that, single-handedly, defeats it's purpose.

L9 ships with a smooth upgrade that changes––for the better––how the routes are displayed. The new route:list command can be ran in two modes: default and verbose.

To run in the default, use the same old syntax: php artisan route:list. This will display the routes beautifully in a table of columns: method, domain@uri and action. And, it is designed to be, truly, responsive even in smaller screens. To ensure the responsiveness, actions with long names are truncated.

The verbose mode is activated by appending -v at the end of the default command. It should look like the following:

php artisan route:list -v

With the verbose mode, in addition to the method, domain@uri and action, two more columns are displayed: name and middleware and no column is truncated. Even the verbose mode is far better than the old display.

No changes in behaviour in all the options(sort, json etc) of the old command except with columns and compact that have been removed entirely.

There is a breaking change introduced with this make-over. Read all about it here .

L8's Anonymous Stub Migration Will Become The Default
The release of Laravel 8.37 came with anonymous migration support.

Imagine––during the course of your application development––you create an add_tags_column_to_post_table migration. In a following version, you decide to remove the tags column with a migration file remove_tags_column_to_post_table. In a future version, due to a change in requirements, you decide to put back the tags column using the migration file add_tags_column_to_post_table.

Notice that the first and third migration files' names are the same.

At this point of the migration history, running it is hardly a walk-in-the-park––as it should be, unless, you are running it––in a newly created database, while running tests or in an application that is well-tested. The most trouble is for large applications with quite a number of years in development that are poorly tested. This is the problem that Anonymous Migrations solves.

In L9, it will replace the old way migration was handled. The feature is backward-compatible. That means, it can be used with previous versions of Laravel.

The following is what an anonymous migration file looks like:

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration {
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('posts', function (Blueprint $table) {
            $table->json('tags')->nullable();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('posts', function (Blueprint $table) {
            $table->dropColumn('tags');
        });
    }
};

Replacement of SwiftMailer by Symphony Mailer
In August of 2019, Fabien Potencier wrote about his decision to replace Swiftmailer with Symphony Mailer in a short blog post. Laravel follows suite in version 9.0.

Here is the PR that made it all happen.

The server.php file in The Root Directory Can Be Safely Removed
The server.php file, usually, found at the root of a Laravel application's folder is only used for the php artisan serve command. In L9, it can be safely removed as the command's implementation will be included inside the framework. Tiny but, gold!

Replacement Of Str Functions' Internal Logic With PHP's methods
PHP 8.0 shipped with 3 new saucy string functions: str_contains, str_starts_with and str_ends_with. Since PHP 8.0 will be the minimum supported version in L9, it is only logical that their related functions in \Illuminate\Support\Str class get updated as well. Here is the PR that made it all happen!

The Latest Version of Spatie's Ignition Will Be Made Default
The announcement was made in a tweet by Spatie's Freek Van der Harten:

🚀 I'm proud to share that our team has released a new major version of Ignition. It's the most beautiful error page you ever seen, and it will be the default in @laravelphp 9

👍You can also install it in Laravel 8!

🧵 Let's take a look at all the features pic.twitter.com/jw9Dqdse9T

— Freek Van der Herten 🔭 (@freekmurze) January 18, 2022 " data-card-controls="0" data-card-theme="light">
🚀 I'm proud to share that our team has released a new major version of Ignition. It's the most beautiful error page you ever seen, and it will be the default in @laravelphp 9

👍You can also install it in Laravel 8!

🧵 Let's take a look at all the features pic.twitter.com/jw9Dqdse9T

— Freek Van der Herten 🔭 (@freekmurze) January 18, 2022
A New Option For The artisan test Command
Nuno Maduro announced in a tweet that the artisan test command will have a --coverage option in L9 that will instruct the test command to display the test coverage directly on the terminal.

In @laravelphp v9.x, we will be introducing the artisan test --coverage option. This option displays the test coverage directly on the terminal. 💫 pic.twitter.com/yKAMFwvwaZ

— Nuno Maduro (@enunomaduro) January 18, 2022 " data-card-controls="0" data-card-theme="light">
In @laravelphp v9.x, we will be introducing the artisan test --coverage option. This option displays the test coverage directly on the terminal. 💫 pic.twitter.com/yKAMFwvwaZ

— Nuno Maduro (@enunomaduro) January 18, 2022
This post is a work-in-progress. I will continue to update it as I get more information regarding Laravel 9.0 release. Thank you!

This post is a work-in-progress. I will continue to update it as I get more information regarding Laravel 9.0 release. Thank you!

A Law That Helps You Write Loosely Coupled Functions

Faruk Nasir — Sun, 01 Aug 2021 09:13:42 +0000

There are programming principles and there are frameworks to help us stick to those principles. One of those frameworks is––Law of Demeter.

Coupling is the degree of interdependence that exists between software components. Tightly coupled components are harder to maintain, modify and enhance overtime. For this reason, it's good to write loosely coupled functions as much as we can through out the development of a software program.

Honour thy functions and thy classes and keep them high up the altar away from undeserving stragers

LoD or principle of least knowledge is a design guideline for software development with the notion that a function or similar object should assume as little as possible about the properties and behaviours of components it comes in contact with. It is a novel way of loosely coupling software artifacts to make evolution much easier. It tries to prevent you from reaching into an object to gain access to a third object's methods.

Breakdown

The law states that any method of an object should call only methods belonging to:

itself
any parameters that were passed into the method
any objects it created
any directly held component objects

class Demeter {
    private:
        A *a;
        int func();
    public:
        //...
        void example(B& b);
}

void Demeter::example(B& b) {
    C c;
    int f = func(); // itself

    b.invert(); // any parameters that were passed in to the method

    a = new A();
    a->setActive(); // any objects it created

    c.print(); // any directly held component objects
}

The Worth

Theoretically, it sounds good. But, does it really help in writing more maintanable and adaptable code. Short answer––Yes.

Since components are not very knoledgable of each other, you can easily make changes to one without affecting the other.

There have been studies that show C++ classes with large response sets are more prone to error than classes with smaller response sets.

a response set is defined to be the number of functions directly invoked by methods of the class

Downside

Using the law of demeter will make your code more adaptable and robust, but at a cost: as a "general contractor", your module must delegate and manage any all subcontractors directly, without involving clients of your module. This means that you will be writing a large number of wrapper methods that simply forward the request on to a delegate. These wrapper methods will impose both a runtime cost and a space overhead, which may be significant––even prohibitive––in some applications.

Helpful Links

Javascript Iterators and the for-x Loops

Faruk Nasir — Wed, 14 Jul 2021 08:53:38 +0000

This video discusses for-of loop–the most concise and accurate way to loop through an array in javascript, in comparison to other loop types.

Laravel: Easily Customize Email Verification URL

Faruk Nasir — Tue, 06 Jul 2021 15:12:03 +0000

This is not something you'd want to do if you're building an application the traditional laravel way––that is, a monolithic app. I've had to do this recently while working on a project that has the backend and frontend existing in different code bases.

Normally, when you setup a laravel project for new users to verify their email, a temporarily signed url is generated and sent to them. The url is generated based on the project's set APP_URL in the .env file and, subsequently, in the /config/app.php file.

The problem arises when you are building a SPA front end for a laravel backend api. In that case, you may have your frontend at, say, http://cool-app.com and the backend at http://api.cool-app.com. Because the user will not have a direct access to the api endpoints, it won't be ideal to generate a user-clickable link based on the api's base url. What you'd want is a url that is based on the frontend's base url. So, how can that be achieved? Easy.

Create a custom method for generating the URL and pass it to the createUrlUsing method of the VerifyEmail notification class.

/**
* Set a callback that should be used when creating the email verification URL.
*
* @param  \Closure  $callback
* @return void
*/
public static function createUrlUsing($callback)
{
    static::$createUrlCallback = $callback;
}

The only other step that we have to take is to call this function inside the AuthServiceProvider passing the callback that returns our custom URL. The complete code is as below:

/**
* Register any authentication / authorization services.
*
* @return void
*/
public function boot()
{
    ...

    VerifyEmail::createUrlUsing(function ($notifiable) {
        $frontendUrl = 'http://cool-app.com/auth/email/verify';

        $verifyUrl = URL::temporarySignedRoute(
            'verification.verify',
            Carbon::now()->addMinutes(Config::get('auth.verification.expire', 60)),
            [
                'id' => $notifiable->getKey(),
                'hash' => sha1($notifiable->getEmailForVerification()),
            ]
        );

        return $frontendUrl . '?verify_url=' . urlencode($verifyUrl);
    });
}

In the frontend, you can have a page with a logic that makes a GET http request to the verify_url. And, there you have it––a customized email verification url!

Fortify: How to Disable Auto-login After User Registration

Faruk Nasir — Tue, 06 Jul 2021 15:00:38 +0000

With Fortify, a user is logged in, automatically, after registration. This might not be what you want for your application. Thankfully, the package is easily extensible.

This post is a walk-through on how to override the default behaviour and disable the auto-login.

Before we start, let's take a look at the package and try to understand what is happening behind the curtain. You register a user by hitting the /register endpoint with the expected name, email, password and password_confirmation fields' values. On a successful login, you get redirected to the home configuration option in your fortify's configuration file. The controller responsible for handling the registration request is RegisteredUserController. Inside the controller class, there is another method–store that handles the actual registration:

/**
 * Create a new registered user.
 *
 * @param  \Illuminate\Http\Request  $request
 * @param  \Laravel\Fortify\Contracts\CreatesNewUsers  $creator
 * @return \Laravel\Fortify\Contracts\RegisterResponse
 */
public function store(Request $request,
                        CreatesNewUsers $creator): RegisterResponse
{
    event(new Registered($user = $creator->create($request->all())));

    $this->guard->login($user);

    return app(RegisterResponse::class);
}

You can see that the registered user is logged in right after firing the Registered event.

$this->guard->login($user);

A noob mentality will have you thinking you can easily comment out that line and you're good to go. Well, you could do that and your code temporarily behaves as expected but what happens when you run composer update/install and your change is overridden––You are back to square one. You should never make changes to any code within the confines of the vendor folder.

Create a folder and name it Responses inside the Http folder of your application. Inside, create a RegisterResponse class that extends the FortifyRegisterResponse class.

<?php

namespace App\Http\Responses;

use Illuminate\Http\JsonResponse;
use Illuminate\Http\Response;
use Laravel\Fortify\Contracts\RegisterResponse as RegisterResponseContract;

class RegisterResponse extends FortifyRegisterResponse
{
    /**
     * Create an HTTP response that represents the object.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return \Symfony\Component\HttpFoundation\Response
     */
    public function toResponse($request)
    {
        return $request->wantsJson()
                    ? new JsonResponse('', 201)
                    : redirect()->intended(config('fortify.home'));
    }
}

Take out everything inside the toResponse method and replace it with code that will first log out the just logged in user by Fortify and then defers to the base class's implementation:

<?php

namespace App\Http\Responses;

use Illuminate\Contracts\Auth\StatefulGuard;
use Laravel\Fortify\Http\Responses\RegisterResponse as FortifyRegisterResponse;

class RegisterResponse extends FortifyRegisterResponse
{
    protected $guard;

    public function __construct(StatefulGuard $guard)
    {
        $this->guard = $guard;
    }

    public function toResponse($request)
    {
        $this->guard->logout();

        return parent::toResponse($request);
    }
}

Fortify's RegisteredUserController accepts a stateful guard implementation on it's constructor. So, we are using the same approach so that the response object receives the same guard instance as that of the controller. Otherwise, we could have used the Auth facade to logout the user.

The final step is to register the implementation in Fortify's service provider's boot method as in the following:

/**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        ...

        $this->app->singleton(
            \Laravel\Fortify\Contracts\RegisterResponse::class,
            \App\Http\Responses\RegisterResponse::class,
        );
    }

And that's all, folks!

This post appeared here first.

Laravel: Hotfix for SQLite Drop Foreign Exception

Faruk Nasir — Tue, 06 Jul 2021 14:55:41 +0000

By convention, you can not use ALTER TABLE sql statement to drop a foreign key in sqlite. To do that, you will have to rename the table, create a new table without the foreign key, and then copy the data into the new table.

via GIPHY

This behaviour has been baked in to Laravel in the form of an exception since Laravelv5.7. Unfortunately, this removes the possibility to simply ignore foreign keys using the same migrations across different drivers. This has been a real bottleneck for me because I mostly use in-memory sqlite database for my tests and real world databases schema definitions are messy with lots of changes and droppings through out the lifetime of your project.

If you are like me, you are in luck because I will be sharing with you a solution I found that does not involve you updating any migration.

via GIPHY

Note:
This example is for when you are using in-memory sqlite for tests!

Inside the TestCase class, create a function that calls the Connection class resolverFor method. It takes the driver's name as the first parameter and a callback as the second.

The callback will return a new class extending SQLiteConnection and override the getSchemaBuilder method:

public function hotfixSqlite()
{
    \Illuminate\Database\Connection::resolverFor('sqlite', 
        function ($connection, $database, $prefix, $config) {
        return new class($connection, $database, $prefix, $config) 
            extends SQLiteConnection {
            public function getSchemaBuilder()
            {
                if ($this->schemaGrammar === null) {
                    $this->useDefaultSchemaGrammar();
                }

                return new class($this) extends SQLiteBuilder {
                    protected function createBlueprint($table, Closure $callback = null)
                    {
                        return new class($table, $callback) extends Blueprint {
                            public function dropForeign($index)
                            {
                                return new Fluent();
                            }
                        };
                    }
                };
            }
        };
    });
}

The final step is to call the newly created function in the TestCase's constructor class. Your final TestCase class should look like the following:

abstract class TestCase extends BaseTestCase
{
    public function __construct(?string $name = null, array $data = [], string $dataName = '')
    {
        $this->hotfixSqlite();
        parent::__construct($name, $data, $dataName);
    }

    /**
     *
     */
    public function hotfixSqlite()
    {
        \Illuminate\Database\Connection::resolverFor('sqlite', 
            function ($connection, $database, $prefix, $config) {
            return new class($connection, $database, $prefix, $config) 
                extends SQLiteConnection {
                public function getSchemaBuilder()
                {
                    if ($this->schemaGrammar === null) {
                        $this->useDefaultSchemaGrammar();
                    }

                    return new class($this) extends SQLiteBuilder {
                        protected function createBlueprint($table, Closure $callback = null)
                        {
                            return new class($table, $callback) extends Blueprint {
                                public function dropForeign($index)
                                {
                                    return new Fluent();
                                }
                            };
                        }
                    };
                }
            };
        });
    }
}

Important:
For PHPUnit 9, it is important that you call the hotfix
method before the parent constructor in the constructor method.

via GIPHY

This post appeared here first.

Too many commits? No worries, just squash them into one!

Faruk Nasir — Tue, 27 Apr 2021 10:56:49 +0000

It's a beautiful Friday morning. It had just rained last night. You wake up feeling energetic and ready to build something great or make something better. You've filled your favourite mug with your favourite morning beverage, sat down on your desk and opened your laptop.

The first open issue is your pick of the day. You dove right into it. The problem is understood. It's an open and close case.

First commit. Tests are passing. You pushed to github!

Shortly after, QA report comes through that your PR is breaking another thing not covered by currently written tests.

You create 3 more commits for the fix and some tests. More things break!

Shoooosh!

By midday, half your screen is filled up with commit messages. The day is adamant on going down in history as proof that, "a wonderful morning does not guarantee a good evening". Literally.

At the end, you manage to get everything to work:

[x] Tests are passing
[x] Static Analysis
[x] QA Approval

But, Your PR has 11 commits. You can't send that for a review. Its too much work for a reviewer. Have some empathy.

Luckily for you, you can fix that with the squash-rebase workflow.

What is the squash-rebase workflow

The principle here is, before you merge a working branch into the main branch, all commits of the working branch should be squashed into one single commit, then, rebased from the main branch.

These are the steps:

Select the starting commit

Couple of assumptions here:

You are working on a feature branch you checked out from your project's up-to-date main branch.
You have made all necessary changes you need to make up to your final commit.

On the feature branch, run the following command:



git log

This is to list all the commits we have made starting from the most recent one. You will get something similar to the following on your screen:



commit e8f89c696596619678c819f9b7a34730cd3f41bb (HEAD -> chore/test-git-squashing, origin/chore/test-git-squashing)  --- newer commit
Author: Faruk Nasir <user@example.com>
Date:   Tue Apr 27 09:41:30 2021 +0100

    fix: on and on and on we go

commit a8293a21f31b5fea688dc3ef65add3b9924b5f28
Author: Faruk Nasir <user@example.com>
Date:   Tue Apr 27 09:41:00 2021 +0100

    fix: and on we go

commit 3dc51a8a8f83d96cde7b0f9b2be33c694ca91a3d
Author: Faruk Nasir <user@example.com>
Date:   Tue Apr 27 09:40:33 2021 +0100

    fix: we are adding something

commit 5f561cc9380ddeafd6134cee31b4ee4f630eac4c
Author: Faruk Nasir <user@example.com>
Date:   Tue Apr 27 09:40:03 2021 +0100

    fix: deleted some things

commit 3c0ae097ef858d61ecc2110d84a413f77673d09a (origin/main, main)  --- older commit
Author: Faruk Nasir <user@example.com>
Date:   Tue Apr 27 09:33:13 2021 +0100

    chore: fifth change

Above you can easily detect where your main branch stops and where your feature branch starts. The goal here is to count all the commits of your feature branch. This will then be used in the command to start the interactive rebasing. More on that in a bit. For a more compact result of the commits' log, we can try decorating the command as in the following:



git log` or `git log --graph --decorate --pretty=oneline --abbrev-commit

This will give us:



* e8f89c6 (HEAD -> chore/test-git-squashing, origin/chore/test-git-squashing) fix: on and on and on we go
* a8293a2 fix: and on we go
* 3dc51a8 fix: we are adding something
* 5f561cc fix: deleted some things
* 3c0ae09 (origin/main, main) chore: fifth change
* e1d0da7 chore: fourth change
* e165870 chore: third change
* f249883 chore: second change
* 86b4fbd chore: first change

Picking and Squashing

After getting the number of commits you want to squash, you go ahead and run the following command to start the interactive:



git rebase --interactive HEAD~[number of commits]

# or

git rebase -i HEAD~[number of commits]

So, let's say you are trying to squash 4 commits, the command will look something like this:



git rebase -i HEAD~4

Alternatively, if you don't want to count the number of commits all the time, especially, when the commits are quite long, you can get the hash of the commit just before the first one to rewrite from and run the interactive rebasing command like this:



git rebase --interactive [commit-hash]

An editor will popup with something like the following:



pick e8f89c6 fix: on and on and on we go                --- older commit
pick a8293a2 fix: and on we go
pick 3dc51a8 fix: we are adding something
pick 5f561cc fix: deleted some things                   --- newer commit

...

Here, you are to edit the file leaving one commit as pick (ususally the first one) and change all the other ones to s or squash. Save and exit the editor.

New Commit Creation

You will be prompted again to enter a commit message for the final about to be created. You can choose to skip this and the name of the commit will be a list of all the intermediate commit. It will look like the following:



on and on and on we go
and on we go
we are adding something
deleted some things

And, thats it! You have successfully squashed all your commits into one. Thank you for reading!

This post first appeared (here)[https://faruknasir.com/2021/4/squash-commits-into-one-git]

Running Psalm With Github Actions

Faruk Nasir — Fri, 23 Apr 2021 08:27:46 +0000

I have written about Psalm here. Here, I share my workflow for running Psalm in Github Actions:

name: Psalm

on:
  push:
    paths:
      - '**.php'
      - 'psalm.xml.dist'

jobs:
  psalm:
    name: psalm
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '7.4'
          extensions: dom, curl, libxml, mbstring, zip, pcntl, pdo, sqlite, pdo_sqlite, bcmath, soap, intl, gd, exif, iconv, imagick
          coverage: none

      - name: Cache composer dependencies
        uses: actions/cache@v2
        with:
          path: vendor
          key: composer-${{ hashFiles('composer.lock') }}

      - name: Run composer install
        run: composer install -n --prefer-dist

      - name: Run psalm
        run: ./vendor/bin/psalm --output-format=github

Let's Discuss What's Happening Above

I start by specifying a name for the job. In this case, "Psalm".

name: Psalm

I, then, go on to describe when I want the job to run. I only want it to run when there is a new version of a php file or the psalm config file.

on:
  push:
    paths:
      - '**.php'
      - 'psalm.xml'

Then, I go on to describe fully the actual job that needs to run. First, I specify the environment the job is going to run on. Then, I check out the code in the virtual machine.

jobs:
  psalm:
    name: psalm
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

That is followed by setting up PHP(using a third party action) and Composer:

- name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '7.4'
          extensions: dom, curl, libxml, mbstring, zip, pcntl, pdo, sqlite, pdo_sqlite, bcmath, soap, intl, gd, exif, iconv, imagick
          coverage: none

      - name: Cache composer dependencies
        uses: actions/cache@v2
        with:
          path: vendor
          key: composer-${{ hashFiles('composer.lock') }}

      - name: Run composer install
        run: composer install -n --prefer-dist

Then, the job is finally executed:

      - name: Run psalm
        run: ./vendor/bin/psalm --output-format=github

And, that's that!

This post first appeared here

Static Analysis With Psalm

Faruk Nasir — Fri, 23 Apr 2021 08:20:24 +0000

A typo is never that serious unless it's in a software code base. A tiny mistake such as an omission of a comma can cause companies billions of dollars, destroy a NASA rocket or even interrupt service for users of a SaaS product.

Over the years there has been tremendous efforts towards development of automated tools and processes to prevent such catastrophic typos from finding their way into or making a home of our software code bases. Extensions of compiler technologies have been built to help us with automated reviews.

In this post, I write about Psalm - a PHP static analysis tool, and how you can take advantage of its powerful features in stopping bad code from creeping into your source codes.

Psalm

Psalm is a VIMEO open-source project that helps you in catching bugs early and identifying problems in your code. It helps:

prevent type-related runtime errors
enforce standard coding patterns
autofix bugs
detect PHP security vulnerabilities using taint analysis

For a quick start and installation guide, head over here.

Psalm does not just flag a line of code as problematic, it includes links that you can follow to see explanation for the decision. It looks like this:

ERROR: InvalidArgument - \namespace\file.php:8:19 - 
Argument 1 of getAttribute expects string, 
int provided (see https://psalm.dev/004)

Support For Laravel

Psalm v3 came with a new plugin framework that makes authoring integrations for third party packages much easier. That, with Barry's IDE Helper made the Laravel Plugin a reality according to Matt.

It's super easy to setup. You only need two commands after successfully installing and setting up Psalm:

composer require --dev psalm/plugin-laravel
./vendor/bin/psalm-plugin enable psalm/plugin-laravel

Under the hood, it runs the laravel IDE helper, get the stubs and feed them into Psalm. I, personally, would love it that the package exists independent of the IDE helper because a scenario in the future where issues would pile up in both repos because of some dependency mismatch or recent upgrade that stops a certain "something" from working entirely is imminent.

But, so far so good. I'm really happy with the developments and excited for what is in store for the future!

This post first appeared here

PHP null-safe and null-coalescing operators

Faruk Nasir — Fri, 23 Apr 2021 08:10:50 +0000

Null-coalescing Operator (??)

PHP7 came with syntactic flavourings we all have been savouring ever since its release - One of which is the null-coalescing operator. If you have ever had to use the ternary operator together with isset() method, then this was tailor-made for you!

$developer_status = $coding ?? $sleeping;

// is equivalent to
$developer_status = isset($coding) ? $coding : $sleeping;

It returns the first operand if true, otherwise returns the second. It is also chainable:

$developer_status = $coding ?? $sleeping ?? $eating;

Null-safe Operator (?->)

The null-safe is a PHP8 feature that, instead of throwing an exception, short-circuits to null when a chained property or method access is null and the rest of the chain is skipped.

It is an elegant way of wrapping is_null around each property or method access.

Let's examine the following code snippet:

$recentlyActive = null;

if (session()->has('user')) {
    $user = session('user');

    if (! is_null($user)) {
        $lastLoggedIn = $user->lastLoggedIn();

        if (! is_null($lastLoggedIn)) {
            $recentlyActive = $lastLoggedIn->withinLast7Days();
        }
    }
}

With null-safe operator, we can be more efficient by writing less and clearer code:

$recentlyActive = session()->has('user')?->lastLoggedIn?->withinLast7Days();

Versus

What is the difference between null-safe operator and null-coalescing operator. Hint: it's not just in the syntax, it is also in the semantics.

The null-safe operator supports method while the null-coalescing operator doesn't. The null-coalescing operator supports array while the null-safe operator doesn't.

// this works
$array = [];

var_dump($array['mukulli']->kofa ?? null);


// this throws a warning
var_dump($array['mukulli']?->kofa);

// Warning: Undefined array key "key"

Null-safe with methods:

class Order
{
    public function date(): ?Carbon { /* … */ }

    // …
}

$order = new Order();

var_dump($order->date()?->format('Y-m-d'));

// null

This post first appeared here

It's never easy knowing when to use exception handling. In this post I explain a simple rule

Faruk Nasir — Wed, 07 Apr 2021 07:18:18 +0000

It is good practice to check for every possible errors - especially, the unexpected ones. This can push us to write code that is hard to read. The logic of your program can end up being totally obscured by error handling, particularly, if you subscribe to, "a function must have a single return statement" school of thought.

Let's examine the code snippet below:

Personally, I am not aware of any limitation to if-else nesting but, deep nestings could be an indication of terrible design. They could negatively impact readability which will make the job of the future maintainer a little bit more difficult.

With most modern programming languages, we can, easily, refactor the above code snippet using exception handling to increase readability:

The code is clearer with the main logic on one side and all the error handling moved to a single place. But, my personal dilemma is the deciding factor of when wrapping a piece of code around a try and catch block is the right approach and when it isn't.

What is Exceptional?

"Exceptions should rarely be used as part of a program's normal flow; exceptions should be reserved for unexpected events".

If your code tries to load a record from the database for some operations, and that record does not exist, should an exception be raised?

That depends on the expected behaviour.

Always assume that an uncaught exception will terminate your program and then ask yourself, "Will the code still run if I removed the exception handler?". If "no", then, maybe, exceptions are being used in non-exceptional circumstances.

If the record should have been in the database, then an exception can be raised. This is because something unexpected happened - a record that your program expected to find in the database was not found.

On the other hand, if you are unsure whether the record should exist or not, then not finding it in the database is not exceptional - not an unexpected behaviour, and an error return is appropriate.

This post first appeared on https://faruknasir.com