Yeah I don’t fault you there, lol.
The thought to rewrite it in OCaml has crossed my mind more than a few times, and it’d be entirely modular there and type-safe!
Drab? You can send even specific modifications to do, you can make things as tight as javascript allows.
But isn’t that websocket based?
The exact use case is… image if you’re viewing a page where a video is playing.
[video]
a | b | c
And each of those letters are tabs you can click. When you view a video, by default you’ll be on tab A, but if you want to skim notes or something while the video is playing, you might click tab B. But Tab B has 10-20kb worth of HTML to serve (a video transcript).
It’s really just a simple ajax request that contacts the server and responds with a partial phoenix template (everything but the layout). I have it all working but there’s a massive amount of JS boilerplate to hook it up for each tab. Plus, I have to inspect the request on the server side too, to make sure it’s an ajax request, etc..
LiveView would be perfect for this as described, but you mentioned you need pushState as well? I don’t think it will be a large effort for us to land pushState, it just depends how far want to go with it. For example, I discussed “transitions” above about pushState to a new view, where this is pushStat in an existing view, so I need to find the right API that satisfies both.
The reason my example would prefer to have push state is because imagine the URL for the video to be /videos/1/notes where notes is a tab, but after you click the “downloads” tab, you you would end up at /videos/1/downloads.
It’s mainly a convenience so users can bookmark a specific page + tab, but it’s not a deal breaker since the videos are behind a user login, so they wouldn’t be sharing a specific tab with others.
It’s interesting to hear you think LiveView is perfect for this. Wouldn’t this mean each user on any of the video tabs would have a liveview connection active on the server and then if they change tabs, the state gets changed on the server, etc.?
In any case, the act of switching tabs would always be an action the user takes, and it wouldn’t persist anything to a database. It’s just for requesting different HTML content in the output. Do you still think that is an ideal use case?
(Note: I am hoping it is because I would love to use liveview for that + the other things where I know it’s a good fit).
Exactly… I’m most interested how I could possibly integrate existing React components without having to rewrite the complex ones to LiveView components day one. I’d love to be able to embed some existing React components (currently using react-phoenix) into LiveViews. Doing so I would need to somehow pass props onClick, onConfirm, etc JS callbacks which invoke phx- events including optional payload to be handled server side. I wonder if it’s possible at all or if morphdom will blow away the React component’s <div> on each re-render. Wow… if this could interop it would be incredible for my project.
Are we still 100% sans expected release date?
The combination of refusing us to play with the alpha and not having a release date makes me feel like when I was hopelessly in love with the hot girl in fifth grade but she wasn’t interested in me. 
I’m daydreaming about this getting done so I can start working on all my queued up hobby projects!
Stuff like pushstate should come pretty quickly as a community contribution once you deem us worthy to gaze upon the holy grail of liveview @chrismccord 
Given that events need to go back to server and then return to the client to be rendered, has anyone given any thought to the upper bounds of acceptable round-trip latency between the server and browser that still has for a good user experience? Theoretically what should be the limit of acceptable latency for a plain old forms? 100ms? 500ms? Less or more?
Chris has said “soon after Phoenix 1.4 comes out” (and 1.4 is due out soon!)
It has been 2 months and 2 days since it came out. Am I the only one who is so impatient? @chrismccord please let us help you, most of us accept a working prototype and are ready to work with a few bugs.
has anyone given any thought to the upper bounds of acceptable round-trip latency between the server and browser that still has for a good user experience?
I think that depends on your application. I can imagine cases in which 30 minutes are still okay, but in others you should stay below 50ms. For the plain old forms, I’m guessing around 400ms unless you are creating an app for old people (they are generally slower 
). Just be sure to use the proper type=“x” on your inputs, so that the browser can do some of the work instantly.
