Liveupdate Laravel Package

Getting Started

Step 0 — confirm what you actually installed (half a day, non-negotiable). The intake record contradicts itself: the composer name wehaa/liveupdate and its description describe a broadcasting/Blade live-refresh helper, the repo URL wehaa/inline-field-update and top-line description say "a Laravel Nova field," and the only release note (v0.3.2 — "Return an empty array if validation rules do not exists") reads like a validation-utility fix. Do not write a line of product code until you have resolved this:

git clone https://github.com/wehaa/inline-field-update
cd inline-field-update && git checkout v0.3.2
cat composer.json                 # require / require-dev / extra.laravel.providers
find src resources -type f | head -50
wc -l src/**/*.php resources/js/**/*.vue   # LOC decides fork-vs-depend later

The shape of composer.json tells you immediately: a require on laravel/nova plus a src/*.php class extending Laravel\Nova\Fields\Field means Nova field. A ServiceProvider with Event::listen / broadcastOn means the broadcast reading. Write the one-page answer down; everything below is conditional on the Nova-field reading, which matches the repo name.

Install pinned, never floating.

composer require wehaa/liveupdate:0.3.2   # exact, no caret

If the tagged artifact ships a dist/ folder, you are done. If it only ships resources/js sources, you must build assets yourself inside the vendor path (or fork and build) — see Gotchas.

First use case: one inline-editable text field on one internal Nova resource. Not a dashboard, not a table of ten editable columns. Pick a resource where an operator currently clicks View → Edit → Save → Back to change a single value — a status note, an internal SKU, a display name. That is the exact workflow this package claims to compress, and it is the cheapest possible pilot.

Where to look first when something is wrong: the field's PHP class under src/ (how it resolves the value and what it declares for rules/authorization), then resources/js/components/*.vue (what HTTP call the save actually makes — this is the single most important thing to read, because it determines whether Nova policies apply), then the network tab.

Compatibility smoke test before the pilot. Register the field on a throwaway resource on a branch and exercise four paths end-to-end: happy-path save, validation failure, authorization denial (log in as a user whose Nova policy says update => false), and a read-only/canSee => false view. The denial test is the one most likely to fail and the most expensive to discover in production.

Implementation Patterns

Attach the field to a resource like any other Nova field, and wrap it so the package name appears in exactly one file in your codebase:

// app/Nova/Fields/InlineText.php — your adapter, the only place the package is named
namespace App\Nova\Fields;

class InlineText extends \Wehaa\LiveUpdate\InlineField   // confirm exact class from src/
{
    public function __construct($name, $attribute = null, $resolveCallback = null)
    {
        parent::__construct($name, $attribute ?? $name, $resolveCallback);
        // pin package defaults here so an upstream swap is a one-file change
    }
}

// app/Nova/Order.php
public function fields(NovaRequest $request): array
{
    return [
        ID::make()->sortable(),
        Text::make('Reference'),
        InlineText::make('Internal Note', 'internal_note')
            ->rules('nullable', 'string', 'max:255')
            ->help('Edit inline from the index table'),
    ];
}

Understand which of the two components you are activating. Nova fields expose three Vue components: FormField (create/update screen), DetailField (read-only detail screen), and IndexField (the index table row). "Inline field update" almost certainly means IndexField — click a cell, edit in place, save without navigation. Confirm the package implements IndexField; if it only ships FormField, you have bought nothing over the built-in Text field and the use case evaporates.

Save-on-blur / save-on-enter, not save-on-keystroke. Debounce the blur handler and show a per-cell saving/error state. The interaction contract that makes inline editing a win rather than a hazard is: the cell reverts to the server value on failure and shows an inline error message. Never optimistically show a new value the server rejected.

Route the write through Nova's own update endpoint. A Nova resource update is PUT /nova-api/{resource}/{resourceId} with the Nova request payload. If you (or the package) post to a bespoke controller instead, you inherit every responsibility Nova normally handles — authorization policies, field-level canSee/readonly, validation, and model event dispatch. If you must use a custom endpoint, do it explicitly and defensively:

// Only if the package's own write path doesn't go through Nova
Route::put('/api/inline/{resource}/{id}', function (Request $request, $resource, $id) {
    $model = Nova::modelInstanceForKey($resource)::findOrFail($id);
    Gate::authorize('update', $model);                       // Nova policy, explicit
    $request->validate(['value' => ['required', 'string', 'max:255']]);
    $model->update([$request->input('field') => $request->input('value')]);  // fires observers
    return response()->json(['value' => $model->fresh()->{$request->input('field')}]);
});

Keep model events flowing. The point of going through $model->update() is that updated fires and your audit log, search indexer, and downstream sync keep recording admin changes. If inline edits silently bypass observers, you have introduced a data-integrity drift between the admin panel and reporting — the failure mode is discovered weeks later.

Wrap it in a regression test that assumes nothing about the package's internals. Hit the HTTP surface, not the PHP class:

it('rejects an inline update from a user without update policy', function () {
    $order = Order::factory()->create(['internal_note' => 'original']);
    $user  = User::factory()->create();          // no Nova update permission

    $this->actingAs($user)
         ->putJson("/nova-api/orders/{$order->id}", ['internal_note' => 'hacked'])
         ->assertForbidden();

    expect($order->fresh()->internal_note)->toBe('original');
});

If the broadcast/Blade reading turns out to be the real product, the pattern is the standard Laravel one — the package broadcasts on a model event over your configured driver, and your Blade view listens with Echo:

@push('scripts')
<script>
Echo.private(`orders.${orderId}`)
    .listen('.updated', () => window.Livewire?.dispatch('$refresh')
        ?? document.getElementById('order-panel').dispatchEvent(new Event('refresh')));
</script>
@endpush

Verify the channel authorization callback in routes/channels.php actually restricts to the owning tenant before you ship this — an over-broad private channel is a data leak, not a UI bug.

Gotchas and Tips

The identity ambiguity is the first gotcha and it invalidates every other assumption. Three documents describe three products. Until you have read composer.json and the source tree at the exact tag, treat every capability claim — including the ones on this page — as provisional. This alone justifies a timeboxed spike rather than a roadmap commitment.

Nova major version is the gating compatibility check, and the answer is probably "no." The package last shipped 2021-12-02, which puts it in the Nova 3 era (Vue 2, before Laravel Mix → Vite, before Nova 4's Inertia rewrite). Nova 4 and 5 reworked the field front-end contract; a Vue 2 field component will not mount against a Nova 4/5 panel. Check composer.json's laravel/nova constraint and then prove it by rendering the field — if the cell renders blank in the index table, that's the Vue 2/Vue 3 mismatch, not your code. Console errors like "Failed to resolve component" confirm it.

The v0.3.2 release note is a tell about validation handling. "Return an empty array if validation rules do not exists" means that at some point rules() returned null where Nova expected an array, and Nova choked. That edge case was reachable in the wild, which suggests the validation path was lightly covered. Test the field with no rules declared at all, with a failing rule, and with a server-side 422 — and confirm the error renders inline in the cell rather than silently no-opping while the UI shows stale data.

Authorization is the failure mode with a delayed blast radius. Test the denial path explicitly. An inline editor that writes directly through the model bypasses Nova's canSee, readonly, and policy checks. Two symptoms to watch for: a field marked readonly() still accepts edits, and a user without update permission gets a 200 instead of a 403.

Asset build is a real blocker if dist/ isn't in the tag. Nova fields built with laravel-nova + Mix need compiling. If the release ships only sources, you'll need cd vendor/wehaa/liveupdate && npm install && npm run prod, which is fragile (vendor is wiped on composer install) — fork the repo, build, and point your composer repo at the fork. This is also the moment to decide fork-and-own: at a few hundred lines under MIT, owning it is cheaper and safer than depending on an abandoned tag with zero dependents.

Zero dependents means you are the first person to hit most edge cases. There's no Stack Overflow corpus, no issue thread with your exact error, no one who has already hardened it against a Nova upgrade. Budget the debugging as first-of-a-kind time, not routine integration time.

Debugging order that actually works: (1) browser console for Vue mount/render errors — catches Vue 2 vs 3 first; (2) network tab, filter nova-api, inspect the save request payload and the response body — catches endpoint, authorization, and validation-shape problems; (3) storage/logs/laravel.log for the server-side stack; (4) only then read the package source.

Extension points are limited, so plan the exit before you need it. The adapter class above is the cheapest insurance available: if the package dies or breaks on the next Nova major, you swap one file. Cost the fallback up front — a minimal click-to-edit IndexField is roughly one to three days of work against Nova's documented custom-field API, and it's the only option that survives a Nova upgrade without archaeology. If the build really is one to three days, the spike's expected value drops sharply, and that should factor into whether you start at all.