Laravel Code Tips

💡#Laravel Tip: Did you know that any commands you schedule in the console kernel can automatically email their output if something goes wrong.

Not sure on the difference between "strtoupper" and "mb_strtoupper"? #PHP

To boost perceived speed in your @LaravelLivewire apps when loading data, make use of prefetching.

The .prefetch modifier tells Livewire to fetch the result in the background on hover, and then displays the result when the button is actually clicked ✨

A tiny tip about #laravel eloquent.

To retrieve the Query Builder after filtering the results: you can use ->toQuery().

The method internally use the first model of the collection and a whereKey comparison on the Collection models.

⚡️ Database Tip

Comparing anything to a null value is always null too (meaning false). Simple operations like searching for rows with an unequal value will be more complicated. But null safe operators are making those queries dead simple again.

I don't do it very often, but you can use Laravel's Schema builder anywhere you want, not just in migrations!

If you ever need to make a temp table to help you mass process data more quickly, it's a great solution.

A handy $loop object is available in Laravel Blade foreach loops. Super useful for controlling output based on the loop position ➰

Source dive for reference: https://github.com/laravel/framework/blob/8.x/src/Illuminate/View/Concerns/ManagesLoops.php

A quick and easy way to check if @LaravelLivewire components are re-rendering when you don't want/need them to.

Add now() or now()->timestamp to your component template. The time value will increment if there's a re-render side effect!

📝 Here's part 2 of the new Database and Eloquent ORM features in @laravelphp 8.x since the release in September 2020.

One of my favorites is the ability in Model Factories to create models without dispatching any events 🔥

Blog post: https://protone.media/en/blog/database-and-eloquent-orm-new-features-and-improvements-since-the-original-laravel-8-release-22

#Laravel #PHP

#Laravel Updates:

In Laravel 8.7 you can now validate enum columns!

An Example:

This release of Laravel also includes a "--requests" flag when making models via Artisan. This option will create a "Store{Model}Request" and "Update{Model}Request" form request + update the controller to use those requests on their respective methods. 🔥

Thanks @PovilasKorop!

#Laravel Tip: If you are running Laravel v8.70, you can chain can() method directly instead of middleware('can:..')

Here is and example:

💡 Check if there's a previous URL when showing error pages instead of linking to static page!

It's incredibly useful if your marketing and app pages share the same error pages! It makes sure your users won't get lost :)

Happy Monday 🙌 Let's start the week with a Laravel tip: You can use the Prunable trait to automatically remove models from your database. For example, you can permanently remove soft deleted models after a few days.

#Laravel Livewire Tip: If you want to remove property values at once and make your code cleaner, you can use $this->reset method.

Here is an example:

If you ever need to generate text-based tables for sending in text messages, outputting in console, or in logs, @symfony provides an awesome "Table" class, just for that! 💅 Such a cool utility! 🤩

Do you hate re-writing short closures just to add temporary debugging code?

#Laravel Tip: If you want a single value from a database table.

Laravel Tip: Abstract relations you commonly use to a trait. It’s a DRY approach that keeps your models thin.

PHP reminder: you can define your class properties directly on the constructor. ✅

PHP reminder: you can use the method "__toString()" to specify the string representation of an object. ✅

🔥 A way to check if a string contains valid JSON: just decode it, encode it again, and check if it matches the original value #php

Laravel productivity tip! Add this little function to your bash profile to quickly execute anything with the Tinker command and get the results instantly.

💡 By default, the @laravelphp HTTP client doesn't throw exceptions on client and server errors.

However, you can make it do that by using the 'throw' method, and this method is chainable 🔥

Documentation: https://laravel.com/docs/8.x/http-client#throwing-exceptions

#Laravel #PHP #webdev #webdevelopment

For example:

• invoice() to create an Invoice model
• product() to create a Product model

Imagine that you have a nested component that depends on the parent state. You don't need to sync child state into parent, you just want to replace the child when the parent state changes.

You can use my custom directive for that.

It's good to get into the habit of using $wire, since it provides a full communication layer for your Livewire component.

It also doesn't run into issues when you use it inside single quoted attributes.

Let's look at the same trait again. It does two interesting things.

1. Livewire::listen() is superior to hydrate* and dehydrate* when you need access to specific parts of the lifecycle

2. The instanceof self check scopes the listener to the component

Traits are a powerful way to reuse functionality between Livewire components.

They're generally better than component nesting, since that comes with more complexity and worse performance.

Next up: Advanced trait examples

As you know, Livewire sometimes runs into painful DOM diffing issues. They can usually be solved with simple workarounds, but sometimes those workarounds get quite complex.

So I built a package that adds a wire:replace directive, telling Livewire to replace an entire chunk of the DOM, instead of trying to diff individual changes.

This example is from Tenancy v2 when we had an ActiveRecord-style custom Tenant object.

Very useful if you want to tag jobs with things like the user/tenant id.

You DON'T have to go raw SQL when you hit a performance issue with Eloquent. There's so many "secret" techniques.

Example: You can create scopes to add specific selects to your queries.

I didn't know about this for so long.

Instead of: $table->unsignedBigInteger('user_id'); $table->foreign('user_id')->references('id')->on('users');

You do: $table->foreignId('user_id')->constrained();

$model->getOriginal()

in Eloquent event listeners can be very useful.

One such use case is checking whether an order is locked. If it is, the only write action we permit is unlocking it. Only then can changes be made.

Not recommended in most cases, but interesting.

(image stolen from the internet)

One of them is examining sent emails ✉️

You usually don't need a service like Mailtrap. Just use the log mail driver and install Telescope.

(image stolen from the internet)

It's IMO better to use static properties and have "self-contained" behavior & configuration. Than to have a billion config keys. Especially when building large packages.

Makes the package more extensible, by consisting of atomic parts

Extremely handy when you have multiple admin panels in a single app.

Great for debugging/tweaking the design.

You can tell the app what response to return when a specific exception is encountered.

This is the simplest example. There's many more use cases.

Left: double nesting Right: arrow function

Above I said that moving business logic to action/service classes is good. But context matters

Here's code design advice from a popular "Laravel best practices" repo. There's absolutely no reason to put a 3-line check into a class. That's just overengineered

If you validate some resource's attributes on multiple places, you definitely want to centralize these validation rules, so that you don't change them in one place but forget about the other places.

https://twitter.com/LiamHammett/status/1260252814158282752

You can make your Blade templates more expressive by creating custom directives. For example, rather than checking if the user has the admin role, you could use @admin.

Sometimes you may want to execute DB queries in blade. There are some ok use cases for this, such as in layout files.

But if it's a view returned by a controller, pass the data in the view data instead.

Install extensions, write annotations, use typehints. Your IDE will help you with getting your code working correctly, which lets you spend more energy on writing code that's also readable.

If you have a complex route action, consider moving it to a separate controller.

For OrderController::create, you'd create CreateOrderController.

Another solution is to move that logic to an action class — do what works best in your case.

If you want to retrieve some data from a model, create an accessor.

Keep methods for things that change the model in some way.

Similar to single-use traits.

This tactic is great when you have a very long template and you want to make it more manageable.

There's nothing wrong with @including headers and footers in layouts, or things like complex forms in page views.

Sometimes you may have multiple classes with the same name. Rather than importing them with an alias, import the namespaces.

Rather than thinking "what can this object do", think about "what can be done with this object". Exceptions apply, such as with action classes, but this is a good rule of thumb.

https://www.youtube.com/watch?v=dfgtKb-VpRk

Don't think that long variable/method names are wrong. They're not. They're expressive.

Better to call a longer method than a short one and check the docblock to understand what it does

Same with variables. Don't use nonsense 3-letters abbreviations

You can also create objects with fluent APIs. Gradually add data by with separate calls, and only require the absolute minimum in the constructor.

Each method will return $this, so you can stop at any call.

Know the difference between static/instance methods & variables and private/protected/public visibility. Also learn how Laravel uses magic methods.

You don't need this as a beginner, but as your code grows, it's crucial.

Sometimes people put helpers into a class.

Beware, it can get messy. This is a class with only static methods used as helper functions. It's usually better to put these methods into classes with related logic or just keep them as global functions.

Consider offloading some logic from controllers to events. For example, when creating models.

The benefit is that creating these models will work the same everywhere (controllers, jobs, ...) and the controller has one less worry about the details of the DB schema

Your controllers should be simple. They should say things like "create invoice for order". They shouldn't be concerned with the details of how your database is structured.

Leave that to the model.

The opposite of the previous tip. Sometimes the value comes from a complex call and as such, creating a variable improves readability & removes the need for a comment.

Remember that context matters & your end goal is readability

Opening an array with [ and indenting the values tends to work well. Same with long function parameter values.

Other good places to split lines are chained calls and closures.

The code will be cleaner & more readable and you will see understandable exceptions if something goes wrong. No half-passing edge cases.

Custom collections got you sorted. Love these methods.