This strikes me as sort of like Meteor, only without the suggestion that real time apps will be trivially easy to build.
How we got to LiveView
121–130 of 293 posts
Re: How we got to LiveView
#122> We also shipped a live_redirect and live_patch feature which allows you to navigate via pushState on the client without page reloads over the existing WebSocket connection. This is one LiveView feature I've deliberately avoided so far. The reason is that when you replace real page loading with client-side navigation using pushState, accessibility for blind users suffers. When a real page load happens, a screen read…
It's unfortunate there's no standard way to dispatch this kind of thing ARIA wise. Fortunately live navigation is opt-in, so folks can continue to use `` vs `` when needed. On the form submission side, we actually still have you covered within LiveView, because the server can instruct the client to do a plain redirect:
def handle_event(save, params, socket) do
...
{:noreply,
socket}
|> put_flash(:info, "It worked!"
|> redirect(to: "..."))}
end
I'll also check out the ARIA region approaches. I think something like that would be drop-in for LiveView in the live layout, and we at the very least could include docs on it.
Re: How we got to LiveView
#123We use Phoenix and LiveView to power all of our non-video interactions on Glimesh.tv[0] and the immediate out of the box features and performance are unmatched. LiveView allowed us to get a completely real time updating channel where streamers can edit their metadata (game, title, viewer count, etc) and all of the viewers can see it in real time. Not to mention we implemented a distributed chat system that sends mess…
Are you using Live View for everything related to navigation too? For example if you transition between any page, is this happening through Live View? In any case, I'd love to chat with you on my podcast on how you built and deploy Glimesh if you're interested. It's at https://runninginproduction.com/ , there's a become a guest button in the nav bar on the top right if you wanted to schedule a call to be on the show.
Yeah, the channel / category pages are all "live patched" generally, which means the user can navigate around without incurring a full HTTP roundtrip. Some pages like the account settings are "dumb views" though and do not offer the same advantages.
Thanks for the offer to be on the podcast, I'll check it out!
Re: How we got to LiveView
#124Earlier quoted context omitted.
Are you using Live View for everything related to navigation too? For example if you transition between any page, is this happening through Live View? In any case, I'd love to chat with you on my podcast on how you built and deploy Glimesh if you're interested. It's at https://runninginproduction.com/ , there's a become a guest button in the nav bar on the top right if you wanted to schedule a call to be on the show.
Slight difference from stock phoenix but yes. Only area I’m not 100% on is auth. https://hexdocs.pm/phoenix_live_view/live-navigation.html
Right, the normal way for Phoenix LiveView apps is to make the registration / login exist inside your regular controllers / actions since a LiveView cannot directly modify your cookies or global session (with some caveats).
Re: How we got to LiveView
#125This looks cool, but how does it work when your server is located 100ms away from the client? Every interaction will take a minimum of 200ms to complete, which would become fairly noticable.
For things requiring the server to be there anyway – the exact same way an SPA would work, but a little faster round trip.
For things that should happen instantly on the client, you'd run some JavaScript on the client via a pcx-hook (JS escape hatch), or using a tool like Alpine.js to handle purely client-side interactions.
Re: How we got to LiveView
#126Another pointlessly cryptic title. Yawn.
Re: How we got to LiveView
#127Earlier quoted context omitted.
Hi Chris. We've been using LiveView to build a new app at Precision Nutrition and are largely quite happy with it so far. One concern we keep coming back to is that of the need for constant connectivity in order for the app to work. I'll throw up the disclaimer here that I've not spike on how to handle network disconnects. That said, we've had a few of our internal users lose their connection to the web socket, and t…
LiveView will automatically recover the connection, but you are correct it requires a connection to allow interactivity, but this isn't different from being unable to post a tweet while driving under the subway. The interesting thing about the subway usecase is even google docs last I checked will go into read-only mode when the connection is lost, so I don't consider this scenario particular different than the statu…
Thank you for your response, Chris. It's much appreciated!
Re: How we got to LiveView
#128We use Phoenix and LiveView to power all of our non-video interactions on Glimesh.tv[0] and the immediate out of the box features and performance are unmatched. LiveView allowed us to get a completely real time updating channel where streamers can edit their metadata (game, title, viewer count, etc) and all of the viewers can see it in real time. Not to mention we implemented a distributed chat system that sends mess…
[deleted]
Re: How we got to LiveView
#129Creator of Phoenix here. I'm happy to answer any questions folks have about LiveView, Phoenix, or Elixir in general. We've had some big LiveView features land recently with uploads and HEEx so now's a great time to jump in!
Hi Chris - this is superb, really pleased to see LiveView getting so much attention, and thanks for all your hard work. Can you talk a little about the current story with deployments and managing state across/during those? Obviously Erlang/OTP supports hot upgrades, but those are hard to design correctly and not supported by container/VM environments like Heroku and (I presume?) Fly.io.
You can store state client-side. Say you have a view to edit users, with a modal dialog. A typical LiveView app will change the URL when you open the modal, so it's like /users?action=edit&user=bob. When a server goes down the client reconnects, and the LV receives the URL params in its handle_param callback, so it can recover the earlier state. Forms recover automatically in a similar way.
With this and a DB to store permanent data, an LV app can be deployed just like any other standard container app without user impact.
Re: How we got to LiveView
#130Since I'm a persistence person and not a UI person, I am more interested in what is on the other side of the Phoenix/Elixir/BEAM VM server cluster: the database/persistence. I understand that currently apps mostly talk to PostgreSQL, like a Rails/Django app would?
Then, if something modifies the data in the database not by using the Phoenix app, the Phoenix app would not find out until it loaded the values from the database. And what would prompt it to do that?
But if your entire active state can fit in RAM in a cluster of BEAM VMs, you might turn the BEAM VM cluster itself into a distributed database, in which the only way to modify the data is by talking to the Phoenix app (using Liveview, regular REST HTTP API or something else, maybe even postgresql protocol). If this is the case, the app server can guarantee that no state change could have happened by something else modifying the database or whatever, and a client receiving updates via websocket would be sure that it has a complete and accurate picture of the data.
Of course, you would need snapshot isolation (versioning of tuples in RAM) and you would need to store the transaction log durably on disk and you would need to garbage collect (postgresql vacuum) the no longer needed records. Snapshot export and "live update pushing" to a traditional SQL database would be desirable for BI and stuff. But basically, if a modern distributed database was also a good application server, it would be neat.