The Travel Keeper: A Sinatra Project
So a couple of weeks ago, the time came for me to create my second project for Flatiron School’s Software Engineering program. For this project I had to create a simple CRUD, MVC Content Management System app using Sinatra to track something that was important to me.
After debating what I wanted to do my project on, I finally landed on the idea of a digital travel vision board. Users could go to the app, create a list of bucket list destinations and have the ability to add, edit or delete destinations off their own lists. Next, came the fun part of figuring out how to make that idea come to life.
After 2 weeks of working on it, I can proudly say my project is complete! I’ve had a few takeaways from this experience and wanted to focus on one of those learnings in particular. It’s about figuring out what kind of permissions to give to users who are logged in vs not logged in and what kind of conditionals I needed to set up to make sure that happened.
Who has access to what?
When I first started mapping how I wanted my project to flow, I decided I only wanted users who are logged in to be able to create, read, update and delete their own destinations. That way a user would only be able to view and manipulate destinations they created and wouldn’t be able to view or manipulate destinations created by other users.
I was able to get that logic working for the new, show and edit views but in my index view, I was still seeing all the destinations, regardless of user. I then realized I didn’t have enough logic in my code to express that a user should only be seeing their own destinations so I updated my code to the below with the help of some helper methods.
I set up a couple of conditionals. The first is calling on the helper method, logged_in?, that confirms whether a user is logged in or not. It’s saying if the user is logged in, run the next conditional. Else, show a flash message letting the user know they need to log in to view destinations and redirect them to the login route.
The second conditional calls on the helper method, current_user, that provides the user that is currently logged in. It’s saying if the current user’s destinations are empty, show a flash message letting the user know their Travel Keeper is empty and they need to add their first destination. Then redirect them to the ‘destinations/new’ route. Else, show that current user their list of destinations.
Updating this code reminded me of the importance of making sure I map out what information I want logged in users to see vs a user who is not logged in and to not be scared to nest conditionals if I’m not seeing what I’m expecting using only one.
This was also my first time using helper methods and I learned how easy it was to incorporate them throughout my app either one their own or chained to other methods.
I will definitely remember these takeaways and incorporate them in future projects.
