 |
 |
 |
 |
|---|---|---|---|
Alec Caro |
Hammad Khalid |
Holly Phillips |
Stewart Morales |
HYPE is a social networking app for adults who haven't outgrown schoolyard games. Users can create and join-in on intramural sporting events, including hide-and-go-seek, dodge-ball, freeze tag, sardines, capture the flag, and more. The HYPE app will allow users to find fun ways to exercise, make memories, and form long-lasting friendships. In short, a meet up app for athletic adults, who are children at heart!
- User authentication system allows for secure user registration and login
- Event index displays all events in the database
- Search bar in the index allows users to quickly sort by title
- Event map allows users to browse by location, picking events in their area
- Event show page displays all event details, allows users to RSVP, and has a cute map
- Dashboard allows a user to see all events they're attending and hosting
- Avatar builder on the dashboard lets each user customize a little them!
This project was a first venture into MERN and NoSQL databases for the entire team. As such, NoSQL took us several days to wrap our heads around. The breakthrough came when we wanted to display additional user information on each "Event Show Page". Our instinct was to take the user's ID and search the database for a corresponding user. That's when we remembered reading about embedding. After a couple hours of watching videos, tinkering with code, and combing through documentation, we figured it out. The Mongoose populate method did exactly what we wanted...
router.get("/:id", (req, res) => {
Event.findById(req.params.id)
.populate("host", "username")
.then((event) => res.json(event))
.catch((err) => res.status(400).json(err));
});
When we saw the results in our database we were ecstatic. We started shouting "MONGOOSE!" quite loudly. The document/collection system of the NoSQL MongoDB allowed us to customize routes and pull data appropriately for each use case. We are all glad to have worked with this powerful tool under Hammad's steady guidance as backend lead.
As this project uses React and we wanted to use Google Maps, we felt that it was appropriate to utilize a relevant library. We started out using the 'react-google-maps' library, and got fairly deep into its implementation before realizing that it worked best with hooks. This was a problem because no one on our team was familiar with using hooks in React, refactoring all our compenents to use them was not an efficent option. This led to sloppy re-renders in our event map, which not only looked bad, but also ran up a bill on Stewart's google cloud account. We revisited the project after the deadline, and found out that the 'google-maps-react' library was better maintained and less hook reliant, allowing us to refactor and clear up this issue. The maps don't re-render on every click, and Stwart's bank account is safe once more.
The first version of our "Create Event Form" had users clicking on a mini-map to set the event location. This was not ideal, as we wanted events to have an actual written address. Holly took the lead on this task, and used the geocode API to convert an input string into a latitude and longitude. Next, in order to have the location input autocomplete to real world addresses, we utilized the 'Places' library. Seeing this autocomplete in action was one of the most satisfying moments of the project. Unfortunately, even with the autocomplete working, and strings being converted to LatLng, we still had issues connecting these pieces. The autocomplete locations were not properly added to local state. We were able to bridge this gap by adding an event listener to the autocomplete in the component did mount.
componentDidMount() {
const autocomplete = new window.google.maps.places.Autocomplete(
document.getElementById("autocomplete")
);
autocomplete.addListener("place_changed", () => {
const place = autocomplete.getPlace();
this.setState({
address: `${place.name}, ${place.formatted_address}`,
});
});
}
