livewire-material/src/Support/ErrorPage.php

<?php

namespace NoNameWeb\LivewireMaterial\Support;

use Illuminate\Contracts\Support\Htmlable;
use Illuminate\Foundation\Vite;
use Illuminate\Support\HtmlString;
use Throwable;

/**
 * What the error layout needs from PHP, written so that nothing in it can fail the page: an
 * error page is shown precisely when something else already went wrong.
 *
 * The page carries its own component rules whatever the application imports. An application's
 * CSS entry imports the stylesheets of the components its own views render, and no view of its
 * renders this layout — the framework does, from the package's error-view root — so nothing ever
 * told an application to import `components/error-page.css`: `DesignGuard::missingStylesheets()`
 * reads the application's views, not the package's, and `unusedStylesheets()` would call such an
 * import unused. So an application imports nothing for its error pages: with a build the layout
 * takes the foundation, tokens, scheme and font from the application's Vite tags (`assets()`) and
 * inlines its own rules beside them (`layoutStyles()`); without one it inlines everything
 * (`fallbackStyles()`).
 */
class ErrorPage
{
    /**
     * The application's Vite tags, or null when they cannot be made. They bring the foundation,
     * the tokens, the scheme and the font; the layout's own rules come from `layoutStyles()`
     * beside them, since the application's entry need not import them.
     *
     * A 500 during a deploy is the moment the manifest is missing, half-written or names files
     * that are not there yet — a missing manifest throws a ViteException, a truncated one a
     * PHP warning turned exception — so every failure means "no build", never a second error.
     */
    public static function assets(): ?Htmlable
    {
        try {
            $tags = app(Vite::class)(config('livewire-material.showcase.vite', []));
        } catch (Throwable) {
            return null;
        }

        return $tags instanceof Htmlable ? $tags : new HtmlString((string) $tags);
    }

    /**
     * Where the Back button goes: the page the visitor came from, when there was one other than
     * this page and the home page Home already offers. Null when the session behind it cannot
     * be read.
     */
    public static function backUrl(): ?string
    {
        try {
            $previous = url()->previous();
            $current = url()->current();
        } catch (Throwable) {
            return null;
        }

        $isHome = rtrim($previous, '/') === rtrim(url('/'), '/');

        return $previous === $current || $isHome ? null : $previous;
    }

    /**
     * The error layout's own rules for a page with its build: `components/error-page.css` and the
     * stylesheets it imports, prebuilt into resources/dist/error-page.css (`npm run
     * build:stylesheets`) and inlined beside the application's Vite tags, which bring everything
     * else.
     *
     * Nothing is dropped from it, because nothing in it needs a build: the package's only
     * `@font-face` is `tokens/font.css`'s, which only the foundation reaches and the application's
     * build serves, and no stylesheet the layout imports writes a `url()` a request would have to
     * resolve (tests/Feature/ErrorPagesTest.php checks both). An application whose entry also
     * imports this layout (through `all.css`, say) gets the same rules twice, in the same layers and
     * with the same declarations; the second copy decides nothing the first had not, so that is
     * harmless.
     */
    public static function layoutStyles(): HtmlString
    {
        return new HtmlString(self::dist('error-page.css'));
    }

    /**
     * A stylesheet for a page without its build: the foundation and the error layout's own rules,
     * prebuilt into resources/dist/error-page-fallback.css — the same inlining a Vite build does,
     * so the fallback can never drift from `resources/css/components/error-page.css` the way a
     * hand-written copy did, and without the `@font-face` (there is no build here to serve the font
     * file; the brand typeface's stack in tokens/type.css falls back to the system fonts) — with
     * the application's colours appended in `material-scheme.css`'s own shape
     * (`SchemeStylesheet::withProfiles()`): the standard level, the medium and high contrast levels
     * under `[data-contrast]`, and a block per colour profile under `[data-scheme]`, built from
     * `Scheme::forStylesheet()` on every call. `<x-theme-script>` has already written
     * `data-theme`, `data-contrast` and `data-scheme` onto `<html>` by the time this tag is parsed
     * (it renders first), so the browser resolves the right block on its own — nothing here decides
     * an active profile in PHP.
     */
    public static function fallbackStyles(): HtmlString
    {
        return new HtmlString(self::dist('error-page-fallback.css').SchemeStylesheet::withProfiles(...Scheme::forStylesheet()));
    }

    /**
     * A prebuilt stylesheet under resources/dist/.
     */
    protected static function dist(string $file): string
    {
        return (string) file_get_contents(dirname(__DIR__, 2)."/resources/dist/{$file}");
    }
}