Slices of State: My Journey from Pizza Guy to Full-Stack Engineer
Lambda Labs is an 8-week intensive apprenticeship program. It takes computer-science students who just wrapped up a 2-month curriculum dealing in comp-sci theoretical la-la land and puts them into a learning environment that mimics what an actual team of engineers do day-to-day. Now, that’s not to say that computer science fundamentals are unimportant, quite the contrary — they set up any software engineer to have core knowledge of the systems that the tools they use day-to-day are built from. But moving from theoretical learning to practical learning always forces one’s brain to totally change gears.
My Labs team is building Apollo — an agile development tool that aims to solve the problem that often comes up with auto-generated survey notifications: they get ignored. Apollo is meant to solve this problem by requiring topic channel leaders to provide current context for every survey that goes out.
My hesitations going into this project were many: how is a team going to work efficiently together when we’re all student-developers? Won’t it just be blind leading blind?? I also was concerned with my own React front-end chops. It had been almost 8 weeks since I even touched a functional component, let alone integrating a fully fleshed out scaffolding to fit the project. I was sure I would fail out and never be able to get a working product put together by release 1. And yet, here we are at the end of the first release sprint, with everything almost ready to go.
Into the oven it goes…
Some of the core functionality that solves the ignoring problem that so many daily notification applications face is to make sure the default questions that are asked of the users render dynamically, based on the context chosen. If the contextualized questions are simply a standard, one-size-fits-all list of typical questions such as “What are the blockers”, “How is the project going”, or “Is the timeline still accurate”, the people on the team who are expected to answer aren’t getting the best, most tailored questions.
This posed an interesting problem for us as the team of developers. We needed the context selected at the very beginning of the “Add New Topic” modal to drive which default questions were going to be passed in at the very end of the process by the topic leader.
The first step for getting the dynamic default questions to render based on which context was selected at the beginning, was to actually write out different context-specific questions that would be used as the defaults for each case. For example, if the topic relates to design, one of the default questions could be “Do you have any edits for the design team to make to the wire frames?”, or the engineering leadership may need to know, “Are the current load times up to speed requirement for the upcoming release?”
Once we had these custom default questions written out, they were ready to render dynamically — the most head-bending part of this component. What we decided to do was to log a numerical value for each of the radio buttons that could be selected on the first page of the new topic modal. Once they were selected, the topic state object would then be modified to show whichever index place of the default questions list matched the radio value.
Now we had our default questions rendering dynamically based on which of the topic radio buttons were selected on page one! We did it! We now could guarantee that the users who respond to the topic iterations would have properly selected context-based default questions that they would need to be asked.
This was a great exercise for me in re-learning the basics of component state management. We needed to pass props up and down the component structure, make sure we had our change handlers and click events all buttoned up, and ultimately were successful in getting proper context.
Oh yea… I actually need to remember how to build things!
Another more general challenge for me was actually getting the modal pop-out button to work from the navbar. It had been a while since I last used Redux for anything, so I needed to go back and re-read documentation for a refresh. In order to avoid some serious prop-drilling, I needed to make sure we could access the state by reaching out to a centralized store on the side, rather than reaching up and down the component structure.
The clear way to overcome this was to use Redux. It would help us take the pieces of state from one part of the app, and make it accessible by a completely different component. This allowed us to effectively get the modal to open and close by clicking a button on the navbar, a totally separate component from the modal itself.
The (User) Story So Far…
My team and I just wrapped up the first release of our product, Apollo. The release called for the ability for a user to generate a new topic and unique join code, login/logout, and view a list of topics that the user is currently a part of.
We have been able to ship a modal that is activated by clicking the “Add New Topic” button. It then prompts the user through four pages of radio buttons and input forms, gathering information that can be sent out in a POST request to the back end and stored in the PostgreSQL database. Once the pages are filled out, the user can submit the new topic. In the response of the API endpoint, the unique join code is then captured and displayed in a “New Topic Created” modal. This can then be shared with members of the user’s team so they can be added to the topic.
We also created the login/logout functionality that allows a user to gain access to secure routes in the app. Once a user is logged in, they can view their home page and all relevant information.
A Look to the Future…
For future releases, the focus will be on user interface, UI, and more user interface. Something we desperately need is a day or two spent on styling and rendering the components to make a nice clean home page. We are also going to be focusing on GET requests that pull in the user’s information and displays which topics they are a part of, and which survey’s are yet unanswered.
Something technically challenging will be setting up notifications. We have toyed wit the idea of adding the Twilio API to send out messages to the users, but haven’t yet fully explored it.
This project has forced me to stretch my React knowledge in ways I never thought I would have to. Not only with building out components that render on the screen, but also dealing with state that touches multiple components across the entire app. It allowed me to learn new techniques for adding Redux hooks to the app to manage state, a skill I’m sure I’ll use regularly from here on out as a React Developer.