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.

The warning tone frames a screenshot you captured but have neither attached nor discarded: --vf-warning, a 1px border that ships at 5.02:1 against the light surface and 6.83:1 against the dark one, above the 3:1 a boundary needs. The sentence at the end of the form still says what is open; the border shows where. On the WireKit tree the border takes --color-wk-warning-text.

The corners have two properties of the same kind: --vf-radius rounds the panels, the widget's dialog and the report browser's detail pane, and --vf-radius-control rounds what sits inside them, the fields, the buttons, the status boxes and the previews. Both scales apply to the widget and the report browser alike, so one override changes both.

WireKit renders the same widget with WireKit components, so it inherits your design tokens, and WireKit's supported browsers with them. Those follow Tailwind CSS v4: at WireKit 2.63 that is Chrome and Edge 111, Safari 16.4 and Firefox 128. 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: while the WireKit tree serves it renders a smaller sheet rather than the plain tree's, with the layout design tokens do not cover, such as the spacing between field groups, the screenshot preview and its status, the required-field legend and the honeypot's concealment rule. Without the include, <x-visual-feedback::scripts /> emits the sheet itself at the end of the body, where it can flash unstyled, and logs a warning that names the missing line. Keeping it also keeps the plain tree styled if you ever set ui.variant back, uninstall WireKit, or publish over it.

  • 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.68 or newer

A floor, not a preference: 2.68 is the oldest release this version supports. From 2.66 a soft button takes the shade of the surface it stands on, so the tree's soft buttons read as buttons in the report dialog and in a hovered row of the report browser. Every field of the WireKit form explains itself beside its label, which WireKit renders from 2.64. The report browser pages its list with <x-wirekit::pagination>, and 2.51 is the release whose pager turns pages inside a Livewire component, so a page turn keeps the filters. The report dialog is a <x-wirekit::modal>, and 2.50 is the release whose panel is a column: on an older WireKit a dialog taller than the screen loses its header and its close button on a small device, and before 2.49 the floating trigger also sits closer to the bottom edge than to the side. ui.variant = auto serves the plain tree below 2.68. A forced wirekit or a published tree gets no such check, because nothing at install time can stop you — check the installed version.

One thing reads differently in this tree, and it is 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.

The corner does not differ. ui.position follows the writing direction in both trees, so a right-to-left application mirrors the trigger whichever tree serves it.