noNameWEB/livewire-material
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Inline the error layout's own rules beside the app's build

Browse Source 
Plan step 46, from SealShare's breakpoint walk: an application imports
the stylesheets its own views render, and none renders the error layout,
so under a real build its 403/404/500 pages drew unstyled. With a build
the page now keeps the app's Vite tags (foundation, tokens, scheme, font)
and inlines Stylesheets::bundle() of components/error-page.css and its
imports beside them (ErrorPage::layoutStyles(), cached). Without a build
the fallback is unchanged. An application imports nothing for its error
pages; one that imports all.css gets the same layered rules twice, which
is harmless.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Andreas Reinhold / reini
2026-09-15 16:10:01 +02:00
co-authored by Claude Opus 5
parent 05f115ab36
commit 70c983b7bb
8 changed files with 194 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
resources/views/error-pages/errors/minimal.blade.php
+15 -9
View File
@@ -12,15 +12,20 @@
`actions` the buttons; by default a filled Home and, when the visitor came from a page on
the way here, a text Back.
The app's own Vite entries (`livewire-material.showcase.vite`) bring its scheme, font and
the package's stylesheets, including this layout's own,
resources/css/components/error-page.css. But an error page is also what shows while a deploy
has no build yet, so when those tags cannot be made the page brings a stylesheet built in PHP
instead: the foundation and this layout's own rules, `Stylesheets::bundle()`-inlined rather
than copied by hand, plus the app's scheme from its scheme data in the same selector shape
`material:scheme` writes (`src/Support/ErrorPage.php::fallbackStyles()`). The two paths draw
the same `data-md-error-*` hooks by construction, nothing to keep in step by hand. The shape
turns once a minute, unless the visitor asks for reduced motion. --}}
The page carries its own component rules, so an application imports nothing for it: its CSS
entry imports the stylesheets its own views render, and none of them renders this layout.
With a build, the app's own Vite entries (`livewire-material.showcase.vite`) bring the
foundation, tokens, scheme and font, and a `<style data-md-error-styles>` beside them inlines
this layout's own resources/css/components/error-page.css with the button and shape
stylesheets it imports (`ErrorPage::layoutStyles()`, `Stylesheets::bundle()`, cached). An app
whose entry imports them too (`all.css`) gets the same layered rules twice, which is harmless:
the second copy repeats the first, in the same layers. But an error page is also what shows
while a deploy has no build yet, so when those tags cannot be made the page brings a
stylesheet built in PHP instead: the foundation and this layout's own rules, inlined the same
way rather than copied by hand, plus the app's scheme from its scheme data in the same
selector shape `material:scheme` writes (`src/Support/ErrorPage.php::fallbackStyles()`). The
two paths draw the same `data-md-error-*` hooks by construction, nothing to keep in step by
hand. The shape turns once a minute, unless the visitor asks for reduced motion. --}}
@php
$assets = \NoNameWeb\LivewireMaterial\Support\ErrorPage::assets();
@@ -40,6 +45,7 @@
@if ($assets !== null)
{{ $assets }}
<style data-md-error-styles>{{ \NoNameWeb\LivewireMaterial\Support\ErrorPage::layoutStyles() }}</style>
@else
<style data-md-error-fallback>{{ \NoNameWeb\LivewireMaterial\Support\ErrorPage::fallbackStyles() }}</style>
@endif