The responsiveness of you guys is ridiculously amazing! Thank you!
3 posts were split to a new topic: Phoenix LiveView and Pjax
A post was split to a new topic: What’s the possibility of creating a “drop-in component” (React-like) using LiveView?
Just a quick note to say that now this thread is getting quite long, if you have a question about LiveView please post it in a dedicated thread
Chances are that many others may have a similar query and so by having dedicated threads they will be more likely to be picked up by search engines… which means they will be more easily found, hopefully lightening the load for Chris, José and the rest of the Phoenix team, thanks
2 posts were split to a new topic: Will LiveView work with iOS or Android?
Desktop apps is one area that I think LV have a lot of potential.
The past couple of months, I’ve been looking for a way to give one of my elixir apps a GUI (JavaFx, wxWidgets, Electron, etc), but all of them had major drawbacks that kept me from committing. With the introduction of LiveView, I just made that exact same app as a dependency for a phoenix liveview front-end and ran things straight from the browser. Work that would have otherwise taken me weeks, done in a day.
Great job here m8s
A post was merged into an existing topic: LiveView demos thread!
I never have flattened Jose or Chris for Elixir or Phoenix, just to be clear how high I put the bar
But LiveView might as well (and should IMHO) revolutionize the web.
So let me say something I probably should have said a long time ago:
Jose, Chris and all the others working on Elixir, Phoenix, Ecto, LiveView etc.
You are my heroes and I am, like many, many others, in your debt !
where is phoenix live view documents?
you mean the code? https://github.com/phoenixframework/phoenix_live_view
Hello, no I mean like this https://hexdocs.pm/ecto/Ecto.html
As the package is not published yet, you will find the documentation in the code, take a look at the README
But yeah, thanks for all your work and optimizations which allow liveview to be useable (maybe most thanks should go to the people who made the BEAM and light processes possible). It only lacks a way for forms to have a fallback when JS is off for me to happily flatten you as well!
oh good one
People.flatten flatter of course!!!
Golang/Elm user here (although very interested in Elixir) - just wanting to add my 2 cents.
I developed something very, very similar to this in Go last year. I modelled it after The Elm Architecture (hence the name ‘go-tea’) but it does essentially the same thing: renders HTML, establishes a websocket connection, then pushes ‘messages’ from the client to the server. The server holds a state object for the session which it updates and then sends the rerendered HTML back to the client. As with LiveView, the client uses Morphdom to make minimal incremental changes to the DOM. Repo is here: https://github.com/jpincas/go-tea (hasn’t been touched for a while).
I had a few cool examples, similar to some of the stuff @chrismccord demoed in his keynote: forms, navigation, shared list editing across connected ciients, basic components, even a little card flipping game.
I came to a similar conclusion: that this architecture was easy to reason about, performant enough and could scale quite well, so our team took the plunge and used it on a project we were working on at the time which needed an internal admin panel with fairly interactive UI.
I was actually amazed at the results. I built the admin panel in about 2 days instead of maybe 2 weeks. The code was clean and honestly, the app was indistinguishable from a SPA except perhaps to an expert eye.
The only real issue we had was with debouncing text input in a text editor. We were live rendering a preview of parsed markdown next to where the user typed the content. As an aside - that was another compelling argument for this architecture. We were able to use the exact same template to render the preview in the admin panel as was used for the user-facing portion of the site (also server rendered in Go). Anyway, when the user typed too fast, the server state could get out of sync with the browser state causing some strange regressions while typing. We experimented with a few different debouncing techniques and parameters but never really settled on anything we liked.
Eventually that project was abandoned in favour of Wordpress (don’t get me started on that…) but the idea of building sites/apps in this way has stuck with me ever since but I’ve always been hesitant to go all in on it for a couple of reasons:
Firstly, there’s always been that “can this really scale” niggling doubt. It’s such a departure from the norm that I think it’s natural to be slightly cautious in this respect.
Secondly, and this is definitely subjective - for me, at least, Golang was not a ‘nice’ fit for building apps in this way. Don’t get me wrong, the raw power of Golang, the speed and concurrency features makes it an ideal candidate for doing this - probably one of only a handful of languages in which you’d even attempt to do such a thing. I just found that expressing the app/UI logic felt clumsy. I longed for the functional elegance of Elm. I don’t know if it’s just because I’m used to Elm now, but it feels very natural to write UI logic as pipelines of transformations. You have a list of this thing, map it to this other thing, filter out these ones, then render. That seems to me the to represent 80% of the code you end up writing - that and case switches. This was just horribly verbose to write in Go.
So stumbling across LiveView was a real joy for me. I can attest that this way of architecting apps is totally awesome and works better than you probably imagine at first. Personally, I’m ready to go all in. 90% of the sites/apps I build will never need the power/overhead of Elm, so it’s a great fit for me - obviously YMMV depending on what you build.
Now I’ve got to learn Elixir as fast as possible. Off to research resources…
I first heard about Phoenix LiveView in more detail during ElixirConf.EU in @chrismccord’s talk there. Before that, I had heard about it a little bit, but was (a) skeptical about its intended performance, and (b) far too busy with other projects these last two months to look at it in any detail.
But not only did my jaw drop to the floor during Chris’ talk, also did I realize that it was a godsend to use during hackathons where you want to quickly build something simple, without wanting to worry about the ‘frontend <-> backend communication layer’.
So, last weekend, during the Odyssey Blockchain Hackathon in Groningen, we set out to build a simple PoC ‘mobile-like’ web interface to make people’s energy usage more sustainable by gamifying it.
While we did run into a couple of bugs (it seems that currently nested if/else statements or case-statements in LiveView templates sometimes cause weird behaviour; I’ll investigate further before opening a issue request), the speed improvement gained from not having to worry about the JS boilerplate meant that within ~30 hours, the designer/slicer and I (the single developer on the six-person team) were able to flesh out the complete interactive interface.
We will probably release some screen footage and the source code soon, but first let me catch some sleep – I’ve been going on for 56 hours with very little of it.
Thanx for sharing,
Sorry about Wordpress
Welcome to our community, which, might be just one of the best places for learning
Did you find a solution for drag & drop?
My apologies for missing this! I essentially implemented my own JS-driven drag & drop solution in the browser, alongside and unrelated to the LiveView. It’s definitely not as simple as what it could be with LiveView, but it worked. Basically, I implemented things by hand in the browser and used an old-school AJAX call to a basic controller action.