coladarci
I’m really interested in the future of maintaining phoenix apps given the new practice of dumping generated code into a project versus separating things out as packages (something I think I love).
For example the phx.gen.auth (something that should never have to change, as José eloquently explained a while back when he wrote it). But for core_components I got bit pretty bad; all the form function components were re-written and the new generators require the updates to work. So now I have 20 generated routes (mix phx.gen.live) that work but any new generation will fail. My only recourse was to re-generate a brand new project and diff the core_components and carefully bring over the changes (since I modified the tailwind classes; something that feels reasonable). And even then, I had problems because it meant all my existing routes were broken, so I had to go back and re-write all of the live_views to handle things the new way. (I should note, I love the changes, big props to the change).
That said, there was no change log explaining it, upgrade path, etc…
Curious if I missed something or if others have thoughts on how we can improve this moving forward so we can continue to make phoenix + live view the best web development experience out there.
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #ai
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 5- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Schultzer
Yeah, there is a delicate balance for generated code vs. a library, where the former requires a higher maintenance cost, in that it’s not as easy for a developer inexperienced or not to increment a version number.
And I like your point about even when some generated code is not meant to change; from my experience, software changes over time.
al2o3cr
I’ve found PhoenixDiff very useful to see what’s changed between releases. It’s basically the diff versus a newly-generated app you described, only automated on a webpage.
coladarci
Extremely helpful!! Yeah this is amazing and will help an awful lot for future upgrades.
poipoi
So basically the only way is to generate a new project everytime? Maybe the all-knowing @LostKobrakai has some better advice?
Zurga
What about this approach: CodeGen - simple, succint and customizable code generation for your libraries
I haven’t had the time to give it a spin but the idea looks promising.