Blog
After the recent update of my IdenticonSvg library , I thought that it’s a good opportunity to learn and practice some things about Phoenix LiveView and create a web app as a demo of the library at the same time.
The first thing I wanted to do is test how quickly I can make something super-simple with Phoenix LiveView: just a single dynamic page with a form, validated live, and generating something that’s live-updated and visible on the same page. That was simple and super quick. No Ecto, no context, just a single LiveView with a form and a handle_event() function for form validation that also sets a field in assigns to the SVG output of the IdenticonSvg.generate/5 function with the content of the form as the function’s arguments.
The second thing was something that I wanted to learn: how to create a file with the value of a field in the LiveView’s assigns and push it to the browser to download with a predetermined filename, without disrupting the LiveView and the parameters set by the user in the form fields. That one took way longer than I expected. I relied on threads on Elixir Forum to piece together a solution that uses a JavaScript event handler instead of a Phoenix Controller (a “deadview”) to avoid ping-ponging the data back and forth between server and client, and disrupting the LiveView process or having to render an IFrame.
Apparently, my current solution
with an inline window.addEventListener in the HEEx template only works for a single-page LiveView, and the right way to go is to add a hook to app.js: here is user steffend
’s response on the thread “Download or Export File from Phoenix 1.7 LiveView
. In any case, the current solution for this specific situation works well, and the naming of the files is clean.
The third thing is something that’s not that big of a deal, but interesting to learn, nevertheless: how to use dark: modifiers with Tailwind classes to enable dark mode. No big deal, it works.
The fourth thing is something else that I wanted to learn: how to deploy a Phoenix LiveView app to production, instead of using mix phx.serve and running the dev environment (with a wide-open /dev/dashboard page). This one was super simple too; I just followed the “Introduction to Deployment”
section of the Phoenix documentation. It worked straight away on Linux, but not at all in a FreeBSD 14 jail (something about not being able to start the listener). In any case, the app is now deployed in an LXC container running Debian 12, on Proxmox VE, and reverse-proxied with caddy.
Here it is: https://obidenticon.overbring.com
