DEV Community: Pandaa

Project 2 Final Post

Pandaa — Mon, 10 Apr 2023 03:31:55 +0000

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?

Project 2: Week 12 Check-in

Pandaa — Mon, 03 Apr 2023 03:41:53 +0000

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.

Frameworks, Web Components, and Me (Week 7)

Pandaa — Mon, 27 Feb 2023 04:26:10 +0000

Introduction

Welcome to my little corner of the internet! The wonderful world of webdev is a really interesting space that I've only gotten a small taste of. The technologies contain a lot of great features that I've come to love, but they're held back by many shortcomings when it comes to onboarding. Now that I'm seven weeks into my journey, I'd like to write a brief reflection about my experiences exploring the current landscape.

What is confusing about platforms?

I think the biggest source of confusion for me was just the sheer amount of options out there. There are so many different platforms/frameworks with so many different rules and design philosophies. It's difficult to keep heads or tails of things, especially if you're jumping between them on multiple projects. Some platforms match the vanilla behaviors of our main programming languages (HTML, CSS, and JavaScript), but most end up wanting to do thing their own way with changes completely distinct from the competition. The inconsistency makes my brain melt...

How could web components and VanillaJS standards be taught in a way that is more approachable?

Both standards could benefit greatly from simply providing users with more concrete examples and thorough explanations in their documentation. A misstep of both is that they don't handhold newcomers through the setup process. The Mozilla MDN that VanillaJS relies on is a great resource with tons of useful information, but it reads like gibberish to people with no prior experience. The available web component documentation, on the other hand, just isn't populated with nearly as much content due to how new and niche the platform is. Beginners need everything explicitly explained to them. They don't know what a querySelector or a scaffold is but are expected to make use of them almost immediately.

Luckily, Vanilla JavaScript has thousands of tutorials as a benefit of its age, but web components aren't quite so fortunate. I believe that it would be helpful if these resources both offered some fully completed basic projects for new users to poke and prod. I find that being able to mess with something that already works helps a lot with early learning. Outside of tutorials, this is a great way to demonstrate exactly how different functions can typically be used for various purposes.

What did I find easiest to work with on 1st stab?

I definitely found VueJS the easiest to understand on my first attempt. I may be a bit biased because I was given the most time to learn with this framework. However, my rationale is that I liked the framework because it didn't feel too different from VanillaJS in syntax. Although it had some of its own quirks such as the heavy use of <template> tags, it felt very readable, for the most part, compared to platforms like Angular and Svelte. Web components shared in this readability advantage but lost when it came to creating JavaScript events. Many of the others required knowledge of what a DOM (Document Object Model) is and how to utilize alternate versions of it. VueJS, on the other hand, felt especially simple and allowed me to easily write standard functions with vanilla logic. For each individual webpage in VueJS, almost all the action happens within the same file, which removed the need for cross-DOM scoping.

Thinking back on the tooling. What parts were confusing? What clicked with me immediately?

I found the tooling fairly straightforward in VueJS. The HTML in it followed standard structure. Its CSS and JavaScript were also housed in pretty vanilla <style> and <script> tags. Additionally, they all accessed each other using the early methods I learned using CodePen. The one thing that threw me off initially was the <script setup> tag, since my functions only worked in the normal <script> tag.

With web components, what confused me was definitely properties in LitElement. They didn't end up being too complicated; however, I had skimmed past the part describing them in LitElement's own documentation. On the other hand, I found <slot> very easy to get a hang of. This is probably because it's pretty forgiving with incorrect implementations, meaning that it can become functional really quickly.

What additional readings did you have to do in order to make sense of things?

For the most part, official documentation, StackOverflow, and (of course) random webdev blogs were my best friends throughout my learning process. While the web component documentation was fairly lacking, Mozilla's MDN was invaluable for discovering and understanding the operations of all the vanilla languages. Alternatively, StackOverflow was excellent for coming across jury-rigged solutions to all sorts of tiny problems that were never addressed in documentation. The random blogs that I came across tended to feel much the same. I didn't actively search for them, but they'd always pop up when I was pursuing a really obscure question. It felt like striking gold whenever I got provided a functional answer on a basic webpage that hadn't been updated in 7 years! I can only imagine the aftermath if all these websites disappeared one day!