Hey @MatinDevs,

thank you for the detailed proposal. Here are some comments:

1. State Management
   • “When the server responds with a prefetched view, it stores all of the assigns related to that view inside the current assigns collection”
     • this cannot work because LiveViews are by definition their own process. Therefore prefetching must also use a separate process as usual to not break existing guarantees (imagine someone having a <%= send(self(), ...) %> in their template. This message must not escape to the LiveView that initiated prefetching.
   • “When the client sends a prefetch request, the server sends the view, which is cached by the client in the browser session storage”
     • just a comment: LiveView already has the concept of a Rendered structure that stores a view’s static and dynamic parts in memory in the browser. This is what could also be used when implementing something like prefetching. Using the browser’s session storage would most likely not be a good idea here.
2. Rendering Logic for Prefetching
   • “During prefetching, the system renders the view with all elements and logic except for asynchronous functions […] (this decision ensures maximum compatibility with previous versions of LiveView)”
     • if the goal is to reduce latency, why should async tasks not be executed?
3. “Prefetching logic can be bundled into a separate, optional file, allowing projects that do not require prefetching to exclude it entirely for simplicity and performance optimization.”
   • The LiveView JavaScript bundle always contains all the LV code. There is no tree-shaking or similar at the moment. I also don’t think that prefetching would justify adding it. So this part of the proposal can be removed because it’s not needed.
4. Prefetch Cache Management
   • “To enhance control, a function will be introduced to clear the prefetch cache for the entire site. This is particularly useful in scenarios like user logout, ensuring sensitive data is not inadvertently cached.”
     • Logged in and logged out LiveViews should use separate LiveSessions and I’d say views across those must not be prefetched. A request to prefetch those should be denied by the server.
     • If implemented through in-memory Rendered objects, a full page refresh would clear the prefetch state automatically.

With all that said, a realistic implementation of prefetching would almost definitely require adoption of Liveview to be implemented first. As mentioned, separate LiveViews are always their own processes and this is not something we can change. But even if did have adoptable LiveViews - meaning we can spawn a new LiveView process beforehand for prefetching and “adopt” it when the real navigation happens, there is still one problem:

How would patch navigation work? By definition, a patch goes to the same LiveView and therefore the same process. This is a predicament since:

• a prefetch should (I’d say must) not have side-effects on the current LiveView, but we cannot transparently calculate the new state in the same process
• a patch navigation can depend on the current state of the LiveView, therefore just using a separate process also won’t just transparently work
• → one solution would be to just not support prefetching for patch

Those are all my thoughts at the moment. While I don’t see a good way forward for this at the moment, I still want to thank you very much for the proposal and the thoughts you put into it!