source MVC: The Real MVP
Y’all know I’m a big fan of making things simple. And, in general, so is software! Patterns in software are what make things repeatable, and keep things organized. And I looooove me some organization.
When everything has a proper place, I feel like I can focus and get down to the real work. So when something has a nice pattern for me to follow, I’m all about it.
MVC. Simple. Super base idea. Like beginner stuff. But believe me when I tell you, when you forget the beginner stuff… everything else breaks.
I know because I did that. And after I did it, I felt kinda silly… ok really silly. But! I had a good laugh about it. Not to worry, I just went back to the basics and did a little refresher!
So we’ll go back to where everything broke. I was making some updates to a Sinatra app I did a while back, Vinyl Records. This is an app a user can log into and input their vinyl and what condition it’s in. That way they can easily keep track of all that great vinyl quickly and easily (and they’ll know if someone brought back that record they borrowed in worse shape than they got it in).
So here’s how the MVC works:
M — Model. All about the data (bout that data, bout that data) and logic, and rules.
User, and vinyl are the two models here. A user has many vinyl, vinyl belongs to a user. Nice and easy. Users have to have a unique email and username. Vinyl has to have two names for the album and artist, and then a number for the condition it’s in.
Ok great, we have user and vinyl data, some logic, and a few rules.
V — View. This is how the data is represented to a user. We’re just talking about what they’re seeing. No logic necessary here!
There’s a handful of views going on here. Top level, there’s the overall layout of the app, and I use yield to keep things consistent among views. There’s also the top level index view, which is the home page.
On the next level, users have a login or signup page. And once logged in they can edit their profile. Vinyl has create, show, index, and edit views. All very simple, these are all just .erb files responsible for showing the user data in a pleasing way. No one wants to try and organize their vinyl collection on something that looks like this:
I mean this isn’t the source code for my app, that code didn’t prove my point enough. But also, maybe you would enjoy that I don’t know you. Personally, that sounds like a nightmare and not organized at all. I’ll take a pretty and simple layout thank you.
Now that is pretty! (cue me tooting my own young developer horn)
Ok but I digress. Next step is C — Controller. The controller does exactly what it sounds like it does. A user is going to use the app, for this example let’s say they add a new record to their collection. The controller will take info from the user and manipulate that into something the model knows how to deal with (remember, data, logic, and rules), and then the model updates the view(s). And now a user sees the new and pretty view.
So where did my issue happen? Well… I’m embarrassed to say that I was simply not paying attention to how I was naming things between my controller, and my view, so my model had no idea what to do with this information it knew nothing about. Basically, I took a jenga tile out of the middle of the pile, and tried to replace it with a peanut butter and jelly sandwich.
Ok bad analogy. But when I was updating my app, I thought it would be a fun addition to allow a user to add their top three favorite bands. Got that added in there just fine (pat on the back!). But then it occurred to me, that information will probably change! So I better make sure a user can edit their profile.
Well here’s where I got into some muddy water. I was not paying attention to how my user controller was set up. When I created the edit user view, I started using a completely different variable to refer to my @current_user (spoiler alert- The variable should have just been @current_user the entire time)! So of course I got errors, and I had to laugh because all I could imagine was the controller going to model saying, “Please take this, make sure it’s actually this user, and if it is, then take note of these updates, and let my pal view know.”
But then the poor model said, “I have no idea what to do with this garbage. You’ve handed me a pile of garbage nonsense. Please make sense of this for me, I have no idea who @user is. They look strikingly like @current_user, but I can’t possibly be sure.”
And poor view is like… “Model, what’s going on dude? I have no idea what to show this user right now. Nothing looks right, you’re the smart one my guy you gotta handle this.”
And here’s the greatest part! My tired brain kept trying to update the variable for the @current_user to @user. So I continued to break it even further.
I mean all-in-all this was only about 10 minutes of error handling and looked nothing like this printer, but it made me laugh, and I like to imagine tiny programming comics about how it must have played out between MVC.
Maybe I should just write a tech comic? I can’t draw so… that might not work.
But I’ll keep using witty banter to find funny ways to think through why things aren’t working.
Moral of the story is, don’t forget how your MVC is flowing. It makes error handling quite a bit easier! Also never hurt to think of all the moving parts as funny comic characters. Seriously. Giving MVC little personalities has helped me remember a whole lot more about it!
Happy coding, friends 🤘🏻
P.S. I haven’t deployed Vinyl Records yet (I will be very soon!) but if you want to check it out, here’s a link to the repository: https://github.com/jillbowen/Vinyl_Records