Mod 2 at Flatiron School means something special to students: we get to see our code in a web browser thanks to the wonder of Ruby on Rails. As I worked through labs that moved me from /index to /show to /new pages, I got stuck on an unusual prompt. As these challenges often do, it tossed me down a rabbit hole that resulted in new knowledge and the writing of a blog post.
The lab was straightforward on its face: create a form to collect user information and render an instance based on that information, but rather than route the user to a /show page displaying the instance they had just created, route the client back to the /new page. In other words, create a loop so that each time a user hits submit, they are taken back to the form.
It was no trouble using redirect_to and sending the user to the /new page in my Rails controller, but I was still stuck because of the second part of my assignment — display the information that had just been inputted below the form when the page was reset. First I tried to simply print the params, but they refreshed (they persist through the POST method of /create, but not once /new is called again). I realized after the fact that I could have pulled the most recent addition to my database and displayed that on the /new page, but the data would have been inaccurate if the instance creation had failed or if my DB had simultaneously been updated by another request. Isn’t there a way for me to save inputs from one page for display on another?
After failing to find an answer through research, I consulted the solution set for the lab and found this unfamiliar bit of code:
(Controller)
def createsession[:form_params] = params.inspectredirect_to new_student_pathend
(View)
<%= session[:form_params] if session[:form_params] %>I followed the lead and learned all about sessions — a wonderful tool for easy access to cookies.
A bit about cookies:
Cookies are pieces of information shared between a web server and client (usually your browser) during their interaction. Each time the client makes an HTTP request, it sends a cookie. Each time the request is fulfilled, an updated cookie comes back. Cookies are used to make browsing easier by informing the server of pertinent details such as whether a user has saved something in their cart, expressed site preferences, or requested to be kept logged in to an account.
Cookies are very difficult to read, which is why we’ve been gifted sessions to help us parse them out. Sessions do have a bunch of pre-populated cookie data, so they’re not easy to read if you don’t organize them. Here’s a screenshot of what mine looked like:
I was intimidated by the long lines of seemingly illegible code, but towards the bottom I actually recognized something:
Where did that come from?
Sessions are hashes, so it’s no trouble to add keys with data and call that back later. Remember the code that was provided earlier?
session[:form_params] = params.inspectWe’ve dropped our params into the session hash! Now I can call that on whatever page I like, regardless of whether the info saved created anything permanent. In my case, I saved a pair of name strings and then printed them out on my /new page. Here’s the browser view:
My View page was ugly, but we’d have no trouble cleaning it up and presenting a formatted list of whatever info I wanted from the params hash. The important lesson for me was that, though web pages are all independent and don’t naturally communicate with one another, I can save data that persists with session.
Anything else to know about this function?
This example was a very unique use for session, which is very frequently invoked for login features. In my research, it was regularly pointed out that saving your session as a cookie does have some limitations. There’s a 4KB storage limit and making large cookie requests can slow your program down. This article taught me a lot about sessions and explains why it might work to use a database for certain situations. It’s absolutely worth a read if you want to learn about this function in more detail.