The transitions from about half of the versions between 0.3 and 0.10 were worse for me. From 0.10 to 0.15 were smooth. 0.16 was tied to phx 1.6, which made it worse again, but I didn’t find it that bad.
0.16 to 0.18 has been mostly okay again, but I’ve seen bugs introduced into an app just by adding IDs to HTML elements with a phx-hook on them. This is a problem since heex templates enforce that each hook does have an ID. It’s also strange that a totally new ID never used elsewhere in the app would break existing JS interop, but it does and it’s what I’ll be working on this week so we can continue upgrading…
Not sure what it’s going to be like upgrading to Phoenix 1.7, but I think it’s going to be a major undertaking and unfortunately most my Phoenix-related screencasts will become obsolete. Elixir itself and Ecto have been really stable, though.
Right, Phoenix LiveView has been pre 1.0. We try to keep things deprecated for a while but we need to balance getting to 1.0 and supporting existing code. Now that it is getting closer, we can make it as a default in new Phoenix apps. :)
phx-hook always required IDs. They would misbehave (and warn) if you forgot the IDs, so could it be that you were relying on broken behavior? In any case the IDs can be enforced now, so it should be consistent, please file bugs if it does not work.
Upgrade to Phoenix v1.7 should be painless, because it only really changed generated code. Screencasts that use generators will be out of date though. In other words, best practices evolved (as they should) but code still works.
I don’t see reliance on broken behavior around the hook, but it’s absolutely possible. It’s a large app with a lot of technical debt and was on Elixir 1.9, OTP 22, LiveView 0.4 and Webpack 4.x when I joined on this summer.
The existing team had encountered a lot of pain dealing with LiveView and made heavy use of jQuery as an escape hatch. They were seriously considering a rewrite in another language not long before I joined.
It’s been a long, painful slog upgrading, but the app is now working with current Elixir and Erlang versions and runs on my M1 Mac now at least. LV 0.16.4 runs on prod and 0.17.5 is working on an upgrade branch (as long certain phx-hooks don’t have an ID).
I’ll get to the bottom of the various issues and get the heex migration finished. Ultimately, I’ll remove the currently hooks and related JS entirely and replace the modals that rely on them with pure LV versions. Just reporting the dev experience.
IMO Phoenix upgrades were pretty trivial since I started around 1.2, until LiveView. Now, due to the increasing LV integration, it feels like Phoenix itself is no longer 1.0.
FWIW, if an element does not have an ID, then it is hard for morphdom to track when it moves around on the page. This will lead the hook to consider it is has been destroyed and mounted instead of updated.
About Phoenix, the generated apps definitely evolved a lot, but updating your Phoenix dependency should just work. If it doesn’t, please file a bug report!
Well, I did make a conscious decision to hold off on videos about LiveView (and part of my book) due to the frequent breaking changes in the LiveView series I did back in 2019.
My job has been giving me a lot of ideas for new content, though.
0.16 to 0.18 has been mostly okay again, but I’ve seen bugs introduced into an app just by adding IDs to HTML elements with a phx-hook on them. This is a problem since heex templates enforce that each hook does have an ID. It’s also strange that a totally new ID never used elsewhere in the app would break existing JS interop, but it does and it’s what I’ll be working on this week so we can continue upgrading…
Not sure what it’s going to be like upgrading to Phoenix 1.7, but I think it’s going to be a major undertaking and unfortunately most my Phoenix-related screencasts will become obsolete. Elixir itself and Ecto have been really stable, though.