Skip to main content

View trees

Two view trees ship, and you pick one in configuration.

Plain (the default) is framework-free: one small stylesheet, no Tailwind, no build step. @include('visual-feedback::style') in your layout is all it needs, and every color is a --vf-* custom property you can override to match your app.

That includes the success tone the widget uses to confirm a sent report and an attached screenshot: --vf-success, which ships at 5.02:1 against the light surface and 8.42:1 against the dark one, so both clear the 4.5:1 floor for body text. Override it if your palette wants a different green — and keep the contrast, because the check mark beside the sentence is decorative. The words carry the meaning, never the color alone. On the WireKit tree the same two lines take the kit's own --color-wk-success-text instead.

WireKit renders the same widget with WireKit components, so it inherits your design tokens. Choose it with one key:

// config/visual-feedback.php
'ui' => [
    'variant' => 'wirekit',   // auto | plain | wirekit
],

Or leave it at the shipped auto, which serves the WireKit tree when a new enough WireKit is installed and the framework-free tree when it is not — so an application that has WireKit gets the token-styled widget without configuring anything.

A WireKit installed from a branch counts as new enough: dev-develop, or an alias such as 2.x-dev, is the newest state of the kit rather than an old one. And when auto does fall back because the installed WireKit is older than the floor below, it says so in your application log, with the version it found, instead of switching trees without a word.

With the WireKit tree you do not get the plain stylesheet, and you no longer have to remember that: visual-feedback::style withholds it while that tree is being served. Keep the include anyway — it is not a no-op there. It renders a small block for the WireKit tree: the vertical rhythm between field groups, the flex row under the screenshot preview, the danger box around a refusal, and the honeypot's concealment rule. Every value is read from a WireKit token, colors included (--color-wk-danger-text, --color-wk-text-muted), so a theme change moves the widget with it and nothing here can fight your own design. The --vf-* palette is not in this tree at all.

caution
A published template outranks ui.variant, including one you published by accident

Laravel resolves a view from resources/views/vendor/visual-feedback before any path a package registers, and that is deliberate — it is what makes publishing the way to edit these templates. It also means the umbrella install, vendor:publish --tag=visual-feedback, copies the plain templates there, and from that moment they serve no matter what ui.variant says.

So if you ran the umbrella publish and expected the WireKit tree, you are on the plain one. Two ways out, and they are different decisions rather than two spellings of the same one:

  • Publish the WireKit tree over it — vendor:publish --tag=visual-feedback-wirekit --force — if you meant to edit these templates. You then maintain that copy.
  • Delete resources/views/vendor/visual-feedback if you did not, and let ui.variant choose again. Nothing else in the umbrella tag lives there; the assets publish separately.

The stylesheet follows the tree that actually resolves rather than the one configured, so a published plain widget is styled either way. That was not always true: up to and including 0.4.0 it read the configured answer and rendered nothing here, which left this exact install with an unpositioned trigger and an unstyled dialog.

The visual-feedback-wirekit publish tag still exists and still overwrites the plain stubs, which is why it is not part of the umbrella tag. Its job is different now, and smaller: publish when you want to EDIT these templates. Publishing to merely SELECT the tree meant keeping a copy of them in your application, and a copy is what package updates leave behind.

Three practical notes, none of which is guessable from the tag name:

  • WireKit has to be installed. This package does not require it — it is a suggest, so a lean install never drags a component library in — and the published views render real <x-wirekit::modal>, <x-wirekit::card> and <x-wirekit::fab.button> tags. Publish this tree without the package and every page carrying the widget throws on the first tag.

  • Nothing in the layout changes — including the stylesheet include. @livewire('visual-feedback.report-widget'), <x-visual-feedback::scripts /> and @include('visual-feedback::style') all stay exactly as they are.

    That last one used to say the include had to go, and removing it is the thing to avoid. The stylesheet carries the same switch the tree does and renders nothing while the WireKit tree serves, so leaving it costs a page nothing — and it keeps the plain tree styled if you ever set ui.variant back, uninstall WireKit, or publish over it. One thing genuinely depends on it: the honeypot's concealment rule lives in that stylesheet, so a layout without it needs the rule written by hand.

  • To switch back, delete the published widget views under resources/views/vendor/visual-feedback/ and publish visual-feedback-views again. There is no un-publish command, in this package or in Laravel.

WireKit 2.21 or newer

A floor, not a preference. The WireKit tree builds its floating trigger from <x-wirekit::fab.button>, using the placement prop and the accessible-name path that release introduced. On an older WireKit the trigger lands in the wrong corner and announces nothing to a screen reader — and because the tree is published into your application, nothing at install time can stop you. Check the installed version.

Two things read differently in this tree, both deliberate:

  • The trigger is an icon button, where the plain tree's is a text button. That is the point of the tree — it looks like your design system. Its accessible name is the widget heading either way.
  • ui.position is logical here. bottom-right follows the writing direction, so a right-to-left application mirrors it; the plain tree keeps the physical reading. In any left-to-right application the two agree exactly.