Okay, so I’ve been mucking about with Phoenix for a good while now, and you know how it is, you use something day in, day out, and then BAM! You stumble across some little thing that just makes you go, “Huh, why didn’t I know this before?” So, I figured I’d share a few of these little nuggets I’ve picked up.
Getting Started: The Usual Grind
Right, when I first started with Phoenix, I was doing what everyone does. Building out controllers, views, templates, the whole nine yards. And for a long time, I was typing out full module names. Like, if I was in , and I needed something from , I’d type it all out. Every. Single. Time. It felt a bit clunky, but hey, it worked, right?
Gem 1: The Simple Alias Trick
Then one day, I was peeking into some other code, probably some open-source thing, and I saw this: alias * right at the top of the file. And then, further down, just *_function(). My mind was kinda blown. It sounds so simple, almost stupidly simple, but I’d just never thought to do it systematically. I started using alias __MODULE__ a lot too, especially in contexts or schemas if I was defining embedded schemas or something related. It just cleans things up, makes it easier to read. Less typing, more doing. I kicked myself for not doing that sooner.
Gem 2: Verified Routes, Oh My!
Next up, routes. I used the path helpers like ~p"/posts/#{@post}" a lot. And they’re great, mostly. But sometimes, especially when refactoring or if I just had a brain fart, I’d type a route wrong or forget a segment. The app would compile, but then boom, runtime error when I hit that link. Super annoying.
Then I dug into . Man, this was a game changer for me. I added import *, only: [verified_routes: 0] to my MyAppWeb module. And then in my templates or wherever, I could do ~p"#{verified_routes() > *_path(@conn, :show, @post)}". The big deal here is that if I mess up the route name, like type post_pth instead of post_path, or if the route definition changes and my usage is no longer valid, I get a compile-time error! No more nasty surprises in the browser. I remember one time I renamed a whole bunch of routes, and this thing saved me hours of clicking around and testing. It just told me everywhere I needed to update. Sweet.
Gem 3: Generators, But Less Chunky
I use the Phoenix generators quite a bit. You know, mix * and all that. They spit out a ton of useful boilerplate. But sometimes, I just wanted a LiveView, maybe for some small UI interactivity, without a whole Ecto schema and context behind it. I used to generate the whole thing and then manually delete the schema and context files, and unwire them from the LiveView. It felt a bit backward.
Then I was poking around the help for the generator command, mix * -h. And there it was: --no-schema and --no-context. Perfect! If I just need a LiveView module and its template, I run mix * UiStuff MyComponent --no-schema --no-context. It just gives me the my_component_* and the my_component_*. Exactly what I wanted for simpler UI bits. I found this super handy when I was building out a dashboard with lots of little interactive widgets that didn’t necessarily map directly to a database table.
Gem 4: Conditional Assigns with `assign_new`
This one came up when I was working a lot with LiveView, especially with nested LiveViews or components that could be mounted in different ways. Sometimes I needed to set an assign in mount/3, but only if it wasn’t already passed in or set by something else, like handle_params/3 which runs after mount/3 on the initial render if there are params.
My initial approach was clunky. I’d do a bunch of if *_value do ... else ... end checks. It got messy fast. Then I stumbled upon assign_new/3. It’s beautiful. You just do socket > assign_new(:my_value, fn -> "default value" end). If :my_value isn’t already in , it gets set using the function. If it’s already there, it does nothing. This made my mount/3 and handle_params/3 functions so much cleaner. I could set defaults in mount, and then handle_params could potentially override them or add to them, and assign_new just handled it gracefully without me writing a bunch of conditional logic. I particularly remember using this for setting a default sort order for a list, which could then be overridden by URL parameters.
Just Scratching the Surface
So yeah, those are just a few things I’ve picked up. Nothing earth-shattering, but they’ve definitely made my Phoenix development life a bit smoother. It’s funny how you can use a tool for so long and still find these little efficiency boosters hidden away. Always more to learn, I guess!
