My Lambda Labs Experience (The Good & The Bad)
What is Labs?
Labs projects at Lambda are 2-month long sprints meant to simulate a real internship at another company. Some projects within Labs roleplay projects in an organization while some projects are actual companies in the US that take on Lambdas’ students to make contributions. The project my group was assigned was a web app named “Citrics”.
The Problem.
Citrics is a city comparison app that allows users to search any US-based city, and compare up 3 to different cities. Allowing the user to make an educated decision on where to make their next move. Instead of searching different websites for different data points (i.e. rental prices, job industry, climate, etc.). Citrics will visualize those statistics of a city in one report.
Why are you playing so hard to get?
This is a question I asked myself many times when trying to access the component state of different cities I wanted to render in our report. Originally, we were continuously creating different arrays and pushing axios responses into those arrays, and while that was a quick solution on the top level. We discovered shortly after we added our 3rd and 4th arrays to push the new state into, it became near impossible to extract what we needed. We tried attempting multiple variations of the zeroeth index of an array, but the items were so deep that the code would not allow us to access what we needed.
Hindsight is 20/20...
The solution was so simple and we would have saved a lot of time if we had considered more options of handling state within our app. It was to set the state as an object rather than an array. We only needed to make 1 cities key, and the value is an empty array. The array would be 3 city objects to represent the user being able to compare 3 different cities.
This gave us 2 valuable improvements:
- Easier access to the response data by dot-notation
- Significant improvement in readability. Since each report card was separated into 3 separate city keys, this made following our code much more simple which makes bug-squashing much more efficient.
Where we are now
We are at a healthy spot right now, in terms of features for our first release cycle. Our requirements during release cycle 1 were the ability to compare cities (up to 3) and search and visualize city-data. Users are able to do both of those things, but here’s a more in-depth breakdown of features within those 2 requirements:
Users are able to search & visualize city-data:
- Autocomplete within the search bar is functional. As a user types, they can select their city within a list of options that match up to what they have typed so far
- Data for a searched city is displayed in either graphs or stat cards.
Users can compare up to 3 cities:
- The state of the city report updates correctly as a user adds/removes cities
- When the user removes the last city, the home page reverts back to its static state
What is next?
For our last release cycle, we have some interesting additions. Users will be able to see predictions of city statistics (up to 2 years out depending on the statistic). Users will also be able to search for a list of cities based on their preferences(i.e. search for all cities that have a primary job industry of technology).
