![]() In your Counter example, it's true that for the 'degraded' version to work, the link would have to be a proper link and not a phx-click. I've found that the vast majority of clicky stuff I do leads to a URL change anyways, and these are just proper links to the new URL that LV then intercepts. There's an example in the Turbo docs for that at if you search for "def destroy".īut with LV wouldn't you need to create both a LV and a regular controller? That's a huge amount of code duplication.Īlthough to be fair I would imagine most apps would require JavaScript to function so that one is kind of a non-issue for most apps, but it's still more true to the web to support progressive enhancement and the easier you can do this the better. For example you could have a destroy action remove an item from the dom when enhanced using Turbo Stream or just redirect back to the index page (or whatever) for the non-enhanced version. Turbo is set up out of the box to use controllers which means you really only need to add a tiny amount of code (2-3 lines) to handle the enhanced experience alongside your non-enhanced experience. Then there's progressive enhancement too as another difference. How would LV do the same thing over HTTP? Everything about LV in the docs mentions it's pretty much all-in with websockets. In both cases there's no need to poll because the user controls the manual trigger of that event. With Turbo Frames the same thing happens except it's only a designated area of the page. ![]() With Turbolinks or Hotwire Turbo Drive, the user clicks the link to initiate a page transition and then the body of the page is swapped with the new content being served over HTTP. How does that work for page transitions? The docs don't mention anything about this or how to configure it. > Fwiw, you can use long polling for LiveView if you wanted. I could be wrong of course but after reading the docs I'm about 95% sure that is an accurate assessment. Websockets should be used when they need to, which is exactly what Hotwire does. IMO the trade off of throwing away everything we know and can leverage from HTTP to "websocket all the things" isn't one worth making. IMO that is a much better approach than Live View, because now only websockets get used for broadcast-like actions instead of using it to render your entire page of content if you're using LV to handle page transitions. Websockets is only used when you want to broadcast the changes to everyone connected and that's where Hotwire Turbo Streams comes in. It also has new functionality (Hotwire Turbo Frames) to do partial page updates too instead of swapping the whole body like Turbolinks 5 used to do. Hotwire Turbo Drive replaces Tubolinks 5, and it uses HTTP to transfer the content. ![]() However LV will send those massive diffs over websockets. This way you get the benefits of not having to re-parse the along with all of your CSS / JS. However you could use LV in a way that replaces Hotwire Turbo Drive, which is aimed at page transitions, such as going from a blog index page to contact form. If you want to update a tiny text label in some HTML, it uses websockets to push the diff of the content that changed. ![]() Live View uses websockets for everything. It's much different based on a preliminary reading of Hotwire's docs. How does Hotwire compare to Phoenix LiveView? It seems the same to me.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |