Design patterns for (optimistic) updates of items in a list

[miking7]

In Taylor Otwell's Keynote at Laracon US 2024 he demoed Inertia V2 asynchronous updates using a list of switch UI elements.

I'm struggling to find any documentation, demos, tutorials, etc for a design pattern to implement something like this in practice.

Here's my current assumptions:

• I'm guessing the toggle switches would have been implemented by wrapping a custom-styled checkbox - ie: <Link ... as="checkbox">
• This would explain the use of the checked property in the data: { checked: !checked } property definition
• A checkbox could potentially explain how the UI was able to optimistically show updates... unless he was somehow optimistically mutating the front-end state in a click-handler.
• The Inertia docs indicate that the POST/PUT/PATCH/DELETE requests in such cases should redirect back to the index page.
• Redirecting back to the index page presumably provides a simplistic way to ensure any optimistic UI changes are reverted on any errors / failures in the back-end, but reloading the main index route results in...
  • increased network traffic, db queries, performance hits, etc
  • does not seem to be compatible with other smart Inertia V2 capabilities such as infinite scrolling (since all pages would need to be reloaded)

My actual use-case is more complicated than the simple toggle switches demonstrated by Taylor. It doesn't require optimistic UI updates, but will likely require the use of the manual visits using router.put() methods, combined with partial-reload features such as 'only', 'preserveState', and 'preserveScroll', etc.

The most useful discussion I've found on the topic was a Laracasts thread.

I'm currently thinking of using two patterns...

1. the "redirect back to index" pattern for simple cases where reloading the list does not incur too high a performance / data penalty
2. for the more complex cases (including infinite scroll cases) to develop a pattern to manually manipulate the list in the front-end - most likely by directly modifying the props (using the usePage shared data usePage helper - to avoid maintaining a separate list).

...but neither of these patterns are ideal, and the second pattern doesn't feel particularly clean.

I'm keen to find any sample code showing how Taylor's demo (or something similar) should be implemented... and any other elegant patterns others may have found/developed for these types of use-cases.

[miking7]

BTW I thought it might be helpful to document the two patterns I'm currently using:

Pattern 1:

The "redirect back to index" pattern for simple cases where reloading the list does not incur too high a performance / data penalty:

Front-end submits the update via Inertia:

      // Submit using Inertia   (relies on redirect back to the page to reload (all) updated content items)
      await router.put(`/review-songs/${id}`, formData, {
        only: ['songReviews'],                                  // when redirected back to the (index) page, only reload the song reviews (other properties haven't changed) 
        preserveState: true,                                    // preserve the state of the page (so the songs are still loaded)
        preserveScroll: true,                                   // preserve the scroll position of the page (so the user doesn't have to scroll back to the top)
        onSuccess: () => {
          // any success followup logic
        },
        onError: (errors) => {
          // any error handling logic
        }
      })

Back-end updates the database then redirects back to the (index) page:

       // update the database
       ...
       // redirect back to to the (index) page       (the index page will reload all content items)
       return back()

Pattern 2:

for the more complex cases (including infinite scroll cases) to develop a pattern to manually manipulate the list in the front-end - most likely by directly modifying the props (using the usePage shared data usePage helper - to avoid maintaining a separate list).

Front-end uses a non-Inertia axios call and directly mutates Inertia's page props with the updated item that is returned:

    // Non-Inertia axios call:
    const response = await axios.put(`/content/${id}`, data)

    // Update front-end state by finding and mutating the relevant content item in Inertia's usePage props.content.items
    const contentItems = usePage().props.content.items
    const index = contentItems.findIndex((i: Content) => i.id === updatedItem.id)
    if (index !== -1) {
      contentItems[index] = { ...contentItems[index], ...response.data }
    }

Back-end returns a non-Inertia JSON response containing the updated item:

       // update the database
       ...
        // return the updated content item
        return response()->json($content->only(['id', 'content', 'series', 'guests', 'tags']));