Lock it Down!
Here it is, Part 2. The start of refactoring my Mod 1 CLI App. This blog post will look at why reading documentation is so important and how to implement Validation using ActiveRecord.
As discussed in my last post, during our CLI app project we spent a long time writing code that would ensure no user could have the same username or password. We also then made sure a user could login and be tracked through our app until they logged out. In short validating and authenticating our users.
If we had only read the Active Record documentation then we could have done this very quickly and more effectively: https://guides.rubyonrails.org/active_record_validations.html
This post will explore the first issue raised which was making sure no two users had the same information. Below is our original validation code for setting up a new user account:
This method doesn’t follow the single responsibility principal and doesn’t following good OO programming. As you can see the method is both asking the user for input and then validating the input and using this to create a new user account.
Let’s see how we can abstract this out. Firstly why isn’t the User Model responsible for validating the input?
Here we use the ActiveRecord method validates followed by our Models attributes for example user_name . We can then use several methods to help us define what our attribute should be like when our new user is created. In the above example presence: true means that the user must input a user_name otherwise ActiveRecord will not create the new instance of a User. The method uniqueness allows us to stop users from creating non-unique usernames. There are many other useful methods that we can use, just checkout the Rails Docs above.
Let’s see what happens when we try to create a user with incorrect data:
Above we can see a SQLite query that is checking whether the user_name and email already exist in the database — as they do not, it moves on and tries to create our new User . So far all looks good but if we were to look in our database our new User wouldn’t exist. So what happened?
ActiveRecord has seen that our request to create a new instance of user doesn’t meet our validation criteria and therefore doesn’t create it so it never reaches the database. This is great…but what now, the user doesn’t see anything and has no idea that they haven’t successfully created an account.
Well ActiveRecord also comes with a cool method called errors and another called full_messages :
We have now been usefully given and array of error messages which explicitly tells us why ActiveRecord didn’t save our new instance to our database. So now we can output to the user why they have been unable to create their new user account and give them another go. Here is the logic:
create_user_account requires a helper method where the user is asked to input their credentials. We give the helped method an argument of user which then becomes a blank new instance of User when we call create_user_account . This means that once a user has inputted correct data once but is prompted to input other data again due to failure in defining the instance they do not have to retype the correctly inputted data.
If incorrect data is given ActiveRecord will give us the error messages which we loop through and output to the CLI for the user to see and correct. Once all data given satisfies our predefined validation criteria the method then saves the new instance of User to the database.
As you can see ActiveRecord is hugely powerful and gives us so much helpful functionality but we need to know it exists in order to use it and this is why it is hugely important as developers that we READ THE DOCUMENTATION!
Next time we will look at how we can allow a user to login and keep track of them through a session in our app and when finished logout again.
Until next time…
