Laravel 8.62

1. Eventos del modo de mantenimiento de Laravel 8.62

Una de las novedades es que se activan un conjunto de eventos cuando nuestra aplicación entra o sale del modo de mantenimiento. Esto nos permitirá conectarnos al cambio de estado o cambio de estado del modo de mantenimiento para aplicar código personalizado.

Por ejemplo, estamos usando un servicio de monitoreo como Ohdear o Bing bing (estas aplicaciones / servicios se usan siempre que tenemos algún problema en la aplicación / sitio bla, bla…). Pero, por supuesto, en el modo de mantenimiento querremos deshabilitar estos servicios de monitoreo para que podamos cambiar nuestro código, romperlo o cualquier cosa sin ser molestados por las notificaciones provenientes de estos servicios de monitoreo. Ese es el momento en que estos eventos se vuelven útiles.

En el Event Service Provider podemos escuchar el evento habilitado en modo de mantenimiento para deshabilitar la monitorización registrando el oyente que deshabilita la monitorización. También podemos escuchar el evento deshabilitado del modo de mantenimiento para habilitar el monitoreo. Las características del modo de mantenimiento nos permiten actualizar, implementar nuestra aplicación o realizar cualquier tipo de mantenimiento sin exponer la aplicación al usuario final. Cuando la aplicación está en el modo de mantenimiento, no escuchará ninguna solicitud http y no escuchará ninguna caída de cola durante este tiempo. Cualquier usuario que visite la aplicación durante este tiempo verá un mensaje en la vista de que la aplicación se encuentra actualmente en modo de mantenimiento, hasta que se desactive el modo de mantenimiento, solo ellos podrán visitar la aplicación.

2. Recuperación de la entrada de solicitud como una colección

Resulta útil cuando espera que una entrada, una entrada de solicitud sea un tipo de matriz y desee manejar esta matriz utilizando métodos de recopilación.

Por ejemplo, tiene un punto final que espera una matriz de usuarios y desea filtrar esos usuarios para tener solo aquellos usuarios que tienen una puntuación superior a 1000 y para hacerlo, tendrá que usar la matriz O recopilar ayuda que convertirá una matriz a la colección y luego utilizará el asistente de solicitud para recuperar la matriz del usuario entrante de la matriz del usuario de la solicitud. Entonces tenemos que usar el método de filtro y proporcionar un cierre para filtrar los resultados.

Route::get(‘/’, function () {

return collect(request(‘users’))

->filter(

fn($users) => $user[‘score’] > 1000

);

return view(‘welcome’);

});

Con el nuevo método de recopilación podemos lograr lo mismo de una manera más eficiente y con un código más fluido. Entonces, en lugar de usar el asistente de recopilación, llamaremos a request collect y luego proporcionaremos el nombre de la clave, veamos en el código

Route::get(‘/’, function () {

return request()->collect(‘users’)

->filter(

fn($users) => $user[‘score’] > 1000

);

return view(‘welcome’);

});

También podemos usar el método de recopilación sin ningún argumento y devolverá toda la entrada de la solicitud en forma de recopilación. Es una característica interesante que nos permite escribir un código que es más legible y más fácil de escribir, ¿qué le parece?

Route::get(‘/’, function () {

return request()->collect(‘users’)

->filter(

fn($users) => $user[‘score’] > 1000

);

return view(‘welcome’);

});

También podemos usar el método de recopilación sin ningún argumento y devolverá toda la entrada de la solicitud en forma de recopilación. Es una característica interesante que nos permite escribir un código que es más legible y más fácil de escribir, ¿le gusta esto?

Afirmar que un modelo no se eliminó temporalmente

Tenemos una adición al componente de prueba de Laravel Framework. En la versión anterior de laravel teníamos ayudantes de prueba que nos permiten afirmar que un modelo dado fue eliminado temporalmente. Los modelos eliminados temporalmente no se eliminan de la base de datos, sino que se marcan como eliminados cuando los recupera mediante consultas elocuentes. Actualmente, o en Laravel 8.62, hay un nuevo método que nos permite afirmar que el modelo dado no se elimina temporalmente. Por ejemplo, una clase de modelo de usuario en la que hemos agregado el rasgo SoftDeletes para que SoftDelete sea capaz y agregado una columna deleted_at en la migración y luego en la prueba.

/**

* @test

*/

public function testBasicDelete()

{

$user = User::factory()->create();

$user->delete();

$this->assertSoftDeleted();

$user->restore();

$this->assertNotSoftDeleted();

}

4. Actualizar las bases de datos de forma perezosa entre pruebas

Tenemos otra adición sorprendente al componente de prueba de laravel. Es una característica nueva que nos permite actualizar la base de datos solo entre las pruebas, si las pruebas requieren comunicación con la base de datos.

Con el rasgo antiguo i-e RefreshDatabase

Actualiza el estado de la base de datos entre pruebas, por lo que cada prueba se ejecuta con una base de datos nueva. El problema con este rasgo es que actualiza la base de datos antes de cada prueba, incluso si esa prueba no interactúa con la base de datos en absoluto. Y debido a este inconveniente, las pruebas toman más tiempo del que deberían. Pero con la llegada del rasgo LazilyRefreshDatabase, la base de datos solo se actualizará antes de una prueba, si esa prueba requiere interacción con la base de datos. Si la prueba no interactúa con la base de datos, la base de datos no se actualizará en absoluto. Esta característica mejorará mucho el rendimiento de la prueba.