Share Laravel Package

Product Decisions This Supports

• Distribution / growth-loop decisions. The package wraps the native Web Share API behind Blade-friendly data-share-* attributes, so "add sharing" becomes a near-zero-cost roadmap item rather than a platform engineering project. This directly supports decisions about referral links, invite flows, and organic reach on mobile.
• Share-as-a-feature vs. share-as-a-link. v1.1.0's ->file() support plus capability-gated native buttons turns sharing from "copy a URL" into "send the actual artifact" — a materially different product promise for tickets, invoices, receipts, exported reports, media, and generated documents. This is a scope decision worth making explicitly: do we share a pointer or the payload?
• Surface selection. The new data-share-open="sheet-id#section-id" deep-link means a share can land a recipient inside a specific sheet section. That supports decisions on whether shared destinations are generic landing pages or contextual entry points (support articles, onboarding steps, product detail) — which affects activation and support-deflection metrics.
• Progressive enhancement as a default posture. Because buttons render only where the device can actually share files, the package encodes a "no dead buttons" UX policy. That becomes a reusable product principle across other device-dependent features.
• Build vs. buy. The Web Share API looks trivial until you account for navigator.canShare({files}) checks, per-platform file-type and size variance, browser fallbacks, and rendering consistency in server-rendered Blade. Maintaining that matrix in-house is ongoing toil with no differentiation; consuming a maintained wrapper is the cheaper call.
• Roadmap sequencing. File sharing and section deep-links are additive and non-breaking, which means they can ship in a normal increment without a migration or comms plan — useful when deciding what fits in the next cycle versus what needs a dedicated release.

When to Consider This Package

Adopt when most of these hold:

• Your audience is meaningfully mobile/touch-first (web app, PWA, or a Laravel app with heavy phone traffic) — native share sheets are where users already expect them.
• You have a Blade/SSR stack and want sharing wired with markup attributes rather than a JS framework or bespoke front-end work.
• Your shareable objects are links, and increasingly files — tickets, PDFs, invoices, exports, images. v1.1.0 makes files a first-class case.
• You want graceful degradation for free: hidden-where-unsupported behavior removes the need to hand-maintain capability detection.
• You need deep-linked destinations (open a sheet at a section) for support or onboarding content.
• You want no new infrastructure — no backend share service, no third-party SDK, no new vendor in the security review.

Look elsewhere when:

• Traffic is desktop-dominant (especially Firefox/older desktop browsers), where Web Share API coverage is thin; hidden buttons may mean your primary channel shows nothing.
• You need server-side or guaranteed multi-channel sharing (email/SMS send, scheduled shares, share-link expiry, recipient tracking). This is a client-side invocation layer, not a sharing backend.
• You need per-platform social SDK behavior or rich preview control — Open Graph/Twitter card generation and social-specific analytics are a different concern.
• You need share-level analytics as a hard requirement. Client-side invocation is inherently hard to attribute; plan your instrumentation or budget for a fallback event path.
• You require strict no-JS functionality or have a hard dependency-minimization policy for small utilities you could own.

Practical adoption checks a PM should insist on:

• A fallback CTA wherever a share button may be hidden (copy link, email), so discoverability doesn't silently drop on unsupported devices.
• Test matrix covering iOS Safari, Android Chrome, and at least one unsupported desktop browser, including file-type/size limits.
• Instrumentation plan — a click event on the share affordance, not just a completion callback, so you can measure adoption even where the sheet never opens.
• Accessibility pass on attribute-driven buttons and the section-scroll behavior of deep links.

How to Pitch It (Stakeholders)

For executives: This is a low-cost distribution lever. It lets users share our content — and now the actual files we generate — through the share sheet they already use, with no new vendor, no new infrastructure, and no additional security surface. The latest release is additive and non-breaking: file sharing and deep-linking to a specific section of a share, both of which extend the same primitive we already have rather than opening a new workstream. It's a candidate for a normal increment, not a dedicated project.

For engineering: It's a thin, opinionated wrapper over the Web Share API, driven by data-share-* attributes in Blade, with capability gating built in — buttons render only where the device can actually fulfill the share, including canShare({files}) for file payloads added via ->file(). v1.1.0 adds file payload support to native buttons and a "Share the file" action in the sheet, plus data-share-open="sheet-id#section-id" for open-and-scroll deep links. No front-end framework coupling, no migration, no breaking changes. The work on our side is the fallback path, the browser/device test matrix, and click-level instrumentation.