Forem: Nick Alico

Creating a Sorting Game

Nick Alico — Mon, 13 Dec 2021 03:42:04 +0000

Overview

I had the opportunity to work with a team of fellow developers to create a fully-fledged, interactive component as the culimation of our efforts learning component-based design and development using JavaScript. Using LitElement as our JS web component library, we developed our project with the intent of creating a versatile component that could be adopted for use within the Open-source Hax-the-Web project.

Our team decided to create a sorting game where users are able to sort items in a list-based fashion, either by dragging or via buttons, until the correct order is achieved.

Here is the NPM link if you are interested!

This is the original sorting game we targeted to reproduce as a web component: "Sort the Paragraphs"

Buttons

Dragging

Tutorial

In order to develop this sorting game, our implementation fell into 2 primary elements within the component. One is the frame (SortableFrame) and the other is the reusable option card (SortableOption).

Dragging was particularly challenging for myself specifically to try to wrap my head around. Initially, I went down a very difficult path where I was attempting to great one universal event listener in the SortableFrame that would handle an option every time a drag was started. This meant that I was creating a sortable option, and below each card was an associated droppable area. I then intended to toggle this droppable area depending on whether the card actively being dragged was dropped within the bounds of that drop area.

The problem with this approach was that it was very difficult to discern different types of drag events (dragstart, dragend, drag, drop, etc.). It was also a haggle to re-append drop zones once an option card was moved in the list. I was warned that the edge cases for this approach would be incredibly tedious, so instead our team took the route of applying one drag handler to the sortable option that could be reused within each option. This way, it would only be triggered when that element itself began its drag.



  // The Mouse position, drag position, and offSetTop logic was taken nearly directly from Sean's SlimeSorting Implementation
// The overall idea of how to go about dragging to sort each option was taken from Sean as well

drag(ev) {
const pos = ev.clientY;
let currentIndex =  0;
this.dragPosition = this.position - this.offsetTop;
if (pos !==  0) {
    this.position = pos;
}
for (let index =  0; index < this.parentElement.children.length; index +=  1) {
    if (this === this.parentElement.children[index]) {
        currentIndex = index;
    }
    if (window.innerHeight - this.parentElement.clientHeight <  300) {
        if (this.offsetTop - this.position >  0) {
            // https://stackoverflow.com/questions/9732624/how-to-swap-dom-child-nodes-in-javascript
            // https://stackoverflow.com/questions/4793604/how-to-insert-an-element-after-another-element-in-javascript-without-using-a-lib
            this.parentElement.insertBefore(this, this.parentElement.children[currentIndex]);
        }
        if (this.offsetTop - this.position <  40) {
            this.parentElement.insertBefore(this, this.parentElement.children[currentIndex +  1].nextElementSibling);
        }
    } else {
        if (this.offsetTop - this.position >  40) {
            this.parentElement.insertBefore(this, this.parentElement.children[currentIndex]);
        }
        if (this.offsetTop - this.position <  -60) {
            this.parentElement.insertBefore(this,this.parentElement.children[currentIndex +  1].nextElementSibling);
        }
    }
    this.disable();
    }
}

I want to give major credit to Sean for not only discovering how to use offsetTop and the cursor's current Y position to calculate the distance dragged before a dragged item should move, but for also taking the time to explain to me how he came about his solution and why it works. All credit goes to him for discovering it and allowing me to use it as well. I really struggled to implement something similar on my own volition. While I would have liked to find a novel solution myself, I ended up following his core cursor position and drag calculation detection logic as the structure of my team's draggable component logic. Please check out Sean and his group's implemention of this card sorting logic, all credit goes to him.

I then went in and worked on editing the parameters to detect our desired drag distance, as well as attempted to put in some additional handling related to how far your have to drag your cursor on smaller screens where not all options may be able to fit on the screen at once.

Another novel approach I thought was really cool was the use of the Fisher-Yates (Knuth) Shuffle algorithm, which was suggested to me via StackOverflow when I was trying to find the best way to randomize the game's options when you first start to play. Here is the source I duplicated to implement this sorting algorithm.



// Fisher-Yates (Knuth) Shuffle
// https://stackoverflow.com/questions/2450954/how-to-randomize-shuffle-a-javascript-array

let currentIndex = question.answers.length;
let randomIndex;
// While there remain elements to shuffle...
while (currentIndex !==  0) {
// Pick a remaining element...
    randomIndex =  Math.floor(Math.random() * currentIndex);
    currentIndex -=  1;
    // And swap it with the current element.
    [this.randomized[currentIndex], this.randomized[randomIndex]] = [this.randomized[randomIndex],this.randomized[currentIndex],];
}

Finally, it was also interesting how we ended up disabling the up arrow on the upper-most option and the down arrow on the lowest option. It was suggested to use nextElementSibling as opposed to our original use of nextSibling. nextSibling can actually return a blank, whitespace TextNode as the "next sibling" when items are injected into the DOM, so it was really interesting to come across this issue. This is an explanation. Here is the function for disabling the down arrow:



downbtn() {
    if (this.nextElementSibling !=  null) {
        const after = this.nextElementSibling;
        document.querySelector('sortable-frame').shadowRoot.querySelector('.frame').querySelector('#options').querySelectorAll('sortable-option')
        .forEach(option  => {option.shadowRoot.querySelectorAll('button')
        .forEach(but  => {
            // eslint-disable-next-line no-param-reassign
            but.disabled =  false;
            });
        });
        this.parentNode.insertBefore(after, this);
        this.disable();
    }
}

Resources

Our team used a number of very helpful resources to assist with our implementation. As suggested by other developers, this CodePen was suggested as one possible way we could re-engineer the sorting aspect of the component. This implementation actually uses an older version of LitElement, so it was very interesting to use this as a baseline even though we really didn't go down this route a ton.

Another cool implementation I found, one that focused more on the design side of a sorting game than the development side, was this awesome post put out by Darin Senneff on 11/8/2021. This design is leagues above our implementation, so I highly recommend checking it out if you want to make your own insanely thorough component.

Another reference I used was suggested to me by a fellow developer as a way to import and process JSON files containing user-generated questions and answers. Using the Hax-the-Web support for modular web components, our team used the HAXSchema to wire-up this game to support user-generated questions. Following a standard JSON format, users who reference a local JSON file containing their questions and answers will be able to support their own sorting game questions! This is the function that was sent to me to help me reverse engineer some support for reading JSON files into the component.

In the project, we also used the SimpleIcon and SimpleIconLite libraries for the arrow icons for the buttons on our card options. Here is a great tutorial.

CodePen and Github links

Note: Dragging kinda works in the embedded CodePen, open the link to fully interact!

table-in-the-corner / project-3

A Project EdTechJoker creation

See https://github.com/elmsln/edtechjoker/blob/master/fall-21/projects/p3-haxtheweb/README.md for requirements to complete this project.

Quickstart

To get started:

yarn install
yarn start
# requires node 10 & npm 6 or higher

Navigate to the HAX page to see it in context. Make sure to change rename-me in ALL parts of the repo to your project name.

Scripts

start runs your app for development, reloading on file changes
start:build runs your app after it has been built using the build command
build builds your app and outputs it in your dist directory
test runs your test suite with Web Test Runner
lint runs the linter for your project
format fixes linting and formatting errors

Tooling configs

For most of the tools, the configuration is in the package.json to reduce the amount of files in your project.

If you customize the configuration a lot, you can consider moving them to individual files.

View on GitHub

NPM Link: https://www.npmjs.com/package/@table-in-the-corner/project-3

Don't hesitate to reach out if you have any questions. Thanks for your interest!

Passion Project

Nick Alico — Mon, 08 Nov 2021 02:19:15 +0000

Often as developers, we get asked what we do, how we contribute to a project, etc. etc. We don't usually get asked about what we would do if we had infinite time, unlimited resources, none of life's nuanced responsibilities; What project would we work on if there were truly no limitations stopping us?

For me, the answer to that question would undoubtedly be related to design systems. Specifically, I want to make an open source web platform that brings the ability and interests to students, hobbyists, and professional designers and developers alike in an effort to show the importance and purpose of creating accessible design systems for any use case or project. I spend a good portion of my internship this past summer working on using an internal design system to build an updated design for the application I was working on that followed these updated design standards. I've grown very passionate about design systems, and think they really are the future of bridging the gap between design and development consistency. The issue is that design systems are almost solely developed and used by larger companies and created/maintained by hyper-specialize teams.

My vision is to create a design system platform, where individual users and small teams coming from no experience to expert status related to design systems can come to one place to find details and content to help in their design system's development. Just starting a design system at your start-up? My platform will support a comprehensive documentation and resources component that will be community-driven to help users discover a learn about how to get started or expand upon a design system. The platform will include references to other design systems to allow users to research and reference established systems to gather their own ideas. The site will also support a snippets section, where categorized component types will be grouped together and filterable to allow anyone to easily include components into their own project. The platform would additionally support a chatroom/blog-based feature that allows people to share their development progress as they design and create their own design systems. Here users could chat, ask questions, or gain community advice and guidance regarding their own design platforms. The point is that design systems should be encouraged and supported to be built and used by everyone, not just the team of 20 principal designers and developers at a FAANG company.

I would use this platform as simply a maintainer and co-manager of the open source platform. I would also help to advocate for education in design systems for students, junior developers, and for companies of all sizes looking to create their own systems or component libraries.

Accessibility is another huge piece of the puzzle that is missing from like 80% of design systems. Development teams continually refuse to prioritize making accessible elements and/or supporting accessible components in design systems. According to Useablenet and Monsido, there were 3500 digital accessibility lawsuits amassed in 2020 alone! I want to help change that. This design system "information database" would dedicate an entire portion of the platform to explaining, justifying, and displaying examples of components and design systems that were designed with accessibility in mind. I'm a believer that the future of web design MUST take accessibility standards more seriously. There is no reason we should be excluding upwards of 1 billion people (by 2010 world estimates) with a disability from accessing what should be a universal public utility: high-speed internet (WHO, 2011).

I want to get started on this project, to help bring the word that people who are interested should just start a design system. It does not need to be a perfect system from day one. The point is that they are always iterative and adapting to meet the needs of the company. I think there would be great promise once more of the public was able to see actual examples of the systems being implemented that result in improved efficiency in design and development teams at all levels. The future is design systems, and I want to help pioneer that message.

Sources:

Header image: https://pixabay.com/photos/plans-design-web-design-designer-1867745/
Creator: https://pixabay.com/users/pexels-2286921/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=1867745

Slot Composition in Lit - What it is and how it is used

Nick Alico — Mon, 25 Oct 2021 02:49:05 +0000

Slotting, or slotted composition, is one of those technical concepts that can be very confusing to initially understand. Its modular rendering between elements can make it difficult for people new to Lit to see the changes they are making and how the updated content is actually rendered.

For this assignment, I have been working on re-engineering a modular card component:

In order to make the constuction of this component more modular, it was determined that breaking down the component into smaller elements would be a fantastic way to allow for the dynamic rendering of content, such as the type/theme of the card, header and subheader content, card body content, or any other media you may want to place in a card.

I think the official Lit documentation on slots is a great resource to check out, as I will be covering the content here as well.

At a simple level, you can think of slots somewhat like a modular container that you have complete structural control over. Slotting gives you the ability to pass dynamic content between different elements that you create, while supporting the ability to struture the rendered HTML and content however you see fit! This passage of content allows for abstraction of code in each element so that it is much easier to read and follow where content is being passed.

For example, take a look at the banner code which contains the icon and banner headings of the card:

CardBanner.js

<div id="bannerElement">
    <sci-card-icon
    icon="test"
    my-icon="${this.myIcon}"
    type="${this.myIcon}"
    ></sci-card-icon>
    <div  id="banner">
        <div  id="headers">
            <slot  id="main-header"  name="main-header"></slot>
            <slot  id="sub-header"  name="sub-header"></slot>
        </div>
    </div>
</div>
<script  type="module">
    import './src/app.js';
    import './src/SciCardIcon.js';
</script>

Here, we are defining two slots using the <slot> tag. This example performs slotting using named slots. The custom name use choose will be used as the name that you will use where you want to actually render these headings on the card. If we migrate over to our Card.js file, we will see a <div slot="main-header"> which you should recognize when it was defined from the above <slot name="main-header">.

Card.js

<div
class="slot-wrapper"
data-label="Header"
data-layout-slotname="header"
>
    <sci-card-banner  my-icon="${this.myIcon}"  type="${this.type}">
        <div  slot="main-header">
            <slot  name="mainheader">${this.mainheader}</slot>
        </div>
        <div  slot="sub-header">
            <slot  name="subheader">${this.subheader}</slot>
        </div>
    </sci-card-banner>
</div>

The <div slot=""> is the keyword reference used to tell Lit how we want to structure the rendering and where we want the "main-header" and "sub-header" text to render relative to the icon in the banner. The astute eye will notice that Card.js is using yet another slot tag within the already defined structure of slot=main-header like we discussed. ${this.mainheader} references the actual text we want to render, but Card.js isn't the highest element in our scaffolding that we are rendering. We now see <slot name="mainheader"> encapsulating that header text. One level outside of that, we see the entire outer DIV is labeled as <div data-layout-slotname="header">. Let's go look at the outermost layer of our element tree: CardFrame.js.

CardFrame.js

<div>
    <sci-card  type="${this.type}">
        <div  slot="header"></div>
    </sci-card>
</div>

Here, you can see that in a very clean and modular manner, we are simply specifying that inside our sci-card (Card.js) element, we want to have everything that's rendered inside it to be from the slot with name="header", which directly references the outer DIV in Card.js. Therefore, we can now see that the entire HTML of that specific card banner will be rendered within the <sci-card> tag. This is great for readability, and makes it clear to developers that all they have to do is find where a slot with name="header" is defined in order to see the next layer of slotted content

Please take a look at the official documentation for an even simpler example of using slots.

I hope you learned something useful from this escapade into slots!

Check out the project if you are interested!

Header image provided by: https://i0.hippopx.com/photos/386/749/243/programming-html-code-coding-preview.jpg

Analysis of Building a Web Component

Nick Alico — Sun, 10 Oct 2021 19:39:42 +0000

Design, Build, Extend

I like to approach the idea of designing and building a web component similar to how I have been trained to approach UX Design: following the Design Thinking Method. For those of you who are unfamiliar, the Design Thinking Method is a design approach which incentivises considering all potential aspects and perspectives of design, and applies an iterative approach to discover design components, user requirements, and refine implementation decisions. The 5 part system consists of:

Empathize
Define
Ideate
Prototype
Test

Courtesy of the Hasso-Plattner Institute of Design at Stanford

Let's break down how these 5 steps dictated my considerations and approach when building a web component and developing on its API.

Empathize
- We do this innately, but in the form of web components it's important to think about the type of component you will be developing and the people that will be using it. What is the background of the people who will likely use the component? Are there any usability and/or accessibility considerations that you will need to prioritize to meet the needs of your stakeholders? The goal is to try to paint a representative picture of the types of people who could use your component, and the types of ways they may try to use it. What if you component was used in a fashion or application other than what it was intended for? Would it be able to support that user's or that developer's intentions? Becasue web components are meant to be reused and extensible, it is important to keep these concepts in mind so that you avoid developing such a restricted component that it impossible to have it apply to other needs and use cases.
Define
- Defining the web component and its API can be one of the most challenging parts of building a component as it is one of the most crucial parts of the entire development process. If your empathize phase has clarified a base need or functionality, this will likely indicate that your need is aligned with a base behavior that is similar to a simple HTML element or well-known component that exists on the web today. For my first web component project, I knew I was building a CTA button which immediately meant I would need to include some type of <button> and/or <a> tags to complete the click and action-based events that are performed when a user clicks on a CTA button. You are then able to think about the bounds of your component. What use cases do you want to design for and support natively, and what considerations are not as crucial to your component? Maybe responsiveness for an array of different devices is crucial, but the level of animation or "flashiness" is not a huge concern because you are aiming for a minimalistic component. Situating this stance will allow you to better identify where to focus your efforts and how to plan your building process.
- It is at this stage, once you have defined the bounds of your component, that you also need to consider the component's and associated element's APIs. What are the states that you need to design and implement for your component? What happens when you hover over it, or click on a button or icon? What happens when you use your keyboard to navigate to it? Is that behavior consistent with your hover behavior? Considering the states of your component will give you a better idea of the breadth required in building out the properties of you components. See the next section "Ideate" for further details on this.
Ideate
- This is one of my favorite parts of designing and developing software, the ability to have free reign over iterations of the design and structure of a project or component. The goal of ideating is to creatively and iteratively enact your plan for your component, and to specifically come up with variations and styles that you think would serve as interesting approachng to your component design. As mentioned above, the properties of you component come into play between the define and ideate stages. Think about the elements of your component, considering how the could change both with a change in your component's state or to meet the design needs of another developer. For the CTA button I worked on, my team and I considered aspects such as the button icon, title, whether the button was disabled, and theme properties such as dark or high contrast mode. Using these properties for the criteria to inform how you should develop CSS variations for you component will allow you to easily "reflect" certain properties within each implementation of your component. You can think of it almost as turning on or off a lightswitch: All a developer has to do is pass a value to that property on the component and they will be able to leverage a different design or theme. The reward of ideation emerges in the implementing and use phase, but it is a crucial step in driving the flexibility and use case support of your web component.
Prototype
- Here is the step where you are actually building out base versions of your component in an iterative fashion. At this period of the building process, it is important to understand that there are really no "bad" approaches: this is the point where you want to build elements into your component and style them in diverse ways from what you may initially think to be the correct approach. For example, I started out my CTA button using no animations because I thought it would be distracting from the button's functioning itself. However, our team ended up implmenting a fade-to-transparent transition on our button background that looks very smooth and is still fully accessible. Try using CSS variable to make this process easier on yourself, this way you can change the text color or font in one location in code, and see this change persist throughout your entire component. This is the best way to approach using themes, as you can simply overwrite the traditional component style with a themed style simply by checking the value of a reflected property on the component in HTML. Prototyping is meant for quick and dirty development in the beginning, and wil turn into a refinement process as you develop. This is done on purpose, and allows you to focus on more intricate logic and stylistic edge cases as your prototypes become more refined and situated.
Test
- Our final and often most disliked component of software development: testing. Testing is so crucial for any web component, as they are specifically designed to be reusable and adaptive components of code to allow for a wide array of applications and use cases. Testing for responsive design, accessibility, state management, navicability, etc. can be a nightmare as your components become more complex and add more elements into them. This is why I highly recommend using CSS variables for quick design manipulation, as well as the use of Storybook. Storybook functions as a customizable design library which easily lets developers implement and test different states, formats, and styles of their component side-by-side in one compact demo platform. It acts more as a visual testing platform, but allows for easy iteration and design management in later steps of the component development process.
- It is also crucial to write programming logic tests yourself as well. I won't go into this much, but it is crucial to understand whether certain content or data types will impact the functionality of your component. Most of this testing comes down to logic handling and edge-case recognition to see long-term benefits, but writing tests for your components will assure you are supporting a consistent experience across different states and use cases.

Component Breakdown

Naturally, your component will need to be broken down into its constituent parts based on the modularity and flexibility that your design requirements specify, as well as based on the actual HTML structure of your component. The more complex your component, and the higher number of nested HTML tags, the all the more crucial it is to scaffold out a clear structure of how each element behaves. For example, my first web component involved designing a CTA button. This button consisted of a <button> tag with an <a> tag wrapped around it. The purpose of wrapping the button instead of using only a button tag was to allow the CTA button to function as a button that acts more as a hyperlink than a traditional button. The use case dictated that the button needed to open a completely new URL in a new browser tab, so it made more sense to nest the button tag so that the href used for the hyperlink could be attached across the entire button as well as any other elements that needed to be added to the button. If you wanted to add other clickable elements to the button in the future, it is as simple as nesting those elements at the same level as the button inside the <a> tag.
The point of this example is to show that the way you structure and nest elements plays a huge role in the complexity of your CSS and the readability of your code. Poor element structuring can lead to messy CSS with dense logic to control different states, whereas a structured component like my CTA button allows for very simple implementation and customization as necessary by anyone intending to use the component.

Another component I am now working on consists of building a card web component. What is unique about the card compared to the initial button component I worked on is the fact that a card is a container of smaller elements. These smaller elements include a banner, content body, and an extensible icon. Our team was provided with a starter component that includes a basic scaffold of a card containing text and images, and demos a few different examples of the card's scaffolding to depict how the use of the type keyword can allow for matching of card CSS styles to a specific card tag itself. The component is expected to use the button I have assisted in developing previously as a devDependency to demo interactivity of the card component. The component will utilize LitElement properties and Lifecycle functions to keep track of updating the behavior of the card based on each state and property value.
For this component, it will be crucial to consider how each of these element's designs and dimensions will be leveraged together to allow for a cohesive stylistic experience when interacting with the card. For example, accessibility when users navigate with a keyboard through each of the elements is paramount, as we will need to be sure that a logical tab path allows for interaction with any actionable elements on the card. Another example would be the behavior of the card when a user clicks an item within the bounds of the component. We play to support a sliding card with hidden content behind the front pane, so it will be important in our scaffolding implementation to assure that selection of content inside the card will bubble up content and focus to the front pane of the card after click event occurs.

Provided Card Example

Expected Difficulties

Building web components is hard: there I said it. Handling the vast number of states, properties, design edge cases, logic edge cases, and behaviors while supporting the extensibility that you desire for your component means much of your time will be spent writing specific CSS and monitoring how you pass properties into your component. One of the greatest challenges I faced was structuring my CSS in a way that targeted specific states without overwriting other states or thematic behavior. If you have a poorly scaffolded component in the define and ideate stages, you will really struggle to reflect the visual aspects you want to have on your component behave the way it should in a readable manner.
Another difficulty I faced was with deciding when my prototype was "complete". I would argue that a web component is never really complete, perhaps by design, but it can be hard to know when it is ready to ship as a usable component. I found myself considering more complex state logic and subsequent stylistic behavior of my CSS button, but realized these ideas were more than I needed to support given the purpose of the CTA button in the first place. This doesn't mean you shouldn't extend and update your components, or at least build in support for this customization, but that you should take this into account during ideation so you minimize the risk of scope creep.

Reflection on my First Experience

Overall, my first experience developing a web component was an incredibly rewarding learning experience. I didn't really realize the complexity of considerations that went into designing something as "simple" as a button, so it gives me a great deal of respect for the designers and developers responsible for building our entire design systems and libraries at larger companies. These guides can become thousands of components and states as use cases become more precise, so having the forethought to look into how to ideate early while keeping a component's scalability in mind was a really valuable perspective to adopt as I continue into my professional career. It really comes down to motivation and consistency. The future of the web is component-based, and I think it is a highly valuable skill to bring component knowledge to your place of work as a front-end engineer. The modularity of web components really is the future of the web, and I think this will allow for a more simplistic customization process in the future of web design.
It became easier for me to understand how components can relate to larger components within a webpage, and how explicit component-based design can make it very easy to support additional requirements and use cases within a system later on. Compared to a "one-and-done" UI development approach, web components make this experience of designing for the future night-and-day.
Finally, I recommend working with partners when you are developing a component or set of components. You are really limited to your own mental model, which greatly restricts the use cases and value you may place on certain development decisions of a web component. Collaborating with others lets you test ideas more quickly, promotes your group to experiment and make mistakes, and will ultimately make you aware of more features and nuances of the platform you are using, whether that be LitElement or a JS framework such as React or Vue.

Please take a look into building your first web component! It's a fun and rewarding experience that creates a more customizable and inclusive internet for all.

Here's my group's button if you're interested: https://www.npmjs.com/package/@table-in-the-corner/invisi-button

Development of a Button Web Component: Our Progress

Nick Alico — Mon, 27 Sep 2021 01:18:20 +0000

Progress to Date

In terms of the progress made by my teammate and I, we have come a very long way from 4-5 weeks ago when we were first introduced to Lit and Web Components. To date, we have been able to create a Call to Action (CTA) button extended from this example we found on Teuxdeux's homepage. We started out by constructing a very basic button composed of a <button> nested in an <a> tag, and were able to grow our visual API to support various CSS styling designs. We have developed distinct visual and funtional support for four main button states: hover, focus, active, and disabled. We have tested for accessibility concerns regarding tab order and are continuing to leverage Storybook to investigate color contrast and support for other theming styles like our "dark" mode. Finally, out button uses some cool CSS transitions and rotations to allow out button to feel more animated and interactive. This is done when the user is hovering to dissipate to a transparent background while having our caret icon spin 90 degrees.

Difficulties Along the Way

My teammate and I certainly faced a few difficulties along the way, as is common for any new learning process. There were a few nuances within LitElement that took some additional research and instructor clarification to truthfully understand how certain functions should be used. Things like the Shadowroot, the <slot> tag, reflecting properties in the constructor, and using bindings like @click just did not really click with me initially. I am used to vanilla JS where these do not exist, so wrapping my head around where the Shadowroot lies in the DOM Tree and why it is so awesome definitely took some time. Now that I have a better understanding of why reflecting properties makes data binding a breeze, it has helped situate me in my current development style as well.

TIL

After really digging deep over the past few weeks into Web Components and Lit, it really has come down to one major theme for me: Accessibility is King.
There is really no reason that anyone from major corporations to small start-up could not prioritize their online websites and products following an accessibility-first mindset. While there is an initial learning curve, web components make it incredibly straight forward and explicit in order to handle events, select attributes, and ultimately leverage the CSS cascade to meet the varying needs of my group's button. For myself, I think the idea that you have the power to influence any and all component states and properties was a really humbling fact to understand once I could comprehend it. For example, working to have the same stylistic behavior appear both when a user hovers over the button as well as when it receives tab focus was a fact I wouldn't have thought about coming in. But now that I understand why this consistency is preferable, I find myself motivated to apply this notion elsewhere in my code. Another big realization I came to is the true value in writing succinct and logical code. Things like consistent CSS variable naming and carring those styles dynamically through different button properties and states is crucial for the readability of one's code. This is definitely something I need to work on further, but the division of styles, properties, and the rendering of the component make it very easy to comprehend how a component works if the logic is succinct.

Here's a link to our Button if you are interested! https://github.com/table-in-the-corner/invisi-button

JS Frameworks Boilerplate Exploration

Nick Alico — Sun, 12 Sep 2021 22:53:51 +0000

Boilerplate Commonalities & Duplicates

Each of the boilerplate repositories our group selected for Angular, React, Vue, and StencilJs includes the same basic developer tools to get up and running with a bare-bones environment. This includes a basic README file detailing basic commands of how to run your local project, and each boilerplate comes ready to serve a local web server with a single command. The boilerplates each possess a package.json file detailing what scripts are available and which dependencies are installed to run your boilerplate. One crucial detail that jumps out to me is the fact that each of the boilerplate's file hierarchies are nearly identical. There are separate folders for app files, assets, components and server code which makes for a very simple and consistent experience between frameworks. It is interesting, however, to see that the React, Vue, and StencilJs boilerplates keep all of the corresponding html, css, and tsx files of a component in unique component directories, whereas Angular dumps all of the component and routing files into one large folder. It's a stylistic choice but still interesting to note.

There is some overlapping functionality with the basic features you would expect to run out of the box commonly from a boilerplate. Each of the boilerplates comes with some form of testing support. Our Angular boilerplate supports running both unit and E2E tests, the React boilerplate supports general testing, Vue supports general testing depending on your customized preferences, and StencilJs supports running unit tests as well. It's good to note that each boilerplate comes with a basic "Hello world" component that shows you the basic structure of how a JavaScript or TypeScript component is exported, imported into the main app file, and rendered to the browser.

The React boilerplate uniquely comes prebuilt with a number of its own components to use, including buttons, lists, and toggles. Our Angular boilerplate includes route handling by deafult, which is not included in the other framework boilerplates.

Best DX

In my opinion, it appears that the React Boilerplate has the most convenient, scalable, and development-ready experience of the four frameworks. Literally touting itself as having the "best DX", the repo created by Max Stoiber and a number of maintainers comes prebuilt with support for hot reloading, i18n, offline-first development, continuous integration (TravisCI), SEO support, among many other advantages. You will have to deal with a much bigger project and bundle size up front every time you create a new project, but it has all of the functionalities you could need to get started with your next side project. It does not appear to be actively maintain for the latest version of React, but it is certainly the most feature-inclusive. It even has linting, prettier, and webpack fully included.

What I would pick for my next side project

If I were not in my last semester of school and wanted to learn a framework while working on a fun side project, I would likely select React for a full-stack verbose application that integrates many pages and makes a high number of API calls. It is clear that the React boilerplate has had the highest number of people working to support it (at least when it was actively supported) which can really make the difference when you want a quick plug-and-play experience. The fact that it already has "100% test coverage" and support for SEO and native web apps is a real game changer, as I know how tedious those elements can be to get running after dealing with numerous dependency versioning conflicts.
Despite this fact, I think it is also important to highlight the StencilJs boilerplate as a very intriguing option for projects focus on learning and/or leveraging fast web components. For one, I am the least familiar with Stencil out of the 4 frameworks we considered. The Stencil boilerplate stands as a compile-time tool with TS, JSX, and lazy-loading support which are all really nice to have. I am most curious about exploring the universal web component idea that Stencil is built around. It sounds like it is a framework's version of open-wc or vanilla JS web components, which likely means a Stencil-based app would be very fast and performant. In addition to this, the offering of Server Side Rendering means that active users of the application would have a very responsive development experience since the entire page is downloaded during the first site visit.

Our organization's boilerplate repo: boilerplates

The StencilJs "Getting Started" boilerplate I selected: StencilJs - Getting Started
(This is what I would select first if I were attempting to learn StencilJs for the first time)

Getting Started with Open-wc

Nick Alico — Sat, 28 Aug 2021 18:08:31 +0000

Getting Started with Open-wc

Open Web Components, or open-wc as we refer to it, is a web component platform centered around the idea that utilizing and building web components should be straightforward and accessible to all developers. A proponent of open-source development and tooling, the group see web components as the future of web development, citing it as a: "standards-based solution to problems like reusability, interoperability, and encapsulation" (open-wc.org). Today, I would like to get you up and running with the open-wc boilerplate that can be used as a starting point to create any of your own web components.

Here's what you will need to get started:

Administrative rights to the computer you will be using
Basic terminal knowledge and the ability to run basic terminal commands

Steps we will cover:

Downloading an IDE or Text Editor
Installing Node.js and NPM
Installing yarn (another package manager)
Downloading the open-wc boilerplate

https://code.visualstudio.com/brand

Downloading an IDE

For this tutorial, we will be using VSCode as our IDE as it is freely available and has all of the built in functionality we may need through this project.

Go to VSCode and download the latest stable build.

When you first open the application, it will ask for permission to access certain levels of your folder structure depending on where you attempt to open and save projects to on your local machine. Please agree to grant access to the directories you plan to use in this class (I recommend the Documents folder at the very least).

https://nodejs.org/en/

Installing Node and NPM

Next, we need to install Node.js in order for us to be able to download and manage the open-wc tooling.

Go to the Node.js website and download the latest LTS Build for your operating system.

After downloading, it will ask you to go through a brief installation and setup process. Please agree to all necessary permissions and use agreements that you are presented with, leaving any additional optional settings as their default value.

NPM (a.k.a the Node Package Manager) will also be installed when you download Node. To validate that both of these have been installed correctly, run:

node -v

and

npm -v

to check the version numbers of each.

If you get a version number as a response such as:

v14.17.0

you have installed Node correctly.

https://yarnpkg.com/

Installing yarn

Similar to how we downloaded Node and NPM, let's install the yarn package manager:

In order to install yarn, we will need to use the terminal.

Open up your terminal/console window/shell on your device.
Use the following command using NPM that we just installed:
npm install --global yarn
If you receive an error stating that you do not have appropriate permissions, or that the action could not be completed, this may be because you do not have the correct administrative permissions under the current user. To solve this issue, add "sudo" to the beginning of your command:
sudo npm install --global yarn

Installing the open-wc boilerplate

We made it! We're ready to set up open-wc. First, however, we need to select where we will be installing the boilerplate and all of its dependencies...

Choose a location on your local machine (I recommend creating a new folder in your "Documents" directory) where you want to install and access the boilerplate.

Now that we know where we want to install the boilerplate, open your terminal again and navigate to the appropriate level and folder:

Use ls to look at the files in the current directory level
Use cd <directory name> to drill into your preferred folder location.

We can finally download the boilerplate and its dependencies:

Run npm init @open-wc
- (Use 'sudo' at the beginning if you get a permissions error again)
Once the downloading has began, you will be prompted with a number of questions
- Select "Scaffold a new project" using your Return key to select it

Select "Web Component"
Using the spacebar, select all three additional tooling options (Linting, Testing, and Demoing)
Select "No" for using Typescript
Write "hello-world" as the tag name for your web component
- Please use lowercase letters only for this name!!
Select "Yes" that we want to write this file structure to the disk
Finally, select "Yes, with yarn" to install all of the necessary dependencies that Node requires to support open-wc

If the setup was successful, you should see the following confirmation:

Congratulations!!! You have officially set up your boilerplate for open-wc! Please leave a comment if you have any issues or questions on this installation.

Best of luck on your web component creations!

IST 402: Web Components Introduction

Nick Alico — Thu, 26 Aug 2021 20:09:26 +0000

Hello dear reader!

Background

My name is Nick Alico, and I am a graduating senior at Penn State studying Human-Centered Design & Development with a focus in HCI. (This is a fancy way of saying I enjoy the intersection of software and UX work.) I am also a Schreyer scholar, and am subsequently completing my Honors Thesis studying competency models and how they can be applied to design and development courses to make for a more individualized and accessible learning experience. In the past, I have completed SWE-focused internships with Oracle, GE Healthcare, and Rockwell Automation.

Outside of class, I am involved with IST Diplomats, Undergraduate Research Ambassadors, Viral Imaginations, UXPA PSU, and serve as an LA this semester.

Why Web Dev?

I've always been a visual learner. Web development is the perfect combination of programming and visual design for me: it allows for complete creativity while supporting the ability to build anything you can imagine. I am very interested in exploring the growth of design systems and aspire to work as a Design Systems/UX Engineer in my full-time gig eventually; web development is where that truly begins. I've had some great opportunities in the past to collaborate on everything from small side projects to Fortune 100 company codebases, but I still feel that I've only scraped the surface of what web development really entails. That's why I want to take this class: to learn about the cutting edge of web components and hopefully be able to casually implement them in my future job.

Other Fun Facts

I enjoy running and hiking in my free time
I have competed in the PennApps hackathon twice while in college
I can solve a Rubik's cube in under 30 sec. (I know I'm a nerd but it's not as hard as you think.)

Drop a follow and reach out if you are interested in connecting! I would love to have a conversation with you!