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…

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.

Popout Modal

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!

Snip of useSelector and useDispatch Redux Hooks
Snip of useSelector and useDispatch Redux Hooks

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.

Redux Action
Redux Action

The (User) Story So Far…

Lambda Labs 26 — Apollo Team C — Release 1 Walkthrough

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…

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.