Enumerators!

I recently had an “Oooooh” moment. Well to clarify, I kind of knew what enums were but I wasn’t quite sure on the specifics of it. I knew of enums because of utilizing the Rails enum feature in my personal project Drubbble (yes it’s a Dribbble clone…then Dribbble went and did a redesign!) I’m constantly adding features to it as I learn more about Rails. The last thing I added (and need to properly utilize) is enums, I used Rails enums to provide roles for users within my rails application. The concept was pretty simple, instead of using a boolean to check whether or not a user was a administrator, I instead went with enums. One of the biggest reasons is because enums are MUCH more flexible and can be adjusted to add or take away roles without creating more booleans. I imagine having an application that has 8 user roles, creating a boolean for each of them is utter madness (SPARTA!).

Conversating with some programmers over lunch they started talking about a project they were working on and how they used enumerators to solve a problem. Not wanting to sound like the absolute newbie that I am, I was like “oh yea sure, I used enums on a personal project I’m working on myself.” To be fair, I WAS working on a project…I just wasn’t using enums nor did I truly understand what they were. I had a faint idea, “it had something to do with indices”…that was about it. Little did know how close I actually was. They sat and talked about it and I nodded my head absorbing what they were saying and learning. I felt that I was on the verge of understanding enumerators but just couldn’t pass the threshold. It wasn’t until I read up on Rails enums and how they were used in conjunction with the rails gem Pundit did it click for me. To be honest, I felt rather stupid for not understanding it quicker and slightly hated myself for it. Being able to represent values with integers was never something I thought much of.

How I used them in my rails project:

class User < ActiveRecord::Base
  after_initialize :set_default_role, :if => :new_record?
  after_create :create_profile

  attr_accessor :login, :tagline, :location, :website, :available
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :trackable, :validatable
  #-----------
  validates :username, presence: true, uniqueness: true

  #-----------
  enum role: [ :rookie, :pro, :admin ]

I’d like to make a note that I decided to use devise in lieu of rolling my own authentication system under the idea that it would help me focus on the app more so than anything else…this turned out not to be the case. I think I spent much more time enabling the ability to log in with username instead of devise’s default email/password combination. On the flip side, because I decided to go with Devise I learned about allow_nested_attributes_for (which I will make a post on to talk about a bit more). Back on the subject of enums, as you can see from my Drubbble app snippet, I have 3 roles; rookie, pro, admin. A more parred down version of Dribbble’s roles for users. By defining the roles in the User model, I now have access to a few handy methods, namely .admin and .admin? (the same applies to pro, and rookie). With these, you can do set define a user’s role within the application. Each role is assigned an integer (rookie = 0, pro = 1, and admin = 2) which is much better to manage than using a boolean. Currently, I’m in the middle of actually utilizing the different roles past making my test account an administrator to test my model associations via Rails Admin panel. Ultimately my aim is to allow pro users to have access to anything within the application, while rookie users are restricted until they’re invited by a pro user. Hopefully in the next week or so I’ll have that functionality in (and will write about it).