Laravel Nullable
Do not let "null" to impersonate your objects.
Functional programming paradigm in laravel
Built with β€οΈ for every smart laravel developer
Null is usually used to represent a missing value (for ex when we can't find a row with a partcular Id we return null)
And that is the BAD IDEA, we are going to kill off !!!
π₯ Installation:
composer require imanghafoori/laravel-nullable
This package exposes a nullable() global helper function with which you can wrap variables which sometimes are object and sometimes null.
Consider this:
$email = TwitterApi::find(1)->email;Now this code is working fine But...
What if the user with ID of 1 gets deleted in future ?!
null->email and crap !
So if you forget to handle the null with an if statement, you will have errors.
You need something to FORCE you and the users of your class methods to handle the null cases.
To prevent such errors, you should code like this:
$user = $twitterApi->find($id);
if ($user === null) {
return redirect()->route('page_not_found');
}βΆοΈ Nullables to rescue !!!
To refactor the code above, first
You have to change your repo class :
// the old way:
/**
* @return User|null <---- consider here. We are returning two types !!!
*/
public function find ($id) {
$user = TwitterApi::search($id);
if (!$user) {
return null;
}
return new User($user);
}The above code returns 2 types, and That is the source of confusion for method callers. They get ready for one type, and forget about the other.
Let's do a small change to it:
/**
* @return Nullable <---- we now have only one consistent type. Not two.
*/
public function find ($id) {
$user = TwitterApi::search($id);
if (!$user) {
return new Nullable(null); // <---- instead of pure null;
}
$user = new User($user);
$message = 'Model Not Found with Id : '. $id;
return new Nullable($user, [$message]); // <---- instead of User;
}After this change, no one can have access to the real meat of your repo (in this case User object) unless he/she gives a way to handle the null case.
No if(is_null()) is required, No exception handling is required.
Remember PHP does not force us to write that if, and we as humen always tend to forget it.
And that makes a differnce ! Before it was easy to forget, but it is impossible to continue if you forget !!!
$userObj = $userRepo->find($id)->getOrSend(function ($message) {
return redirect()->route('page_not_found')->with('error', $message);
});
// Call a static method.
$userObj = $twitterApi->find($id)->getOrSend([Response::class, 'pageNotFound']);
// or a get default value
$userObj = $twitterApi->find($id)->getOr(new User());
Now we are sure $user is not null and we can sleep better at night !
βΆοΈ Testing:
An other advantage is that, if you use nullable and you forget to write a test that simulates the situations where null values are returned, phpunit code coverage highlights the closure you have passed to the ->getOrDo() (or similar methods) as none-covered, indicating that there is a missing test.
but if you return the object directly, you can get 100% code coverage without having a test covering nully situations, hence hidden errors may still lurk you at 100% coverage.
βΆοΈ Q & A :
Why throwing exceptions is not always the best idea?!
When you throw an exception you should always ask your self. Is there any body out there to catch it ??
What if they forget to catch and handle the exception ?! It is the same issue as the null.
It cases error.
The point is to give no way to continue, if they forget to handle the failures.