Yes but that state is made of immutable data. Computing a new state doesn’t invalidate it. It’s more a question of not doing update in the database, using pubsub on so on.
So we can’t turn it on by default for all views but maybe it can be opt it?
daniel-gagnon
FlyingNoodle
Hexdocs is not liveview so it is a bad example to use for “liveview slow”.
Besides, I struggle with the “slow” argument. If your page rendering is 10ms you are looking at 10 ms + latency should, can be anything from 5 to 50ms.
So in total, you are looking at 15-60ms from the moment you click. I can’t see a reason why I would get into huge technical complexity to reduce that.
1
antoine-duchenet
Prefetch in Next, Remix, etc. is generally applied on SSG content, not SSR AFAIK.
As mentioned above, a prefetched Liveview should not trigger any side effect and it may be hard to track. And the prefetch result should be invalidated at every state modification, I suppose.
However, I can imagine a world where, if every assign of the Liveview is async and rendered insided .async_result, we might be able to load the static part of the DOM with the .async_result slots in a loading state. It might then be patched by classic Liveview mechanisms after an effective navigation.
In such a world, even mount should not run on prefetch to prevent any side effect. A prefetch would basically return the template with every .async_result in a loading state. Maybe we could imagine a prefetch_default option on assign_async/4 if it is useful (right now I don’t find any use for it, even for skeleton purposes).
P.S: maybe that prefetch_default would be more useful on sync assigns to consider it “prefetch compatible” even if it not async.
0
byhemechi
Sure, 15-60ms is fine, and if you’re in the US or to a lesser extent europe that is probably what you’re going to get.
Unfortunately, a lot of apps cannot have distributed servers so the network round trip latency is going to have a much wider range than that. For example, at my company the servers must be in the EU but we have a significant percentage of the userbase in Australia. That means an absolute bare minimum of 400ms for half of our users which is a very bad experience. I’d love to use LiveView for this because I really prefer the DX but realistically this is forcing us to do an SPA because half a second for an page transition is just bad
2
FlyingNoodle
There is no free lunch. Fetching the actual data will take 300ms regardless, wether you use an SPA or Liveview.
Liveview does provide some utilities to “fake” response UI stuff. Things like clicking a button and showing a spinner or a loading class on the button while you fetch the next view.
Do not underestimate the amount of money it costs to keep an SPA up to date. Just the maintenance is absolute hell.
1
byhemechi
For writes you’re absolutely right, the best you can do is optimistic UI and spinners, but for reads you can get almost the same thing with an SPA by prefetching data. Usually, it takes one entire client.prefetchQuery inside a requestIdleCallback.
I am fully aware of the time cost of maintaining an SPA. I’ve been writing JS since we called interactive UI made without using flash or java “DHTML”, the number one way of fetching data on the client was jsonp and there was this exciting new function on the horizon called document.querySelector. If all you know is backend programming then yes it looks very scary but if you’re familiar with the environment and pin your dependencies frontend code is just as simple to maintain as backend code.
There is absolutely extra cost in developing the app, but there is also cost from lost productivity waiting for a loading spinner. There is a reason things like GraphQL/Relay exist and it is not for developer velocity. It is very easy to take loading times for granted if you live in the US or Europe where the servers are close.
If you watch this video of me using livebeats, every one of these page transitions would benefit from prefetching page contents. This is pretty much the best case scenario for an Australian connection with gigabit fibre with good peering. Compare this to this recording of me using Tidal, an SPA and you can see the transitions are almost instant, despite the server also having ~300ms of latency, as demostrated by when I open a playlist that is yet to be cached.
Somewhat ironically, the same sort of speed can be achieved with phoenix, but only if you use “dead” views, because link rel="prefetch" works just fine for full page transitions
3