Presenting my Flatiron Phase 5 Capstone Project! — User/Admin access
I am very happy to write that I have completed my Flatiron School Software Engineering Live program! It has been quite the experience the past 3+ months, and I have seen immense growth personally and professionally. I look forward to reflecting more on my experience in a later post, but in the meantime, I want to share the Phase 5 Capstone Project that I have been working hard on for the past 3 weeks: BO(U)LDERBETA. (Note: this is a continuation of my Phase 3 Project). You can check it out fully deployed here https://boulderbeta.herokuapp.com/ and the GitHub repo https://github.com/jaybert0/BoulderBeta
Most rock climbing gyms have route setters who periodically change the routes on the wall. The routes will have different grips and difficulty levels, offering diversity for climbers of all types. Usually, this diversity means that there are routes for all, but the route setter will make changes based on what they feel is appropriate. There is not an open communication channel between climbers and route setters which can often be frustrating. As a result, there will be times when a climber will go to the gym to find that a route that they really like has been changed, often without warning, and that the kinds of routes they usually like are no longer at the gym. Opening up the lines of communication can give the route setter information on what people like and do not like, and give climbers information about the routes, the holds used, and of surprising importance when the route will be ended. Enter BO(U)LDERBETA.
One of the big features that I added from Phase 3, was Authentication. Users can now create their accounts so they can have access to the different climbing routes at the gym and their feedback on them. I also was able to create different experiences for regular users, and those with Admin access.
This is what greets regular users of the app, giving the user the ability to review different climbing routes:
Users with Admin access are greeted with this screen, which gives them access to change climbing routes, locations available to climb in the gym, and the different handholds that the gym uses:
This different UX for users and admins started in the backend.
The admin column is where it starts. The admin column has boolean values. By default when a new user is made using the Sign-Up UX, they are given a ‘false’ value for admin. To protect the admin’s ability to change the user-facing data, admin access (specifically changing the admin from ‘false’ to ‘true’) can only be done on the backend by the developer.
The backend only gives the user a boolean value. The frontend code changes what is rendered based on that boolean.
These snippets from the App.js file dictate what is rendered via React which can be seen in the screenshots above. While this renders the majority of the UX, this still leaves the NavBar which also had admin-specific tabs. A similar code was used for the NavBar.
By using if (user.admin ===true/false) return () I was able to increase the functionality of BO(U)LDERBETA to bring it closer to a product that can be used by rock climbing gyms.
