Progression we've made
Our group managed to clean up several design aspects of the badges, such as centering the badge icons and coloring the borders according to spec. We surprised ourselves by also getting the majority of the JavaScript functions for this project working. Due to this, the majority of work that remains is the CSS side of the project.
A major feature that was added was implementing an additional API to hold data related to the "Steps to Complete" section of the badges. The secondary API was used to allow badges to have an unrestricted amount of steps, while preventing every badge from displaying every step. This was done by filtering the incoming JSON data to only associate when its tag property matches a badge's title property.
The steps are set up to render when a toggle event is expanded in order to keep the process dynamic.
Finally, we have used a custom event to keep the toggle process stateful. It is invoked in the index.html file, which is the application-level file for this project.
How did you get the relationship between searching and rendering results working
Our version of the search bar operates in a segmented manner across components. The majority of the filtering work occurs on the application-level in our index.html file. It operates by listening for changes in our custom input-changed element. After this, it detects whether the filteredInput array that it receives has contents. If not, then the complete API JSON data set is passed through the fetch function. But if there is input, then the array is used for a "filter" process that modifies which badges are displayed.
Our current function filters for whether any elements in the array match the title or author properties of the data set. The .filter() method only returns elements that pass as true. The .some() method returns true if any elements match between two arrays. The .include() method only returns true if all values match but works here since we're using it for each word one at a time.
Because our function changes the property that is mapped in the badge-list.js rendering file, this means that the component re-renders whenever the input changes.
As for how user input is interpreted, the following screenshots demonstrate the process. First, we have a function called searchInput() that functions as an event listener and records all new input into a string called inputs.
Our second method searchFilter() is where the real magic happens. It takes the string that we made and then passes it through a for loop and several regex statements. These are used to scan the string and cleanse it of irregularities, before returning it as an array. The first two check for whitespace and punctuations before and at their current position, while the third regex statement is used to delete any non-alphanumeric characters. We didn't know much about regex before this project but discovered the .test() method while searching for methods to get rid of specific characters. Afterwards, we went to town on regex calculators to come up with some jury-rigged solutions.
This custom element is used to make the function stateful and allow it to bubble up to the application-level file. This allows the program to listen for it and initiate the filter process.
Draw a diagram on draw.io for user interaction pattern
The following is our best attempt at creating a user interaction pattern diagram. It's our first time drawing such a diagram, so we are unsure whether it's been done correctly. Nevertheless, we do feel that we were clear in demonstrating what happens from user input, through machine sending value, to re-rendering on the page.
Think of a real-world example of how could we use micro-service architecture to solve a real problem at a company currently using a monolithic design architecture?
A great example of where micro-service architecture could be perfect is any storefront or e-commerce website. These websites often experience user traffic in ebbs and flows through the seasons. Due to this, if a website like Amazon used a monolithic architecture designed for their low season, then this could spell disaster during holidays like Black Friday or Christmas. These events often have massive explosions of users and purchases.
A monolithic design wouldn't be quickly scalable for this because the entire program would need to be retrofitted. However, with micro-service architecture, we would be able to independently scale whichever individual component was needed. Additionally, this would allow easier deployment of new features and services in updates. This is because developers wouldn't need to worry as much about bugs in one component affecting the rest. This makes micro-services both more sustainable and much cheaper in the long run for this situation.
More issues that we're stuck on
Our CSS is still not enough to make our webpage match the example shown in class. We have also faced troubles getting rid of the arrow that comes with the detail/summary tag that we're using for the toggle.
Our plan to solve this is to ask the professor and/or TA for assistance about how to best approach solutions for these issues.
Top comments (0)