Sinatra is a DSL (domain specific language) for building small dynamic web apps with all the beauty of Ruby and without the bulk of Rails. Recently, my Flatiron School classmates and I built a simple playlist app that allows users to perform all the basic CRUD operations on songs - you can create, retrieve, update, and destroy them. Emulating RESTful routes for these actions (à la Rails), I created something like the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
With the corresponding models and views that make these routes real, a working web app was born. Pretty darn cool. But there was a feature in the spec that was still left to add, and it became a bit of a challenge:
Whenever a song is created or updated, the user should see a message like this:
Here’s what I wanted to achieve:
- The user fills out the form at
songs/newand clicks ‘Submit’.
- The newly created song’s show page at
songs/:idis rendered with a success message.
- The user reloads the page (or navagates away and back), and *poof* the success message is gone.
In order to get this to work, I would have to somehow pass a message from one action in the controller to another. The create (or update) action would have to pass a message along to the show action which would pass this message along to the view. It would be nice to have something like an envelope called
success_message that could hold one of three values at any given time:
"Successfully created song."(right after the song is created)
"Successfully updated song."(right after the song is updated)
nil(immediately after the success message is rendered in the view)
1 2 3 4 5 6
But how would
@success_message, which would have to be definied in the show action in order for the show page to know about it, be able to hold a message the was created in another controller action (create or update)?
I knew that
params is one such data object that holds values that can be passed from one action to another, but as it is already the envelope for carrying and delivering form data entered by the user, it didn’t seem like the right place for a success message to live. If only there was some other vessel, like params, but not…
1 2 3 4 5
Once you’ve added that, you get this handy little object called
session that you can access in any of your controllers, which can in turn pass along any value it contains to a view. Just to see what it looked like before doing anything with it, I put a
binding.pry inside my index action in
songs_controller.rb, fired off
shotgun, and loaded the index page on my local server. Here’s what pry spat out when I asked it what
Here it is again, split up onto several lines for readability:
1 2 3 4 5 6 7 8
So that’s our session object, before we’ve done anything with it. Inside it there’s
"session_id", a unique key that lives inside your cookie for the life of your session. What else is in there? Having just learned about preventing cross-site request forgery, I presumed
"csrf"=>"598119612cef0d88134413ddd54bad52" to be the CSRF token. If you want to learn more about this (and you should!), read about it here. Finally there’s
"tracking", which I believe holds information about the user’s browser. For our current purposes (creating a flash message), we don’t need to care about these values, but it helps to see how session is structured and what kinds of things it can contain.
Let’s move on and see how we can use this session object to help us with our success message.
Before doing anything to it, it would help to understand what kind of object
session is. It looks like an ordinary Ruby hash, but in fact it is a special kind of Rack object. Why guess when you can
As it turns out, the
SessionHash object has a lot in common with a
Hash object. 103 methods in common (out of 177 total), to be exact:
One hash-like thing you can do with
session is put new keys into it, with values that you can assign and change at your whim. And since the session persists from one HTTP request to another, it can pass values around from one action in the controller to another. This sounded like just the right object to hold the success message!
Here’s what I did (after enabling sessions, as shown above):
1) At the bottom of my create action (immediately before redirecting to the show page), I added a
:success_message key to
session, setting its value to the one-time message I want my users to see:
1 2 3 4 5 6 7
2) I did the same thing for my update action:
1 2 3 4 5 6 7 8
3) Then, I added some code at the top of the show action to pass this message along so it could be rendered by the erb template in the view, and to ensure that the message is immediately set to
nil so it will only render once:
1 2 3 4 5 6 7 8
Now my success message behaves exactly as I imaged it should, appearing and disappearing at the appropriate times.
Due to the stateless nature of HTTP requests, had I simply used an instance variable
@success_message inside these
post actions, any value assigned to it would have been instantly forgotten the moment another request was made. The
@success_message inside the two actions would have in fact been completely out of each other’s scope. The session, however, is available across all actions.
This ability to fake statefulness in your controllers opens up a world of functionality other than flash messages, not the least of which is maintaining a user’s “logged in” state as they browse from one page to another. Without sessions, almost all of the interactions and transactions that occur over the Internet as we know it could not even happen.
So if you haven’t yet, sit down and get to know the powerful little session. It’s definitely worth prying into.