Search #2: Live search results

[bknoles]

Instant Search Results

This builds off #7 .

Steps

• Visit any page besides the root page
• Type something in the search bar, but do not hit enter. ["coffee" and "pup" are good candidates!] Search results will appear in a menu below the search bar. Pressing "Enter" will still submit the search form and take you to a results page.
• Now visit a categories page. Notice how slowly this page loads. If you look in CategoriesController, you'll see that, similar to Add deferred props #3 , we have simulated a slow computing method that renders prop data.
• In the render inertia method, comment out something_expensive and uncomment the line above it.
• If you reload the page, it will still load slowly. But now the search bar will return live results quickly.
• Also notice that if you press the Esc key, the search form will unfocus, closing the instant results.

What is happening?

Shared data

Because we want to make our search results available on multiple pages, i.e. any page that the search bar is rendered on, we want to use shared data. We've added our inertia_share call to a controller concern to make it easier to include it on multiple pages.

Partial Reloads

The <input /> element now has a React onChange handler with a debounced search call. This search call executes a partial reload, which makes an Inertia request to the current url, and tells our renderer to filter out everything except the search_results prop.

There is an important nuance to this, though. In CategoriesController, passing something_expensive to the Inertia renderer immediately runs that method. So, the renderer filters it out from the response after it has executed. The result is that our partial reload is not actually improving performance. The fix is simple: wrap the method call is something callable [note that all of the InertiaRails lazy evaluation options are callables]. It's good practice to wrap props that you know will be slow to compute in a callable, just in case someone in the future adds a partial reload for that page.

Escape key behavior

The escape key functionality has absolutely nothing to do with Inertia! It's just React code with a ref and and a key down handler. A key benefit of Inertia is removing or avoiding a lot of React hook calls. But you probably don't want zero hook calls. This is a good example of where you might want one: to improve an experience that lives in the UI only. No server communication is required in this interaction, so Inertia doesn't need to be involved.