- What does tanthammar/livewire-window-size do in a Laravel app?
- tanthammar/livewire-window-size is a Laravel Livewire package that exposes the browser window size and responsive breakpoints to your components. It provides Blade directives and PHP helpers so a Livewire component can decide what server-rendered markup to emit for mobile, tablet, or desktop without relying on CSS. It is a narrow presentation-layer tool, not a data-layer or infrastructure package.
- How do I install tanthammar/livewire-window-size?
- Install it with Composer using composer require tanthammar/livewire-window-size. Your Laravel application must already use Livewire and AlpineJS, because the package depends on both. After installation, use the provided Blade directives in views and the PHP helpers inside Livewire components; publish any config only if the package documentation instructs you to. The integration is mechanically small, but you still need to define breakpoint buckets and decide what the first paint should show.
- Which Laravel, Livewire, and Alpine versions does it support?
- The package requires Livewire and AlpineJS, and it is coupled to Livewire's request lifecycle. The provided context does not list exact Laravel, Livewire, PHP, or Alpine version constraints, so check composer.json before installing. Because a Livewire major version is a breaking event for this package, pin versions and test upgrades deliberately.
- How does the server know the browser window size on the first request?
- The server cannot know the viewport on the first request, so the package must establish a client-to-server feedback loop using a cookie, request header, persisted Livewire property, or an Alpine-triggered re-render. That means the initial response may render a default branch and then swap after Alpine measures the window. Verify the actual mechanism before committing, and choose a deliberately safe default branch.
- Will viewport-conditional rendering cause layout shift or hurt Core Web Vitals?
- Yes, first-render ambiguity is the highest technical risk: if content swaps after Alpine measures the window, users can see flicker and cumulative layout shift. That can hurt Core Web Vitals even though the package is pitched as a way to adapt layouts by viewport. Mitigate with a seeded signal from a previous visit or Client Hints, and test the real first-paint behavior.
- Can I cache pages or components that use viewport-based output?
- Any full-page or fragment cache key must include the viewport dimension or breakpoint bucket when output varies by window size. Otherwise a mobile layout can be served to a desktop user, and the number of cache keys multiplies by your bucket count. This is easy to miss and interacts badly with CDN invalidation.
- How does this affect SEO and mobile-first indexing?
- Mobile-first indexing means Googlebot renders at a fixed mobile viewport, so whichever branch that hits is the content Google indexes. Materially different copy or links per viewport can read as cloaking; progressive disclosure of the same core content is safer. Crawlers that never run Alpine will see your default branch, so make that branch representative.
- Does the package set cookies and do I need GDPR consent?
- The package must transmit a size signal, which may use a cookie, request header, or persisted Livewire property. The provided context does not confirm which mechanism is used or what the cookie footprint is, so audit the implementation before relying on it. If a cookie is set, assess consent requirements under GDPR and ePrivacy with your legal team.
- How do I test viewport-conditional Livewire output in CI?
- Testing viewport-conditional output in CI requires simulating the size signal across integration and end-to-end layers. You cannot rely only on a unit test that calls the PHP helper; you need to assert the first render, the post-measurement render, and the default path when no signal exists. Budget time for this, because it will not be free.
- Is tanthammar/livewire-window-size actively maintained and production-ready?
- Treat it as a small, single-maintainer package: the context notes 23 stars, zero dependents, and no third-party audit, so production validation at scale is limited. A Livewire major release is a breaking risk, but the MIT license and small surface area make vendoring or forking realistic. If you only need to hide content, CSS media queries or Alpine x-show are simpler alternatives; this package matters when you genuinely must not send markup.