Simple Sinatra and the Sorcerer’s Gem

If Tinder, Craigslist and H.P. Lovecraft had a baby, that baby would be this app.

And it would be terrifying, but maybe not in the way you’d think.
It would be terrifying because no one, and I truly believe no one, wanted Xanga to come back. But here we are anyway, with a silly little app that looks dangerously like Xanga.

Wireframing? I’ve never heard of her! Just kidding — but these pages could’ve used a little more something something, you know? But hey, Craigslist is still going strong on the same design principles of, well, no design; so I think MonstersConnect can really go far.

Let’s dig into the meat of this though. We could talk about HTML, but it’s even easier to google answers for HTML than it is to find an article about Prince Harry and Megan Markle in The Daily Mail; so is it really necessary to write a blog post on HTML forms? One woman’s opinion: probably not.

So what do we talk about then? The simplicity of Sinatra? It basically writes itself! And that’s not to say that I didn’t still struggle — because I wouldn’t be me if I didn’t struggle — but Sinatra does cut down on the frustration exponentially.

So here’s what we’re going to talk about: my last worked-through bug at the time of writing.

I had my boyfriend make a new profile for a monster, and when he was done I tried to delete and BEHOLD! No delete button. Even though he was logged in! And had been logged in at time of posting! My app wouldn’t let you even see the create page without being logged in, so color me kerfuffled.

I went into rake console in my terminal to see what user_id the new post had and it Did. Not. Have. One! So to my problem, how did I manage to create a new instance of the Profile class without giving it a user_id, which it should always have? And the answer was, as with much of Sinatra (it seems), pretty simple.

So here’s the code block:

get "/profiles/new" do
   if logged_in?
      erb :'/profiles/new'
   else
      redirect_if_not_logged_in
   end
end

We’re calling in a couple of helper methods here, so we won’t get into those, but you can see that in order for a user to see the “/profiles/new” route (which houses the form for creating a new profile) the user needs to be logged in. If not, they’ll be redirected to the sign in page.

post "/profiles" do
   if logged_in?
      @profile = current_user.profiles.build(params)
         if @profile.save
            redirect to "/profiles/#{@profile.id}"
      else
            redirect to "/profiles/new"
      end
   end
redirect_if_not_logged_in
end

Here’s where things matter in regards to that pesky user_id. We’re asking again if the user is logged in. If they are, then we’re going to set the instance variable @profile equal to a new object built in memory(.build), who’s keys and values are set equal to the params(our user input),it will be in our profiles table, and it will belong to the current_user(another helper method elsewhere defined). That was all it needed.

When I didn’t have that, the new instance was still being created, and we were still being redirected to that new profile’s page after creation, but the new instance didn’t know what user_id to set.

The result was that even if a logged in user had created a profile themselves, they couldn’t edit or delete that profile.

The moral of the story is not to overlook those small details. Saying “Sinatra writes itself” is obviously hyperbolic; it’s your responsibility to tell the code what to do.