@chrismccord
What if someone is developing a Facebook style chat and notification system through Phoenix LiveView?
I think the chatbox will be erased and re-created with every new page visit, the websocket connection will break and a new websocket connection will establish, so it will be heavy on the server, especially when there are so many users connected at a time.
Am I right or I am missing something?
pillaiindu
1
LostKobrakai
Depending on how liveview initializes it might be possible to combine it with something like barbajs/pjax or turbolinks to keep parts of a page alive while changing other parts out.
@chrismccord I‘m wondering if there are ways to make this even more fail safe by implementing a way to (optionally) have plain http requests trigger the same kind of action a phx-click does execute. This way one could treat a live view as progressive enhancement, where e.g. the temperature controls in your post would still work even if the whole js fails.
0
OvermindDL1
chrismccord
Creator of Phoenix
Before we explore the push state ideas, you are right that LiveView would not be ideal for that use case, depending on your app. If we ignore the need for transitions with pushstate, for example your app doesn’t use unique URLs for the navigable “pages”, then your chatbox isn’t asn issue, since a LiveView can conditionally render the “page” based on the view navigation state. For example, the snake game uses that approach to render the Game Over screen vs active game template: snake_view.ex · GitHub
You are right that if you need actual page navigation with a persistent chat box, LiveView as it will exist for 0.1 won’t fit your needs. One of our goals as we continue feature development with LiveView is to find the limits. I think we can absolutely make it work well for a chat application, but embedding a chat within an otherwise navigable site will need exploration. @LostKobrakai is right that if you wired up a pjax approach, the chatbox would probably Just Work, but you’d need to be careful about how you nested the LiveViews to make that happen.
2
chrismccord
Creator of Phoenix
Fallback to regular form POST’s is not in my plans, but you could roll it yourself by implementing the routes and controllers for your phx-* forms. It would still be limited because you lack any state on the controller side, but you could use it to broadcast messages for other, realtime users. I’m okay saying we require JavaScript for interaction (but not initial render!, ++SEO :)). The neat thing is if you had a <noscript>Sorry JS required please</noscript> in your LiveView, it would only ever be sent a single time, and never again on any update 
0
cnck1387
So @chrismccord, just for clarity, let’s say I have a video hosting platform and on a video playback page, I have a few tabs that users could click.
Clicking a tab changes the content below the video without the video being interrupted. It also happens to adjust the URL by adding /notes or /downloads to the end, based on which tab you’ve clicked.
Right now I’m doing this with ajax calls where on link click, it loads the content under the video in the tab’s container. Are you saying with LiveView 0.1 this won’t be possible because the URL state wouldn’t be tracked?
Would LiveView even be a good fit for that even if URL state was saved? Some of the tabs can have a lot of HTML content (think 10kb of HTML, since it would be almost a blog post that loads from the request).
0
OvermindDL1
cnck1387
Yeah right now I’m using manually wired up ajax calls, and it’s not scalable at all (not performance related, it’s just a lot of boilerplate for each one – there’s 4 tabs). I wouldn’t mind pulling in a lib to help with that but only as a last resort.
There’s other components of this app that would fare very well with LiveView (form validations, toggling completion states on videos, autocomplete search).
0
dmitriid
Throwing this in as something for (way beyond?) 0.1. We will need/want
-
we need an ability to define delay/throttle on
phx-events -
a way to hook into LiveView: send
phx-events from JS, introspect/modify/monitor incoming and outgoing data, “lifecycle hooks” (on connect, on send, on error, on close etc.) -
previous bullet point can probably help with maintaining state between URL changes
So far, even if 0.1 only allows you to manipulate one single page, it’s already beyond awesome, and can be battle tested to find the limitations and further needs.
OvermindDL1
Unpoly can handle all of that as well too by asking the server about it all or basing things on events that happen (all server controlled). ^.^
I highly recommend it.