Wire Modals Laravel Package

Product Decisions This Supports

• Build vs. buy for modal/dynamic-component plumbing. If multiple surfaces in your app hand-roll component loading, parameter passing, and modal state, this package is a candidate to consolidate that code. The relevant decision is whether your in-house loader is a differentiator (it almost never is) or accumulated glue you should retire.
• Roadmap sequencing for a migration epic. The new docs/sylloo-migration-prompt.md describes a two-phase path — adopt in legacy mode first, then modernise. That de-risks a "migrate our modal loader" line item into two separately shippable increments rather than one big-bang refactor, which is a materially better roadmap shape for stakeholder planning.
• Onboarding and enablement cost estimates. A written, step-by-step migration guide is the artifact that turns "we should adopt this" into an estimate you can defend. It reduces the unknown in an engineering spike and shortens the time-to-first-merged-PR.
• Use-case fit: authenticated app shells with many entry points. Modals driven by dynamic parameters (edit forms, confirmations, detail drawers) are the sweet spot. If your product is API-first or your modals are purely static Blade partials, this is not a decision this package informs.
• Confidence caveat for the PM. The only evidence for this release is one documentation file. Nothing in it changes runtime behaviour, so this release should not shift a build-vs-buy verdict on its own — it lowers adoption cost, not technical risk. Treat the assessment as provisional and re-evaluate once you have release history covering actual code changes.

When to Consider This Package

Adopt-consideration criteria:

• You are on Laravel + Livewire and already use server-driven modals opened from multiple components.
• You have a hand-rolled dynamic component loader — the explicit target of the new migration guide — and it is being maintained by more than one person or has grown implicit conventions.
• You want an incremental migration path: the documented legacy-mode-first approach means you can adopt without rewriting every call site in one release cycle.
• You value documented upgrade paths over feature breadth; a maintainer who ships migration guidance is signalling they intend the package to survive its own API changes.
• You need parameterised modal payloads passed from the caller rather than hardcoded partials.

Look elsewhere when:

• You are not on Livewire, or your UI is client-rendered (Inertia/Vue/React) — the abstraction does not apply.
• You use a single global modal instance with trivial content; the indirection is not worth a dependency.
• You require a stable, versioned API contract with a track record. Evidence here is a 1.0.x line and a docs-only patch; you cannot yet infer the maintainer's breaking-change cadence.
• You need accessibility, focus-trap, and keyboard semantics guaranteed by the package. Nothing in the release notes speaks to this — verify directly before committing.
• Your team cannot absorb a two-phase migration (legacy mode, then modernisation). The guide is an asset only if you actually schedule the second phase; otherwise you are adopting a temporary shim permanently.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk consolidation of UI plumbing — the code that opens and populates modals across the app. The value is not new customer-facing capability; it is reduced maintenance surface and fewer bespoke conventions for engineers to learn. The latest release adds no runtime code, only a migration playbook, which is precisely what makes the switch plannable: we can move in two stages rather than freezing a release for a refactor. Recommend a timeboxed spike, not a committed roadmap item.

To engineering: The 1.0.1 release ships docs/sylloo-migration-prompt.md — a step-by-step guide for moving an app off a hand-rolled dynamic component/modal loader. Read it before estimating. It prescribes legacy mode first, then modernisation, so you can land adoption behind existing behaviour and defer the cleanup. No breaking changes, no code changes, no action required for anyone already on 1.0.0. Two caveats to resolve during the spike: confirm accessibility behaviour (focus management, escape handling) is handled or documented, and confirm the maintainer's intent for the legacy-mode deprecation window — otherwise your temporary shim has no exit date.