How I Added Different User Types to my Application
To set the scene, I was building a Basketball themed app designed for coaches and players who belong to any team. As I began thinking about and coding the functionality of this application, I came to realize that though coaches and players are both users of the application, I wanted them to have different experiences.
In short, the General Managers of NBA teams are responsible for trading, adding, or dropping players. On most street teams, the coach usually takes on more than one role and serves as the GM. In this case, the coach has the ultimate decision to add, trade, or remove players from the team. As an individual player on a team, you have the right to leave a team but you can not make that decision for other players. Also, a player can not just wake up one day and decide to be a part of any team they like. A player has to be approved by the coach in order to join the team.
How does this translate into my application? Well, I need to be able to know which of these users are coaches so that I can allow them to have permissions that players don’t have.
At first, I began making two separate tables within my database, one for players and one for coaches. The more I worked in that way, the more I realized it wasn’t the ‘DRYest’ way to code. Players and Coaches have all of the same attributes, simply different permissions. Due to this, both database tables were identical and I found a chance at refactoring to not only make it look nicer, but I also learned that this way was much more efficient.

Here is the representation of the new users database table that has replaced the separate players and coaches table. The only difference is that I have added a new row named “role” set to an integer value. This one row is what will give me the functionality to be able to differentiate the role of a user between player or coach.

With the help of the enum keyword, the role value within the users table can either be coach at index 0 or player at index 1. In plain terms, if I want to show that the user is a coach, the user’s role should be saved as 0. If I want to show that the user is a player, the user’s role should be saved as 1.
Now that my database can tell what type of role a user has, how will I translate that to the frontend, or in other words, find a way to have the user properly indicate if they are a player or a coach in order to handle their account properly?

Within the sign up form where a user initially inputs all of their required information in order to make an account, I have added two radio buttons. Ive made them radio buttons because they have the perfect functionality to only allow one to be selected at a time, and since in this app a player can not also be a coach, this worked perfectly for me. The labels of the buttons say “Coach” and “Player” so that the user knows what each button represents. However, the value of the buttons are the integers that indicate to the database what the role is.
In this case, fictional coach, Kyle Thomas, clicks on the button that he sees labeled as “Coach” but really has a value of 0. The form is then sent and here are the results:

As we can see, with the help of the enum keyword, Coach Thomas’ role is rightfully, coach.
Now, Coach Thomas’ experience within the application can properly be tailored to fit the needs of a coach.