The Gem Files: ‘phonelib’
“If I am a guilty man, my crime is in daring to believe that there’s a ruby gem for every situation, that the truth will pass in my rspec tests and that no one bug can live forever. I believe it still. Much as you try to bury the gems, the truth is out there.” -Coding Mulder, probably.
The Problem:
You have phone numbers as an attribute for a class, but users are able to input their phone numbers in whatever which way they want. They could be from any country, and all lengths and sizes of phone numbers are on the table.
The Solution:
What would you do if I told you that there’s a gem for that?
Let’s talk about the ‘phonelib’ gem and why the world needs to know about it’s existence.
The ‘phonelib’ gem can do everything that our problem asks us for and more! In other words, it’s an excellent way to validate almost every aspect of a phone number if you happen to find yourself in that situation. It’s based off of Google’s libphonenumber, which you can check out the documentation for here. Also, for the documentation for this gem, which goes over more than this blog does, click here!
Now let’s get started implementing this gem into our Rails backends.
Step 1: Install the gem
This step is pretty easy, simply add this line of code to your .gemfile and bundle install
gem 'phonelib'Double check your .gemlock file to make sure that it has made its way into your projects.
Step 2: Make a default country code
If your project is based in a certain country or you would like your country codes to default to a certain country, you can easily do this with the ‘phonelib’ gem.
To start, head to your config/initalizers folder and create one called phonelib.rb
Next, enter this line of code into your new file.
Phonelib.default_country = "US"Note: If your default country is not the United States, you can check out a list of 2 letter country codes here.
Step 3: Phonelib Validations
Assuming that your phone number attribute is called phone_number your class containing might look like this while implementing the ‘phonelib’ gem.
Let’s dissect this first starting with our validation, and the go into what our format_phone method is doing.
On line 3, our validations start by initializing the phonelib gem using
phone: { attributes_you_are_validating } Inside of our phone object, we’re using keywords given to us by the ‘phonelib’ gem. In this case, possible: true, is referring to if the information given to the :phone_number attribute could be a phone number. This checks for things like letters and the length of the phone number. The other validation, allow_blank: false, tells our database to not allow a user to enter an empty form for the phone_number attribute. For a full list of possible validations, scroll back up to the introduction of the gem and check out the docs!
The final validation uniqueness: false, is allowing a user to have multiple devices with the same number. If uniqueness was set to true, phone numbers could not be duplicates in our database.
Step 4: Formatting Phone Numbers
Let’s move onto our class method for a device called format_phone.
If you take a look at line 4 in our example, you’ll see how we’re implementing the ‘phonelib’ gem to format our phone numbers. When we use before_save, it’s going to correspond to a .save method in our controller and will trigger before that save happens. This way, a user can type whatever they want, but before it goes to our database, it will get formatted in the way we’ve told it to.
In our format_phone method, we’re calling the phonelib gem itself, telling it to parse what our user inputed as phone_number at to change it into an e164 format. If you’re new to the formatting phone numbers, check out what e164 means here. Once it’s changed into the format we like, it will save to our database.
