Having a grasp on ruby is fantastic and such, but this raises the question of what next to do with one's impressive smorgasbord of classes, communicating the way they should with the right methods and having braved every possible edge case.
That is to ask, how do we now make something that begins to actually look a little bit like a website or, better still, a web app?
...To be honest, I'm still not entirely sure myself, but there are a couple basics and tricks to building web apps in Ruby which I wish to cover.
Sinatra
Sinatra is a ruby gem which serves as a framework for implementing ruby code as the backend language - that is, the language through which objects, the data they hold and relationships between pages are controlled. When elements coded in HTML call for either a GET or a POST request (links typically are confined to GET), it's typically in this backend code that any page redirections or manipulations of form or other data are written.
One of my personal favourite things to do here - which I took some time to warm to - is the Post/Redirect/Get pattern, wherein a post request assigns input to variables, then redirects to a page with a get request.
For example, let us say we wanted to take a name and email address and submit them to a list page, but didn't want to risk submitting the data anew every time we refreshed the target page? In the case of, say, a shopping app where such could lead to duplicate payments?
One could have a form submission for a name and email address activate a post '/submit' do end block which takes the text input into the form and stores the contents of each parameter in variables.
If one chooses to enable :sessions within their core web app file, these variables can be values tied to keys within the session hash created by sessions.
Now, the post block can redirect to another page address with the redirect method (in this hypothetical, redirect '/list'), tied to a get '/database' do end block that takes those session key-value pairs and does whatever it is we want to do. This particular feature I'm not quite yet sure how I would build, but there is a more pressing question that must be answered first. Namely, how do we take data from the backend into the front end?
Interpolation of ruby code
Within a GET or POST block within the central controller, one can set instance variables, and then invoke these in the code for the associated .erb file (the file format we use for front end units).
Given a variable @instance_variable in a GET/POST block, followed by erb(:page), one can then print the value of the variable into page.erb using the syntax .
One can again make use of the session hash by enabling sessions if one wishes to make these variable values available across the entirety of the web app session.
Alternatively, one can make certain elements within a view in the web app subject to certain conditions determined through the backend.
The way to implement if statements on the front end is to open them with <% if condition %>, enter the elements which you only want to execute on the page if the condition is true, and close with <% end %>. You can also add elsif and else clauses with <% elsif other_condition %> and
<% else %> respectively.
These are just some of the ways in which you can invoke ruby code directly on to the front end in order to regulate the presence or presentation of content.
Testing
It can be tedious at times to continuously have to close own and restart your web app in order to fully test out its functionality. You can use software such as Shotgun to make this easier for you, although I personally have had errors with Shotgun as while I can launch my web app successfully from the command line with it I find that it raises Sinatra doesn't know this ditty. It is, nonetheless, a useful piece of software for ease of interaction with and fine-tuning of your web app. Rackup is also recommended.
Ultimately, the most important thing to do is write adequate spec tests for your code. Thankfully, there is a testing framework known as Capybara that can work with Rspec and other backend ruby TDD frameworks.
A full cheatsheet and documentation for working with Capybara can be found at https://devhints.io/capybara and contains tests for the presence of links, buttons and content amongst others.
The practice I am familiar with for front end feature testing of .erb files is that one creates a separate /features directory within their spec directory.
Here one should endeavour to have a separate spec file for each view that they create and ensure to be thorough in test coverage. This way one can minimise the number of times they need to reload the page if they cannot find software that can successfully do this for them (I can only speak from personal experience).
If one wants to test out tweaks to elements or CSS styling on the fly, google chrome does offer the tools for this. Simply select the button in the top right with three dots vertically stacked, scroll down to 'more tools' on the menu that presents itself, and click on 'developer tools'. This can also be a useful accomplice to your core web development learning resources as it allows you to peak into some of the source code and allow you to inspect specific elements to better understand how they were built.
These are just a few tips which I have managed to take on in my current and very basic understanding of building web apps with ruby.
Top comments (0)