add @log directive

[Ashot1995]

This Pull Request introduces a new Blade directive, @log(), designed to simplify the logging of messages directly within Blade templates. The directive streamlines the process by eliminating the need for the traditional PHP logging syntax, thus making the templates cleaner and more maintainable.

Current Method

Previously, logging within a Blade template required embedding PHP code, as demonstrated below:
@php
Illuminate\Support\Facades\Log::info('User authenticated');
// or alternatively using the helper function
logger('User authenticated');
@endphp

@php
Illuminate\Support\Facades\Log::error('Error occurred');
@endphp

@php
Illuminate\Support\Facades\Log::debug('Debug occurred');
@endphp

With the New @log() Directive
The new @log() directive enhances readability and reduces the boilerplate code. Here are examples illustrating how to use the new directive:

// Logging an information message
@log('User authenticated') // Defaults to 'info' level
@log('User authenticated', 'info')

// Logging an error message
@log('Error occurred', 'error')

// Logging a debug message
@log('Debug occurred', 'debug')

This approach not only simplifies the syntax but also aligns with the Blade templating philosophy of clean and concise code. The directive supports various logging levels, allowing developers to specify the appropriate context easily.

[donnysim]

You can use the logger()-> function, and also don't use alias facades (global namespace), not everyone has them enabled.

[Ashot1995]

You can use the logger()-> function, and also don't use alias facades (global namespace), not everyone has them enabled.

for logger alse need at first open php
@php
logger()
@endphp
and we cant write log type(error,info....)

[Wulfheart]

I don't actually see a use case for logging in blade (or at least one so common that it justifies adding it to core). Personally, I think this falls more under the category "nice-to-have but not crucial and can easily be a package".

[Ashot1995]

I don't actually see a use case for logging in blade (or at least one so common that it justifies adding it to core). Personally, I think this falls more under the category "nice-to-have but not crucial and can easily be a package".

I understand your concerns about the necessity of this feature within the core of Laravel's Blade templating engine. Let me outline a few scenarios where @log() can be particularly beneficial:

1 Debugging Complex Views: In applications with complex data manipulations directly in the views or multiple conditional renderings, logging can provide immediate insights right where the data is handled, without disrupting the flow by switching to controller or middleware logs.

2 Development Efficiency: During development, quick logs embedded in views can speed up the process of verifying data states and behavior without cluttering the main application logs. It enhances the developer's experience by allowing them to keep context-specific logs contained within the view.

3 Production Monitoring: In production, logs generated from views can help trace issues related to dynamic content rendering which might not be as easily traceable through traditional logging at the controller or service layer.

[rodrigopedra]

and we cant write log type(error,info....)

{{ logger()->error('foo', ['bar' => 'baz']) }}

I'd also say it could be easily added to a project using macros, or provided by a 3rd-party package.

[taylorotwell]

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If applicable, please consider releasing your code as a package so that the community can still take advantage of your contributions!