Recently, I’ve started doing personal projects a little differently. I’ve realized that I learn much quicker and get more done when my time to complete a project is limited. As such, I’ve started putting limits on the number of hours I can spend working on any given personal project. This approach pushes me to work faster, forces me to make decisions on how to fail gracefully, and gives me practice with timeline estimation, a vital skill in the industry. Note that the hours do not have to be consecutive, but they are carefully logged on Github to make sure I don’t exceed them. I generally work three hours at a time.
The week before last, I gave myself the job of creating, in six hours, a sliding-tile puzzle that uses open access hi-res photos of art from the Met. It was tough, but a success. This last week I tried to push myself further, by attempting to create a React on Rails chatroom for the first time within nine hours. (Don’t expect too much from that link.) Most of what I did get done followed this tutorial. I wish I could have failed gracefully and created a blogging platform or something when it became clear that I couldn’t pull off the chat room in nine hours, but I couldn’t change direction in time and it was essentially a flop. However, I learned an absolutely insane amount about Rails technologies that I had zero exposure to before, including Decorators, Action Cable, Active Job and the react-rails gem (I had just used Rails APIs that talk to separate React front-ends up until now). It was also a great example of when to use serializers, and a very solid review of how to do so. In this post, I’ll be documenting the things I learned, the new subject matters I broached, and how I understand them at this point.
I’d heard the term ‘Decorator’ thrown around before this week, but it was a very vague concept in my head. I think it’s pretty understandable that I thought that decorators had something to do with styling and CSS. As it turns out, decorators are a design pattern.
The Decorator design pattern lets you give an object a behavior without changing the class that it’s an instance of. Usually, something like this would be done by creating a subclass, but if you keep doing this you can end up with way more subclasses than you want, and on top of that you may need to create even more subclasses that are combinations of the previous subclasses to give a particular object all the behaviors you want. Ex: Bike, BikeWithBell, BikeWithLights, BikeWithBellAndLights, BikeWithBasket, BikeWithBellAndBasket, BikeWithBellLightsAndBasket, etc…. Any small amount of complexity in terms of custom object abilities can result in an explosion of subclasses, generating lots of code, and leading to confusion.
Decorators are an alternative. Think of them as as a wrapper for our objects that temporarily give them extra methods. There are a few different ways to implement decorators in Rails, but this time around I used the ‘draper’ gem.
I suspect that the name comes from the visual of ‘draping’ the decorator around an object. Once you install the gem, you can generate decorators from the command line, and they appear in a new directory: ‘app > decorators’.
Here is an example of a decorator:
class ArticleDecorator < Draper::Decorator
object.published_at.strftime(“%A, %B %e”)
There are many ways you can now use this decorator. You can fetch an object from the database, enhanced with the published_at method:
@article = ArticleDecorator.decorate(Article.first)
…or you can create a new object with said enhancements, or you can fetch the full collections of all Article objects, with the published_at method now available for each. Decorators are super flexible and the sky’s the limit!
Action Cable was released with Rails 5 in July 2016. It’s the push by the Rails to integrate Websockets with the rest of the framework. Websocket is a protocol, standardized in 2011 and built on top of TCP/IP. It’s purpose is to facilitate real-time data transfer (streaming) between a server and client. This is made possible in part by the client not being required to send a request to the server in order to receive content. Information can be sent continuously between server and client while keeping communication constantly open. Action Cable is the integration of this protocol into Rails.
The react-rails gem
Up to this point in my React on Rails adventures, I’d been keeping the two Rs largely separate from each other. I would fire up a rails API that would provide JSON endpoints for a React frontend generated with create-react-app. Though I might keep them in the same directory, I really just had two apps that didn’t know anything about the other’s existence. The react-rails gem is very different, and brings a much closer coupling to the two technologies. Once the gem is installed, we can generate new React components from terminal, and we can give Rails views access to them with the react_component method. It’s a lot of fun to work with, and I’ll probably use it much more in the future!
I learned a ton from this project. I’m going to try to start working more with all of these technologies, Action Cable in particular. The possibilities are crazy, my dream is to get a video chat up and running. It’ll be a little while before I start messing with that, but it’s fun to think about. Woo Rails!