How many elements did you end up going with? Why did you break it up that way?
Our group ended up using four elements in our project. They are called badge-card, badge-list, search-bar, and step-card in alphabetical order. This division came to us naturally as we tried to break down the functions of the webpage into simple components. The badge-card element is much like our previous card-list assignment, so it was the first that we implemented. It mostly served to build the base structure of each card. Next came the badge-list element, since it what's necessary to render the API data that we brought in using a fetch command. The thought process for this was almost entirely based on our early API homework in Week 10, where a similar element was used to map the fetched dataset to an existing Array property.
The search-bar was the most unique and unknown aspect of the project, which is why it was also broken into its own element. This houses a ton of jury-rigged code to read and clean user input. Finally, we broke off the step-card element because we wanted to retain flexibility for the number of steps in each badge. Our group wanted to ensure that each badge could support any number of steps. Although we could have made a fifth top-level element called badge-card, we ended up deciding to continue using the index.html file to stay with what's familiar to us.
What was the hardest aspect of this?
The hardest part of this project was most definitely creating the search bar. Although the professor eventually uploaded a video guide for how to implement it, we had already spent the entire previous weekend to solve it on our own. In total it took us about fifteen hours of work to get it working. Despite feeling extremely drained afterwards, our team feels great that we got it done.
Our process while working towards our solution was a time-consuming trek across the internet. It was all a step-by-step process, where we worked on little chunks of its function at a time. Many of these hours were taken up scouring StackOverflow for related implementations to reference. After this, we'd start taking a crack at the feature using previous knowledge about loops and boolean logic from other classes. CoPilot also acted as a great help with general syntax for Lit-Element and JavaScript.
If parts of the code didn't work, then we ended up throwing it at ChatGPT but probably not in the way most people would expect. Many people think that it'll replace our jobs and trivialize schoolwork, but at least with web development, the code solutions that it spat out were incorrect more often than not. Instead we mostly looked at ChatGPT to explain error codes or general concepts to us. After this, it often gave us enough information to GO ALL THE WAY BACK TO STACKOVERFLOW!!! And with more relevant articles, we'd finally come across some useful information on our problems. Our group bashed our heads against the wall way too much throughout this endeavor. To be perfectly honest, our team probably should have waited for the professor to release his guide, but we had thought it wouldn't happen.
The following code demonstrates how our program interprets user input in the search bar. The first function is attached to the input element as an event listener and includes the second function in its list of processes. After the second declares the necessary variables, a for loop is used to track through each character in the input. Using a technology called regex, the string associated with the input is scrubbed of whitespace and punctuation before being pushed to a new Array property.
Finally, the following event runs any time changes to our input property is detected. It runs a fetch function on an API JSON, before passing it through a filter. Our implementation is designed to be flexible and accepts a data entry as long as it matches at least one of the qualifiers. There is also a setTimeout function because we decided to do some extra work and implement loading screens. Unfortunately, Vercel is just too fast and awesome, so our screens didn't get any time to shine without setting minimum durations.
What part of this project was easier than you expected?
At first, we had believed that getting rid of the default arrow for the summary/detail element would be extremely difficult. However, after seriously searching for only a few minutes, we discovered how to implement it for all browsers using only two CSS properties and a pseudoselector. We were pretty shocked about how simple it was after actually taking time to go past the first page of Google results.
One other thing that ended up being much easier than expected was our loading screens. We had believed that some sort of complex logic process would be needed. However, we succeeded with only a single if-statement within the HTML render. That was very satisfying to say the least.
Isn't it beautiful?
Top comments (0)