Sitemap
Jon Wu

Jon Wu

Growth @ Aztec

Enums

3 min readDec 11, 2017

--

So recently my boy Christofer Johnson and I were building a Rails app called Jbbr (think Tinder, but for jobs). One of the features of Jbbr is user sessions. That is, unlike Tinder, where users all belong to one class and can like each other willy nilly, Jbbr aliases users into two types, depending on session type: employee and applicant.

We knew we wanted different views depending on whether a user was in employee mode or applicant mode — as an employee, you want to edit your company’s postings and swipe for applicants; as an applicant, you want to edit your resume and swipe for available openings.

Implementing Sessions

We learned recently about rails sessions, a way for user information to traverse the website throughout each controller and view. One nice DRY way to use the session hash is to store the session’s user object before every action:

class ApplicationController < ActionController::Base  before_action :session_user  def session_user
@user = User.find(session[:user_id])
end
end

That way we can call @user anywhere in our controllers!

So obviously my naive approach was to store session information in the session hash. Like, duh right?

Get Jon Wu’s stories in your inbox

Join Medium for free to get updates from this writer.

I therefore built a little flip_view method to handle changing the session type if the change session button on our nav bar was ever clicked:

def flip_view
if params[:session_flipper]
session[:type] = session[:type] * params[:session_flipper]
end
end
Press enter or click to view image in full size
How you switch to viewing Jbbr as an employee of a company

And I passed the session_flipper parameter into a get request with something like this:

<%= form_tag request.original_url, method: :get do %>
<%= hidden_field_tag 'session_flipper', -1 %>
<%= submit_tag('Switch to Employee View' %>
<% end %>

Cool, right? Every time you hit a button the session flips! Now the URL looks like this hidden field tag:

http://localhost:3000/profile?utf8=%E2%9C%93&session_flipper=-1&commit=Switch+to+Company+View

Except…every time we hit refresh on the page, the page would flip back to the opposing view. And if you hit refresh again…same thing. The URL was storing the session flipper parameter of (-1), and the session_flipper method was abidingly changing the session type with every refresh.

How it feels sometimes

A Better Way: Enums

A way better way to do this would be to use enums. An enum is basically a hash with a set list of states. They should be used in cases where a variable should only have one of a set of values. In pseudocode:

enum
STATE 1
STATE 2
STATE 3
end

Enums aren’t native to Ruby (as they are for C-type languages), but ActiveRecord has an enum module that makes keeping track of states easy.

In this case we would persist the state to the user database by adding a column called session_type, and declaring an enum in the User model — we can even add a third state called admin which can be authorized for super-secret stuff!

class User < ActiveRecord::Base
enum status: [ :employee, :applicant, :admin ]
end

Then, ActiveRecord has a bunch of built-in methods to help us change the status easily, e.g.:

@user.status.employee!
@user.status
# => employee

Then, instead of passing params around like a damn fool, we could simply flip a switch to change the user session type. This would also help avoid another mega-mistake I made in designing the views: we could have all the session logic within the controller, so before any view was rendered the controller would determine what session type the user was in and render the correct view.

Instead we had some ugly, ugly conditional views with logic at the top that determined which lines of HTML to run. That’s a huge no-no since ERB’s are extremely hard to decipher what with their <%= terrible bracket %> notation surrounded by a forest of HTML.

This solution would also keep URI’s nice and clean, so that /profile continues to just be /profile and not get junked up with passed-in params — we don’t want our users to see under the hood!

Waow. Much improve. Such code.

Also how it feels sometimes

--

--