Freshly Fetched was a Mod 3 group project in the Front End program at the Turing School of Software and Design. The assignment was to build out a multi-page application using React, Router, and an additional technology of our choosing that we would not be receiving instruction on. We chose TypeScript! All of our user acceptance criteria was tested using Cypress.
The project spec can be found here.
Our project is deployed here.
- Clone down this repository
git clone https://github.com/Meekb/freshest-app - CD into your local clone
cd freshest-app - Install project dependencies
npm install - Run
npm start - Open
http://localhost:3000/in your preferred browser
- User flow visiting the site and searching for markets within 15 miles of 90210
- User flow showing filter by day functionality, a user searches for markets on Tuesday
- User tries to input bad zip and gets error message
- User clicking on a card and viewing details
This application was built by Ash O'Brien, Beth Meeker, Claire Fields, and Alex Kio; Front End Engineering, Mod 3 students at the Turing School of Software and Design.
This application was built using the React javascript framework with the TypeScript superset. Router was used for multi-page functionality. Cypress was used for testing. GitHub and Git were used for version control and collaboration. HTTP Request is being used to Get inside of an async await function.
We started this project by creating a living "DTR document" in which we discussed each other's learning goals, preferred working style, personal schedules, communication preferences, etc. We moved on to digest the project spec and rubric, and started exploring APIs brainstorming about the potential problems we could solve with each. We settled on this Farmers' Market API provided by the USDA. We then conducted research on similar applications and established our wireframes. We created this GitHub repo and initialized it with a PR template and a project board. We used Google Docs to outline our initial thoughts and project iterations and turned all of our user acceptance criteria into project issues. We spent the next two days independently studying TypeScript before reconvening to discuss our findings and begin issue assignment. We checked-in as a group daily as we chipped away at this project.
Typescript took a full two and a half days to learn, and came with a caveat: to use Typescript in React, it is advised to also use hooks. Undaunted, we built out an initial architecture as a team, before revising it to accommodate Router and facilitate the data movement we needed.
When we had a solid architecture functioning, we realized the API had some quirks. One endpoint only returned 200s, and the data shared between endpoints was scant and difficult to manipulate. Overall, this API caused us a great deal of time with data cleaning and error handling.
Finishing this project, I have a working understanding of Typescript, and a deeper understanding of React, Router, and error handling on the whole. In the future, I will be testing my API with more gusto, and planning the architecture of the app accordingly.
This project exemplified issues that can be encountered when api structure doesn’t match expectations. We had to do a lot of cleaning of data, and had to jump through quite a few hoops to consolidate the data we needed at first fetch. Additionally learning a new language - TypeScript - in such a short period of time was heavy lifting in the first handful of days and continued to be a challenge throughout as we learned how to utilize TS within React.
While it seemed like a slow start initially, spending 3 days up front to watch tutorials, play in sandboxes, and learn TypeScript (and Hooks!) really paid off in the end. Once we started coding, I didn't feel that TS was a big lift compared to JS. I am proud that in the refactoring stage, I was able to move all the component's interfaces into a types file using imports/exports and see opportunities to improve my TS flow next time. This was the largest group project we had been a part of up to this point and we wanted to try a rebase workflow for the first time, which was maybe not the best choice in hindsight. I am glad we got some exposure to a new workflow but it led to a lot of group zoom calls sorting through merge conflicts. As others will surely mention, our API was the biggest hurdle. We had never worked with an API that did not return 404 errors for failed fetches, nor had we worked with one where the data returned was so poorly formatted, with so much information missing in some cases. Our data cleaning and error handling became much more involved than we had expected. Now I have a much better idea of what to test before committing to using an API.
I knew going into this project that, per the usual, we were going to encounter many unforeseen difficulties along the way, but knew that if we trusted in the process and habits that have been taught up to this point that success was likely. We prioritized each other’s learning goals and committed ourselves to organization and process, and spent two days learning and playing with TypeScript before even starting to code. From there, we tackled this project with fairly consistent communication and support for one another, and found ourselves learning a litany of new things along the way.