woutdp / live_svelte

Svelte inside Phoenix LiveView with seamless end-to-end reactivity
https://hexdocs.pm/live_svelte
MIT License
1.01k stars 38 forks source link

Excessive SSR for LiveViews #73

Closed vonagam closed 10 months ago

vonagam commented 10 months ago

Right now if ssr is activated then it happens twice on mount - first for disconnected mount and then for connected - and also on each live navigation between different views. Except disconnected mount those renders are not needed and might actually slow down things. It is obvious that there is no point in rendering connected mount. As for live navigation - it seems like main gain of ssr is an ability to see a page before assets have loaded, but in live navigation we already have js and css loaded so there should be no advantage from ssr.

I currently set ssr={!connected?(@socket)} on a svelte component in live view to avoid those renders. I think it worth mentioning somewhere.

woutdp commented 10 months ago

MIght be an idea to pass the entire socket and handle it inside LiveSvelte. And then let users know they should pass the socket when using LiveSvelte in a LiveView. Just to make the UX more simple. If they forgot things will still work but won't be optimal.

vonagam commented 10 months ago

Hm... I guess socket={@socket} reads better. But the main problem is that I do not see a way for a component or macro to detect if it is used in dead or live render.

For example V sigil cannot simple add socket={@socket} because there might not be an assign named socket. Theoretically it is possible to write `socket={assigns[:socket]} in the sigil macro. But it is not technically correct thing to do since a user might use this assign for their own needs in dead renders (though you might decide to ignore that possibility for convenience).

Actually, I think I am mistaken: ~V can look if there is a socket assign with a type of %Socket{} and use it in this case (so new method get_socket(assigns)).