I’m finishing up my second build week at Lambda School. This time around, I used React and Redux to build an app that ingested data from a back end server my teammates wrote in node.js. It was provided to them by the Data Science members of our team, who pulled it from the Yelp API.
^^ sign up with any un/pw combo you like.
The MVP specs were:
- Data Science: do a sentiment analysis of every yelp review to arrive at a score for that review.
- Front End: Build a React app that displayed the restaurants being reviewed, and could toggle between the adjusted score and real score for those restaurants. Route to reviews for individual restaurants. Build a login that stores a JWT token in local storage.
- Back End: Connect data science and front-end. Deliver JWT token to front-end.
I built an app that did just that, fetching data from the server and using redux to manage which components received what info. Even with just three pages, things get complicated. Redux makes it easy for each component to access a global state whenever they need it, but it’s tricky to figure out when to update that global state. I worked with dummy data and dialed everything in for the first four days of the week while data science worked their magic.
Right around Feature Freeze (think “pencils down”), I got the real dataset from my teammates. There was a minute difference in the way the objects were formatted — adjusted reviews were on a second data set — and it screwed up every component downstream of the GET request. As it was written, my app was useless in interpreting the data as it was provided. For demo, I’ll just be using the dummy data, which is a real let-down.
But there are some great things I took away from this week.
- Hammer down your file structure early. I spent four hours this afternoon working out kinks trying to deploy because build scripts were looking in the wrong folders for dependencies that I’d deleted two days ago. It’s easy to let this stuff spiral out of control (“Ohhhhhh, Material UI is pretty” *yarn add @material-ui/core* “Actually this will be more of a pain than it’s worth to refactor”).
- Be more semantic in how you name components. I had ‘restaurant’ and ‘taco’ used interchangeably for a couple of days because I thought ‘taco’ was funny. It’s wasn’t. It was not funny at all. Pick a word that describes what you’re trying to build and use it consistently, and with modifiers that describe why they’re modifying it.
- Building a UI around a data set requires that you know what that dataset is and is not going to provide. It requires that you have a clear understanding of how the data is going to be formatted, and what parts of that format are important.
- I am BAD at making things pretty. I just lose interest in making design decisions beyond those that impact functionality.
It’s an exhausting week, and it sucks to not have a finished product to show off. But I feel infinitely more comfortable in being able to navigate and manipulate complex states, and to use those states to dynamically change the UI of an app. And I guess that’s kind of the point.