A Step Every Beginner Developer Arrives at

Inheriting a SPA

Project Breakdown

Creating meaningful products is one of my passions. I started off creating small applications to help me in the IT field, and that’s when it hit me, I’d rather be creating something meaningful than fixing computers all day.

Family Promise is an organization around the US that takes in homeless families, provides shelter, and addresses the root cause of their crisis. They help them rebuild their lives with new skills and ongoing support. To receive that support the family has to fill out an intake form of 30 pages, for homeless families this process is an ordeal. The process is long, answering questions while watching your kids and dealing with trauma is hard.

Our objective: make the intake and management system easier on families and employees

To accomplish our objective, we need to digitize the intake process and integrate it into a management system. The first iteration integrated the intake form, and reduced the average time from 35 minutes to 15 minutes. The second iteration focused on improving the user experience and giving supervisors and case managers data visualizations about each household. This round my group was in charge of fleshing out the Executive Director dashboard, integrate DocuSign into the intake form, and implement Facebook authentication for easier login and data population for users.

Up until now, I have been working on projects with smaller codebases, and I had concerns about working on a bigger codebase that I inherited from my previous cohorts. I was worried that if I changed a line or two the whole application would break. I had concerns about how to work with a database hosted somewhere else instead of locally, it was later that I learned these were the least of my concerns…

Diving right into the codebase

My group split the three features (Executive Director dashboard, DocuSign integration, Facebook app integration) by volunteers. We had two dedicated members working on getting DocuSign working with our app, and the rest of us worked on Facebook integration and the Executive Director dashboard.

Our Facebook implementation was simple enough, we were using Okta as our user authentication, so we used Okta’s integration of Facebook in their sign-in widget. Following the documentation, my teammate created a Facebook developer account and I populated the widget with the properties and id given by Okta.

Now, to get our Executive Director dash up and working. To our delight my team found out that we had an already existing and semi-working dashboard (hard coded data, but the UI is there), so we decided to test it. The flow is:

Guests -> Reserves Beds
Supervisors/Exec Director -> Checks them in/out

Except, the reservation button for guests was not fully functional, so we can’t check them in or out.

When inheriting code, you get the good and the bad

Over the course of a week, me and my teammates got together to tackle this issue. We went through the code for the backend and front-end for making guest reservations, I had to get familiar with the entire codebase. Two different cohorts worked on this app before my team got here, and I was in for a surprise. This had been the biggest codebase I’ve worked with so far, and inside this codebase was multiple state management systems. Scanning through the code, it looked like the team was shifting to redux; so we had half the state in a redux store while flip flopping the use of Redux’s connect function, and useSelector hooks to access our state. Adding to this, each component also had their own local state that is passed through as props. This was just how state was being handled, our app’s styles were also coming from Sass, styled-components, Material-UI, and Ant-Design. There were a lot of libraries to take into consideration.

Fortunately for us, chrome’s dev-tools made it easy to identify which component/file the issue was in. During our combing of the codebase (specifically the guest dashboard) we found that the guest reservations were hardcoded. No relevant data was actually getting made and passed to our database, and the reservation button also allowed our guests to reserve more beds than needed.

Since the state management was moving towards redux, I created new actions and reducers to populate our state and use that for filling in our reservations while deleting the previously unused calls.

Guests were also not allowed to make multiple reservations if they already had one made for that date.

Now whenever a guest logs in with a reservation, they have the ability to cancel and make new reservations with their data being updated into our database. With our reservations working and giving us proper logs we were finally able to get started on adding more features to our Executive Director dashboard.

Our features and the future

Getting the reservation button functional counts for one of the features we’ve released, the rest are:

• Facebook sign-in, signs in users and connects them to Okta via email account
• Executive Director dashboard shows the number of people making reservation and their check-in status
• Executive Director or supervisor can check people in.

• Executive Director has access to check predictive data for 90 days and 365 days

Of course not everything has been fully implemented for our iteration. In the future we still have to grab user information via Facebook, and fully implement DocuSign for the intake form. A challenge right now is Facebook creating duplicate accounts if the email used on Facebook was different from Okta. This made it difficult to grab user data for the right account. My team brought this up to our stakeholder and we figured that since the supervisors are the ones making the account we would have to integrate Facebook during the sign-up process, either to get their Facebook email and link that to Okta (during sign-up) or have an option to sign out the supervisor to sign-in to Facebook and make an account. There is also the question of how to save Facebook user information and pre-populate DocuSign fields.

A month of experience and learning

My peers tell me I can use growth when it comes to taking time and reading documentation. I rush into the code too fast and need to think about what I’m going to code and how I’m going to accomplish that. Through the month working with Family Promise, I’ve taken this feedback to heart and started off with reading documentation and planning before acting. This helped me get the Facebook sign-in integration done faster since I was able to catch that Okta had Facebook integrated into their widget.

Consistent communication played a key role as every time I met with my team we were able to fix each other’s issue whether it be setting up a local back-end or the discovery of a new bug. I was able to cover my teammate’s weaknesses and they were able to cover my weaknesses. In our meetings I was even able to teach relevant shortcuts when coding such as using ctrl+click to quickly open up a component.

This project helped me experience what its like to inherit and work with existing codebases. It taught me that good preparation and consistent communication can help a lot in getting issues fixed/ accounted for. If there was anything else I can take away from this project its that: its okay to change the existing code if it is not relevant to what your end product is.