Lazy DOM Rendering for Hidden Components

[bobik1337]

Problem

When rendering multiple flux:select components with large option sets, performance degrades significantly:

Example scenario: 20 products × 500 product groups = 10,000 <flux:select.option> elements

This causes three issues:

1. Server-side rendering overhead - generating 10,000 options
2. Network overhead - transferring large HTML payload
3. DOM rendering bottleneck - browser struggles with massive DOM tree for hidden content

Issue 3 is the most critical for UI responsiveness, as all options are rendered upfront even though they're hidden until the select is opened.

Proposed Solutions

Solution 1: Lazy Option Rendering

Add a prop (e.g., defer-options) to flux:select that defers option rendering until the dropdown is opened.
Why a prop? This creates a small latency when the dropdown opens (options need to render), so it should be optional behavior. Developers can choose to use it only when dealing with large option sets where initial page load performance is more critical than dropdown open speed.
Also it may require some changes at flux.js.

Livewire already implements similar lazy rendering using x-if templates. This approach could be adapted for Flux components.

Benefits:

• Solves issue 3 (DOM size)
• Options render reactively only when needed
• Significantly improves initial page load

Solution 2: Shared Option Pool (Advanced)

For pages with multiple selects sharing the same options, render the option list once and reuse it across all select instances.

Benefits:

• Solves all three issues
• Single option set rendered on-demand
• Ideal for bulk editing scenarios where server requests would cause delays

Working Implementation

Both solutions are already implemented together in x-if-demo.blade.php (see discussion at #2334 (comment)). This demonstrates the feasibility and performance benefits of the approach.

Broader Application

This lazy rendering pattern could benefit all initially-hidden components:

• Modals
• Date pickers
• Select dropdowns
• Tooltips

Context

Related discussion: #2334 (comment)
Inspired by @calebporzio Blaze Demo.

[joshhanley]

@bobik1337 thanks for the request! We recently introduced Islands in Livewire v4 for exactly this reason. You can wrap the contents of a select in an island and add lazy to it, so it will only load when the select has been opened. See here for details https://livewire.laravel.com/docs/4.x/islands

[totov]

@joshhanley I think we're hitting the same (or similar) bottleneck – specifically with select elements.

We've recently rolled out changes which include lazy loading Flux selects using islands (although I don't see a way to make the lazy depend on the select being opened?), but one thing we're seeing is that the data is being lazy loaded fairly quickly but then we have a lag while all the select options are being rendered (e.g. ~6,000 options).

So the lazy loading request itself is taking e.g. ~100ms, but then on the front-end customers feel like it's loading for another few seconds while it's being rendered.

Also, because we have multiple islands all lazy loading at the same time and there's no way to isolate islands right now, the data for all those islands is being grabbed in one request and then all the elements are being rendered out at the same time after the response, exaggerating the issue even more.

Obvious answer is to move this into a server-side search to limit the amount of options being rendered, but we were finding customers needed to be able to scroll through the options as they didn't often know enough information to narrow down the results to something useful by searching.

Wonder if there's a happy middle ground where a paginator could be returned from the back-end search and that could be used to fill in the options as the user scrolls?

• On page load -> load the first page of results and know the total results for the scrollbar to simulate the total length
• As the user scrolls options -> load in next page (or page(s) relative to position if the user has clicked on the scrollbar somewhere) – possibly show skeleton while page(s) load?
• When the user searches -> same process applies from start again

I guess this could possibly just be done in Javascript instead of back-end by keeping all the result info in memory and loading it into the select element as needed?

[totov]

Or maybe it's the DOM diffing that's taking ages? Really hard to tell. Sorry, not much help here!