Slim Facades Laravel Package

Getting Started

Install the package and register the container the facades should resolve from:

composer require itsgoingd/slim-facades

require __DIR__ . '/vendor/autoload.php';

$app = new \Slim\App($settings);

// Point the facades at the Slim container. Do this once, before
// any facade call is made.
\SlimFacades\Facade::setFacadeContainer($app->getContainer());

$app->get('/', function ($request, $response) {
    return \SlimFacades\Response::write('Hello world');
});

Where to look first:

• The facade classes themselves (src/*Facade.php or similar). Each one exposes a getFacadeAccessor()-style method that names the container key it proxies (view, router, logger, request, response, …). That mapping is the real API surface — read it before assuming a method exists.
• The package README for the exact bootstrap call (setFacadeContainer) and the list of bundled facades (App, Container, Request, Response, Router, View, Log).
• Your own container definitions, so you know which keys the facades will resolve and which still need to be registered.

First realistic use case: you have a Slim 3 app whose container holds view, router, logger, and you are tired of threading $this->get(...) or $container->get(...) into every helper, template function, and middleware. Replace a single call — e.g. Router::pathFor('user.show', ['id' => 1]) inside a Twig template or a small helper — and confirm it resolves through the container before converting more call sites.

Implementation Patterns

URL generation in templates and helpers. The most common day-one win. Named routes stop needing the router injected everywhere:

// in a Twig function / view helper / middleware
$url = \SlimFacades\Router::pathFor('user.show', ['id' => $user->id]);

Rendering responses. Facades are handy where you do not already have $response in scope, or where a service returns a response-like payload:

return \SlimFacades\Response::withJson($payload);
return \SlimFacades\Response::withRedirect(\SlimFacades\Router::pathFor('login'));

Request access from services. Injecting Request into every small collaborator is noisy. For leaf helpers (formatters, validators, view extensions) Request::getParam(...), Request::getQueryParam(...), Request::getAttribute(...) keeps signatures clean:

class CurrentUser
{
    public function id()
    {
        return \SlimFacades\Request::getAttribute('user_id');
    }
}

Logging. If logger (Monolog) is registered in the container, Log::info(...) / Log::error(...) works anywhere without injection — useful in exception handlers and small domain services.

Container access as an escape hatch. Container::get('foo') / Container::has('foo') when you genuinely need lazy resolution, e.g. inside a closure registered before the container is fully built.

Custom facades. The intended extension point is subclassing the base facade and pointing the accessor at your own container key:

class Mailer extends \SlimFacades\Facade
{
    protected static function getFacadeAccessor()
    {
        return 'mailer'; // key in the Slim container
    }
}

\SlimFacades\Mailer::send($message);

This is the pattern to prefer over Container::get('mailer') sprinkled through code — it gives you autocompletion, one place to change the key, and a seam for tests.

Wiring order matters. Register your services (view, logger, mailer, …) on the container, then call setFacadeContainer, then define routes/controllers that use facades. Middleware that runs before the facade bootstrap will not have facades available.

Gotchas and Tips

• Slim version. This package targets Slim 3 and its container. Slim 4 changed the app/container relationship (PSR-11 container passed to App, no getContainer() on the app), so do not assume the same bootstrap works on Slim 4 — verify before planning an upgrade.
• Facades reflect what is in the container, not what was passed to the route callable. Slim 3 calls your route with ($request, $response), and those may be different instances from the container's request/response entries after middleware. Mutating via Response::... inside a route will often not affect the response you return. Prefer the $request/$response arguments when they are in scope; use the facade only where you legitimately cannot.
• Missing container keys throw. View, Log, Router fail if the corresponding key is not registered. Register view/router/logger before touching those facades, and add a smoke test that calls each facade you rely on.
• Bootstrap before use. Calling any facade before setFacadeContainer is set will fail hard. Put the bootstrap immediately after container construction, and mirror it in your test bootstrap so tests exercise the same static state.
• Static state and tests. Facades are global; container resolution is effectively a singleton. Unit tests need to reset the facade container per test (or run through a fully-wired bootstrap). Do not let facades leak between tests.
• Debugging resolution. If a facade returns something unexpected, check getFacadeAccessor() on the facade class and then dump the container key directly ($container->get('view')). The facade is almost always a thin proxy; the bug is usually in the container definition.
• Prefer constructor injection in core domain code. Use facades at the edges — routes, templates, middleware, small helpers — and keep services explicit. The temptation to call Request::... deep in a domain class is the main maintainability trap with any facade package.
• Extension over hard-coding. When you find yourself calling Container::get('some-key') in more than one place, promote it to a custom facade subclass so the key lives in one location.