Posts

Since 2024
Microsoft Clarity Integration for Laravel
Microsoft Clarity Integration for Laravel

The clarity-laravel package lets you easily integrate Microsoft Clarity into your Laravel application. I wasn't familiar with Clarity before seeing this package—it's a GDPR and CCPA-ready product that you embed in your application, and it can capture how people use your site: Heatmaps with Microsoft Clarity The main features that Clarity offers your application include: Heatmaps Session recordings Insights Google Analytics integration Integration is easy with this package: you set up a few environment variables and include the package's Blade component in your application's layout file: <head> <x-clarity::script /> </head> This package will enable Clarity based on the CLARITY_ENABLED environment variable value in the clarity.php configuration file. If setting the environment variable isn't flexible enough, you can set the :enabled property on the component with a variable boolean value that you define: <x-clarity::script :enabled="$enabled" /> While you could easily integrate the Clarity embed code in your application directly, this package takes care of it for you, and you can start collecting data in minutes. You can learn more about this package, get full installation instructions, and view the source code on GitHub. You can learn more about Clarity from the Microsoft Clarity documentation. You can also see a live demo The post Microsoft Clarity Integration for Laravel appeared first on Laravel News. Join the Laravel Newsletter to get Laravel articles like this directly in your inbox.

Apply Dynamic Filters to Eloquent Models with the Filterable Package
Apply Dynamic Filters to Eloquent Models with the Filterable Package

Filterable is a Laravel package by Jerome Thayananthajothy that enhances Laravel queries with adaptable, customizable filters and intelligent caching to improve both performance and functionality. The main features of this package include: Dynamic Filtering: Apply filters based on request parameters with ease. Caching: Improve performance by caching query results. User-specific Filtering: Easily implement filters that depend on the authenticated user. Custom Filter Methods: Extend the class to add your own filter methods. Defining Filter classes is at the center of this package, where you can create methods that can apply filtering to Eloquent queries. The package includes a make:filter Artisan command to generate a filter in your app's App\Filters namespace. Here's an example of a filter from the package's README: namespace App\Filters; use Filterable\Filter; use Illuminate\Database\Eloquent\Builder; class PostFilter extends Filter { protected array $filters = ['status', 'category']; protected function status(string $value): Builder { return $this->builder->where('status', $value); } protected function category(int $value): Builder { return $this->builder->where('category_id', $value); } } Given a PostFilter, you can utilize this class in a controller with the Post model to filter models based on the HTTP query params: public function index(Request $request, PostFilter $filter) { // i.e., /posts?status=active&category_id=2 $query = Post::filter($filter); $posts = $request->has('paginate') ? $query->paginate($request->query('per_page', 20)) : $query->get(); return response()->json($posts); } You can learn more about this package, get full installation instructions, and view the source code on GitHub. The post Apply Dynamic Filters to Eloquent Models with the Filterable Package appeared first on Laravel News. Join the Laravel Newsletter to get Laravel articles like this directly in your inbox.

Property Hooks Get Closer to Becoming a Reality in PHP 8.4
Property Hooks Get Closer to Becoming a Reality in PHP 8.4

The Property Hooks RFC passed a significant milestone, getting an overwhelmingly positive 34 "yes" votes and only 1 "no" vote. That's well above the required 2/3 majority required to pass. What are property hooks in PHP? Here's the proposal summary from the RFC: Developers often use methods to wrap and guard access to object properties. There are several highly common patterns for such logic, which in practice may be verbose to implement repeatedly. Alternatively, developers may use __get and __set to intercept reads and writes generically, but that is a sledge-hammer approach that intercepts all undefined (and some defined) properties unconditionally. Property hooks provide a more targeted, purpose-built tool for common property interactions... This RFC introduces two “hooks” to override the default “get” and “set” behavior of a property. Although not included in this initial version, the design includes the ability to support more hooks in the future. Property hooks are inspired by languages like Kotlin, C#, and Swift, and the syntax includes two syntax variants that resemble short and multi-line closures: class User implements Named { private bool $isModified = false;   public function __construct( private string $first, private string $last ) {}   public string $fullName { // Override the "read" action with arbitrary logic. get => $this->first . " " . $this->last;   // Override the "write" action with arbitrary logic. set { [$this->first, $this->last] = explode(' ', $value, 2); $this->isModified = true; } } } The syntax doesn't require that both hooks always be defined together; in fact, here's an example of only defining set from the RFC: class User { public string $name { set { if (strlen($value) === 0) { throw new ValueError("Name must be non-empty"); } $this->name = $value; } }   public function __construct(string $name) { $this->name = $name; } } You can read all the details about Property Hooks in PHP in the RFC. This feature looks likely to drop in PHP 8.4. The implementation is already a draft pull request if you want to see the discussion and progress of this feature. The post Property Hooks Get Closer to Becoming a Reality in PHP 8.4 appeared first on Laravel News. Join the Laravel Newsletter to get Laravel articles like this directly in your inbox.

Asserting Exceptions in Laravel Tests
Asserting Exceptions in Laravel Tests

Laravel's recent release of Laravel 11.4 introduced the Exceptions facade, which adds conveniences around asserting exceptions in Laravel's exception handler. Before this release, I would typically use the $this->withoutExceptionHandling() to assert that a specific exception happened during an HTTP test: use App\Exceptions\WelcomeException; $this->withoutExceptionHandling(); try { $this->get('/'); } catch (WelcomeException $e) { $this->assertEquals('Woops, there was an issue with your request!', $e->getMessage()); return; } $this->fail(sprintf('The expected "%s" exception was not thrown.', WelcomeException::class)); When you expect a request to not throw any exceptions, using withoutExceptionHandling cuts out the middleman when you're debugging why an error is happening when you don't expect it. The above code is tedious to write, because it manually captures the exception, makes assertions about the exception, and calls return to avoid the manual $this->fail() call. The manual failure will catch situations when the test doesn't throw an exception when expected. If $this->fail() is called in the above scenario, here's what the output would look like: $ phpunit There was 1 failure: 1) Tests\Feature\ExampleTest::test_the_application_returns_a_successful_response The expected "App\Exceptions\WelcomeException" exception was not thrown. /app/tests/Feature/ExampleTest.php:33 Laravel's Exceptions Facade Let's look at how the new Exceptions facade can simplify our test; the first example, rewritten, would look as follows: use Illuminate\Support\Facades\Exceptions; Exceptions::fake(); $this->get('/'); Exceptions::assertReported(function (WelcomeException $e): bool { return $e->getMessage() === "Woops, there was an issue with your request!"; }); Using the Exceptions facade gives us the bonus of not having to capture an exception to assert things manually. Said another way, the test can keep Laravel's exception handler in place but still be able to assert exceptions that happened during a request. If we want to be sure that a test doesn't throw a specific exception or doesn't throw any exceptions, period, the new facade has our back: Exceptions::assertNotReported(WelcomeException::class);   Exceptions::assertNothingReported(); If the exception handler does not report the WelcomeException, the test output would give us a nicely formatted message: $ phpunit There was 1 failure: 1) Tests\Feature\ExampleTest::test_the_application_returns_a_successful_response The expected [App\Exceptions\WelcomeException] exception was not reported. While there may be times when you don't want to fake Laravel's exception handler, when testing edge cases, the new Exceptions facade is tremendously helpful and cleans up our code: Exceptions::assertReported(WelcomeException::class); Exceptions::assertReportedCount($count); Exceptions::assertNotReported(WelcomeException::class); Exceptions::assertNothingReported(); Exceptions::throwFirstReported(); To learn more about the Exceptions facade, check out Laravel’s documentation. The post Asserting Exceptions in Laravel Tests appeared first on Laravel News. Join the Laravel Newsletter to get Laravel articles like this directly in your inbox.

Basset is an alternative way to load CSS & JS assets
Basset is an alternative way to load CSS & JS assets

It's 2024 and I'm calling it - Server-Side Rendering has officially made a comeback: in Laravel, where Livewire now has 46.000 installs per day in Ruby on Rails with Hotwire in Phoenix with Liveview in web dev in general with HTMX Now that "the old has become the new"... maybe it's time to re-visit another practice we've adopted from the Javascript ecosystem. Maybe it's time to... drop the build step? Crazy, I know! But there's been a lot of talk about no-build Laravel setups in my bubble. And there's one place where people invariably get stuck - "If we drop NPM, what do we do about JS dependencies?". Here's my answer to that - or at least an important first step. What if instead of installing our JS dependencies with a package manager like NPM and bundling them... we just load them directly from the URL? You know... similarly to what the founder of NodeJS himself is doing in Deno. He has publicly said NPM has become a mess and created an alternative for the JS ecosystem... why don't we do the same for the Laravel ecosystem? If you dream about the simple days when you could just load assets using asset(), try Basset - a better asset helper for Laravel. You just replace asset() with basset() to gain some super-powers: assets from CDNs are downloaded to /storage and served from there; vendor assets become possible to load; non-public assets become possible to load; it becomes impossible to double-load an asset during a request; In short, basset() removes the limitations of asset(), allowing you to load any asset you want, safely. That means in addition to this: <link href="{{ asset('path/to/public/file.css') }}"> You can safely do this: <script src="{{ basset(storage_path('file.js')) }}"> <script src="{{ basset(base_path('vendor/org/package/assets/file.js')) }}"> <script src="{{ basset('https://cdn.com/path/to/file.js') }}"> This is a very simple solution for those who want to load assets "the old easy way" in their Laravel projects, because it solves a few problems with that "old way": Don't want GDPR issues? ✅ Solved - Basset will cache the asset to /storage and serve it from there. Don't want to depend on a CDN being up? ✅ Solved - the assets can be cached upon deployment (or on commit). Don't want to load an asset twice, if used by multiple components on that page? ✅ Solved - automatically. Concerned about the performance of loading multiple JS files vs one big bundle? ✅ Solved by HTTP/2, which makes it performant to load multiple Javascript assets on a single page. Granted, Basset may not be a perfect asset loading solution. At least not for every project. It's only been around for 12 months, so it's missing things like importmaps and the like, to make it a 1-to-1 alternative to NPM and Deno's way. But it has been around for 12 months and has proven its usefulness. Perhaps... it's time for us to take another look at how we load assets in our Laravel projects. Maybe we'll discover the simple way... is a good way. For some projects, at least. I suggest you give Basset a try. After all: it's been in production for 1 year already; it's maintained by the Backpack team; it's got 110.000 downloads already; it's under MIT License; If you have feedback on it, open an issue on Github and tell the team about it. A v2 is due soon enough, and we want to incorporate as much feedback as possible. The post Basset is an alternative way to load CSS & JS assets appeared first on Laravel News. Join the Laravel Newsletter to get Laravel articles like this directly in your inbox.