We are a couple of days into the sixth week of the program and have already built a number of small apps using Ruby on Rails. As we’ve been working through the creation of many little apps in class, I’m reminded that practice is crucial to learning something new and familiarizing myself with the process of working with Ruby and Rails.
The process of creating and naming the app in BASH, generating a model and controller, running the rails server, and revising and creating files in the text editor are all steps that seem pretty straightforward. However, there are nuances at almost every step that makes practicing the process so helpful in building a feeling of understanding and confidence that what you are doing makes sense.
A very important part of the process is the relationship between the routes, controller, and views in Rails. Initially, when Jay first ran through the demo in class, I was very confused about what was happening. There was a URL request, some kind of controller, HTML, and all these things floating around that made the app appear in the browser. It was a big jumbled mess that I couldn’t quite parse out.
So I did something that often helps me break down jumbled problems: I drew it.
I drew out the three files (routes, controller, and HTML) that I knew were involved and filled in the info as Jay reviewed it for the class. Normally, I try to mimic what Jay is showing us on my computer, but sometimes it’s best to listen and take notes – especially when I know I’m confused. What I ended up with has helped me so much in untangling the mess I started out with.
Here it is!
The drawing itself is not revolutionary, but it helped me see what I couldn’t before. Namely, how the routes I specify will dictate what I define in the controller file and what I name my HTML files. I made myself draw it and write out some context so I could go back and use it as a guide. I’ve referenced it many, many times during class as we’ve built the lottery app and the employee app and the e-commerce app.
Having that reference drawing on hand while I’ve been practicing has really helped my understanding of the process and where it could go wrong and how you could troubleshoot. It’s to the point where I feel confident enough to explain what is happening with the routes and controller to someone else. Last night, I drew out a more elaborate representation on the whiteboard while I was trying to help a classmate understand the relationship between the files.
Again, the sketches are pretty plain, but they still perform the function of communicating.
In the routes file you specify that a GET (or other) request to a URL will route to a given view, which is named after the hashtag (#). What precedes the hashtag is determined when you create the app in terminal to begin with. Whatever name you give your controller (which should be plural) will be the same name that you enter before the #. The URL and the view do not have to be the same.
In the controller file you define each view that you already named in your routes file. Jay has mentioned that this is not required for the app to work, but that it is best practice to do this. I can completely see why. It’s a step toward keeping everything organized and expressing relationships, which are always handy if something is not working as expected. In some cases the views being defined don’t require the creation of any variables, but in most of our practice examples they do. This means that within the appropriate view, you specify an instance variable (and how it might relate to the model, for example) which will then make it possible to call that instance variable in the view.
Which brings us the view files. These are the HTML (html.erb to be exact) files that you create so that the URL requests that were specified in the routes have something to show. The HTML file names should be aligned with the names previously specified in the routes and controller files. Whatever comes after the # in the routes will be the name of an HTML file. If you specify three distinct routes, then you should have three distinct HTML files. If you specified an instance variable in the controller, you can call it in the appropriate HTML file so that it can be displayed.
And that’s it. As far as I can explain it. I’m still unsure about the language I’m using at times (am I setting up a routes file? or should I be calling that something else?). And I still get a bit lost switching between rails console and terminal and figuring out if the rails server is running in the proper folder, but all that will improve with practice.
Vocabulary: Rails, routes, views, controller, model, instance variable (in Rails, different from Ruby instance variable), rake db:migrate, CRUD, SQL, REST, rails console, rails server, GEM, bundle install