O Laravel 11 está preparado para ser lançado no primeiro trimestre de 2024, e pode inclusivé ser já lançado no próximo mês, por isso é recomendável irmos tentando perceber quais as principais alterações que a nossa framework preferida irá ter.
Ao iniciar um novo projeto, e devido à proximidade da data de lançamento, decidi analisar o que será diferente nesta nova versão principal. Lembro-me de ter lido um artigo do Laravel News há uns meses sobre como o Http Kernel estava prestes a desaparecer e não dei muita importância na época.
Ao criar o projeto usando laravel new project --dev, fiquei bastante surpreendido com o tamanho reduzido do projeto. Foi surpreendente ver uma pasta de configuração vazia (podes publicar os arquivos de configuração com php artisan config:publish)!
E, de fato, não há mais Http Kernel. Então…
Como adicionas ou alteras middlewares no laravel 11?
Nas versões 10 e anteriores, toda a configuração de middlewares era encontrada no Http Kernel, localizado em app/Http/Kernel.php. Adicionalmente, em versões anteriores, raramente seria necessário editar o bootstrap/app.php. No entanto, não se verificará no Laravel 11.
Para ser honesto, como utilizador do Laravel desde a versão 4.2, esta é uma mudança de paradigma significativa. Em vez de um arquivo Kernel.php fácil de ler, há muito mais conhecimento implícito necessário antes de adicionar middlewares na nossa aplicação.
Qual o novo ponto de partida de uma app no Laravel 11?
O novo ponto de partida para bootstrap/app.php é o seguinte:
Estou explorando apenas o middleware neste artigo, mas, como você pode ver, esta é uma abordagem bastante diferente do que vimos nas anteriores versões. Fiquei alguns minutos em análise, “Como configuro o raio do middleware agora? Como altero as configurações padrão?” Tive que explorar a classe Illuminate\Foundation\Configuration\Middleware para descobrir.
Chamar Application::configure() retorna uma instância de Illuminate\Foundation\Configuration\ApplicationBuilder, onde em seguida chama várias funções, withProviders(), withRouting() e as funções withMiddleware(). A função withMiddleware() recebe um callable.
Usando esta metodologia, podemos adicionar novos aliases de middleware chamando alias():
function (Middleware $middleware) {
$middleware->alias([
'some_key' => \App\Http\Middleware\MyMiddleware::class,
]);
}
Depois que some_key é adicionado, podemos atribuí-lo a rotas individuais e grupos de rotas. Se quisermos adicionar o middleware a cada pedido, podemos ainda usar as funções append() ou prepend() para adicionar middleware global.
function (Middleware $middleware) { // Usando uma string $middleware->append(\App\Http\Middleware\MyMiddleware::class);
// Ou adicionando vários
$middleware->append([
\App\Http\Middleware\MyMiddleware::class,
\App\Http\Middleware\MyOtherMiddleware::class,
]);
}
Podemos remover middleware que está lá por padrão chamando a função remove().
function (Middleware $middleware) { // Usando uma string $middleware->remove(\Illuminate\Http\Middleware\ValidatePostSize::class);
// Ou removendo vários middleware padrão
$middleware->remove([
\Illuminate\Http\Middleware\TrustProxies::class,
\Illuminate\Http\Middleware\HandleCors::class,
]);
}
Podemos adicionar ou remover middleware para grupos específicos, por exemplo, o grupo web, usando as funções appendToGroup()/prependToGroup() e removeFromGroup().
function (Middleware $middleware) { $middleware->appendToGroup(‘web’, \App\Http\Middleware\MyMiddleware::class); }
Se o ficheiro bootstrap/app.php ficar um pouco confuso (o que imagino que acontecerá), podemos limpar movendo essas coisas para uma classe invokable.
Criei uma classe em app/Http chamada AppMiddleware.php. Como os velhos hábitos morrem com dificuldade, podes chamar esta classe Kernel.php 😉 …
<?php
namespace App\Http;
use Illuminate\Foundation\Configuration\Middleware;
class AppMiddleware
{
public function __invoke(Middleware $middleware)
{
$middleware->appendToGroup('web', \App\Http\Middleware\MyMiddleware::class);
}
}
Agora, em bootstrap/app.php, substitua a função anônima por uma nova instância de nossa classe invocável.
Como em todas as coisas novas, a mudança é difícil. Tenho desta forma uma pergunta constantemente no meu pensamento sobre esta mudança.
Faz sentido esta mudança tão profunda?
Temos as mesmas ferramentas e capacidades, mas é um pouco mais difícil, pelo menos no início, entender como gerir tudo.
Sinto que essa mudança exigirá um conhecimento mais profundo dos middleware integrados. Isso importa? Provavelmente não. Mas, em alguns casos, pode ser necessário remover ou substituir um middleware padrão. Isso exige que você realmente saiba o que está lá por padrão. Não apenas no middleware global, mas em grupos e middleware com alias. Pessoalmente, sinto que essa mudança aumenta a curva de aprendizagem, principalmente para quem começa agora no mundo Laravel. Até eu esqueço o que já vem por padrão ou quais são os aliases e tenho necessidade constante de consultar o ficheiro app/Http/Kernel.php.
Questiono então se a falta de verbosidade e o paradigma de ficheiros menores valem a pena?
O Que é Marketing Digital para Clínicas?Principais Ferramentas do Marketing Digital para ClínicasSEO (Otimização para Motores de Busca)Redes SociaisGoogle AdsMarketing…
One Response
vi o processo ficou mais simples você pode adicionar diretamente a classe do app
return Application::configure(basePath: dirname(__DIR__))
->withRouting(
web: __DIR__.’/../routes/web.php’,
commands: __DIR__.’/../routes/console.php’,
health: ‘/up’,
)
->withMiddleware(function (Middleware $middleware) {
$middleware->alias([‘sessao’ => \App\Http\Middleware\SessaoMiddleware::class]);
})
->withExceptions(function (Exceptions $exceptions) {
//
})->create();