3 Creative Ways to Make Your Sinatra App More Dynamic (Without Using Javascript)
Take away most of the magic of the go-to web application frameworks, like Rails, and what are you left with?
Appreciation!
Starting your programming journey with lighter weight frameworks like Sinatra will give us both a greater understanding of how the more powerful frameworks are operating under the hood, and a greater appreciation for their convenience.
That is precisely the path charted out in the Flatiron School’s Software Engineering curriculum, teaching you how to create models, controllers and views manually with Sinatra before working your way up to the heavy weights like Rails.
When one thinks of enlivening a web app/page one language comes to mind: Javascript. BUT, since Javascript is not something Flatiron covers until later in the curriculum I wanted to see if I could find some creative ways to bring a Sinatra project to life using Ruby logic and ERB files.
Here are some interesting implementations I discovered in my exploration:
#1 Utilize Sessions to Create Dynamic forms
Every time a form is submitted or a link clicked, our app is sending a new request to our server. Enabling sessions in our applications configuration allows us to keep track of data throughout these new requests and it’s most commonly used to keep track of which user is currently logged in.
But what if we utilized sessions to make our forms respond dynamically to user interaction?
The Sinatra app I tried this out with is called “Gym Programmer” and it allows you to input and edit your weekly exercise programs for easy reference when you go to workout.
If you gave your users a blank form with all available options you would end up with slots for 7 days worth of 10 exercises each.
Not only is it very unlikely a user is going to be inputting a program that uses up all that space, it also looks ugly.
Instead you can try adding a second button below an earlier selection of the form with a name and value set to “update” or something similar.
(The button that actually submits your form should be set with a name and value equal to “Submit” so you can distinguish between the two.)
In your post route you can then set the params from the previous form options, in my case [:days] and [:name] and set them to sessions accordingly.
Next check your params to see which button was pressed and if it was your first button re-route back to the form and use Ruby conditionals to prepopulate what was already entered and use those entries to generate the remainder of the form.
The benefit of this is you save your user from having to re-enter data when the page reloads and by having less blank entries you will have less useless data in your params to clean up on the receiving end.
Playing with forms and routes this way will likely require some extra validations to ensure you are getting proper data when your “submit” button is finally pressed.
Create these validations under a private heading in the appropriate controller and then place them in a single method called #valid_entry? as an easy way to set a conditional to either instantiate and update your database or redirect to try again.
Lastly, don’t forget to reset and empty out those session parameters you set earlier! There’s no need to bog down sessions with data that isn’t immediately relevant.
#2 Utilize Helper Methods to Create Dynamic User Pages
Helper methods are methods that are defined in your Application Controller and made available to all controllers that inherit from this main controller.
They can provide an easy way to validate that users are logged in and have permission to visit certain pages and they keep our code DRY by abstracting this repeating logic to a handful of methods.
Might these methods also be utilized to render pages that are unique to the user?
If you think of commonly used apps that have user profile pages you will notice that often when a user is logged in they can view their profile in a similar way that they view another users profile. The difference is a user viewing their own page might be provided with features to edit or update their page.
Using our helper methods we can create a method that saves the current user from sessions data and then use Ruby conditionals to check if the user who’s page we are on is the current user or not.
This will allow us, in a sense, to render two different pages on the same view depending on the relationship of the current user to that page. Hide certain features and buttons that should only be available to the current user, and at the same time give each user the means to check out other user’s profiles.
#3 Utilize Ruby’s Built in Time Methods to Periodically Update content
Lastly, we can utilize Ruby’s built in time methods to give our user a unique experience from day to day.
In an app like Gym Programmer we are helping our users keep track of their workouts from day to day. Rather than give them their entire program each time they log in, it would be even better to compare the data in our database with the current day of the week and show them what that day has in store for them.
We can use the #Time.now functions in Ruby to make such a comparison and set our app free to change shape as the days go on.
This is only one use case, but there are countless creative ways it might be utilized!
Another feature that I built into this particular app was a button allowing a user to log a workout as complete and add to their total of completed workouts.
The site keeps track of a ranking system based on completed workouts to induce some friendly competition among users. To keep anyone from cheating we can use Ruby conditionals to only show this button if it has not already been pressed that day.
I hope you found these ideas inspiring and helpful in bringing your next Sinatra project to life!
What are some creative ways you’ve found to use Sinatra and Ruby logic?
