I was only referring to API design, of course everything in your post is correct.
I think forcing developers to design their LiveViews to perform twice as much work as necessary on initial render is clearly a design mistake. I understand why it worked out this way, and I am definitely not criticizing anyone. But I don’t see how you could argue this is a good design. Since Hologram is a clean slate I am just suggesting that @bartblast avoid digging himself into the same hole.
This is interesting, but to be clear I am referring to the divergent pipelines in the Phoenix and LiveView APIs. Essentially all of this seems wrong to me.
I’m not sure a unified Plug abstraction would solve this problem because the navigation-over-socket which the live_session abstraction is used for is happening in Phoenix, right? I would think a Plug socket pipeline abstraction would only affect the initial socket connection, not the messages flowing over it (which are actually navigation but how would it know).
Not to mention solving the double render requires keeping a LiveView process alive for N seconds after the HTTP request in case the socket comes in. I don’t know these internals in detail but something tells me this would be harder than it sounds (or it would have been done by now). I can think of several other problems that would come up (and I’m sure you can think of even more).
This is just one of those cases where coupling your API to a lower-level abstraction like this creates trouble down the road. I know there was a thread about whether Hologram should be an “independent” framework so I had that in mind as well. I am not necessarily suggesting Hologram shouldn’t use Plug/Phoenix, by the way, just that it may be better not to expose them to end-users in the way that Phoenix exposed Plug.
