DEV Community: Colby Sanchez Wagenbach

Intro to Singly Linked Lists for the JavaScript Developer

Colby Sanchez Wagenbach — Sat, 25 Mar 2023 01:48:14 +0000

IF YOU ARE HERE FOR A PLAIN ENGLISH/JS EXPLANATION OF DATA STRUCTURES AND LINKED LISTS, PLEASE SCROLL PAST INTRODUCTION

Introduction

I'm beginning this series with the intended audience of JavaScript developers emerging fresh from a web development boot camp. Many boot camp graduates are unaware that they already possess the skills necessary to construct the very data structures they may be asked about in interviews. This series is meant to be a guide to translating your hands-on JavaScript skills into the abstract (and needlessly inaccessible!) world of algorithms.

Data Structures

A linked list represents a particular type of a data structure. Both "linked list" and "data structure" are terms coming from computer science. A data structure at it's most simple is a collection of values, the relationships between those values, and the means available to act upon those values. Data structures are built upon the simpler primitive types. An array represents the data structure most familiar to JavaScript developers.

Linked Lists

If arrays are collections of elements (individual data points) in a set order, where each element may be accessed individually by its index, how do linked lists differ? A linked list is a linear collection of nodes. Each node contains two elements, a value and a pointer. (Doubly linked lists have two pointers and will be discussed in a later post.) A node's value is the data point itself, and a node's pointer indicates the next node in the list. The first node in a linked list we call the head, and the final node in a list we call the tail. Here is an example of a linked list, myLinkedList, in the form of a JavaScript object.

const myLinkedList = {
    head: {
        value: 10,
        next: {
            value: 15,
            next: {
                value: 20, 
                next: {
                    value: 25,
                    next: {
                        value: 30,
                        next: null
                    }
                }
            }
        }
    }
}

The value associated with each node increments by 5, starting at 10 and ending at 30. The head key indicates the first node in the list. Each node is itself an object with two properties, value and next, next being the pointer. The value of the value property is the data point itself, while the next property's value is a nested object, the next node in the list! This is the "pointing" done by the pointer. The tail of the linked list points to null, indicating the end of the list.

Contrasts with Arrays

First, and most importantly, a given node in a linked list can not be accessed by some given index. To explain this further, consider myLinkedList with the same data points laid out in an array: [10, 15, 20, 25, 30]. If we wanted to access the data point with a value of 25, we might grab its index based on its distance from the start array[3], or knowing it's proximity to the end of the array, we might say array[array.length - 2]. It's almost as if the pointer is built into arrays. You don't need to tell the element after element[0] that it's element[1], it just is. Regardless, there is an index that allows us to grab the individual element. Let's return to myLinkedList. If we wanted to grab the 25 value, we could access it with myLinkedList.head.next.next.next.value. Not only is this cumbersome and impractical (.next.next.next.next . . .), but what if we don't know the contents of a list beforehand, or its length?

Unlike arrays, linked lists must be traversed. This method of navigating through a list will become more clear with demonstration in the next post, when we begin to design a generic singly linked list.

Why Linked Lists Now?

You likely made it through boot camp without once encountering a linked list. Web developers do not often need to be familiar with the nuances of computer science, although data structures certainly mark an element of CS one can expect to confront in engineering interviews.

To most immediately answer the question: Why haven't I done this yet throughout my web dev journey? The point is that this is abstract. That's why you haven't done it and might not have been taught it. What you'll come to see is that you were certainly taught all the tools in boot camp, the matter at hand is properly understanding the task you are assigned.

In the next post, we'll go over using class constructors to design and build our own custom Linked List class.

Day 2: Web Development

Colby Sanchez Wagenbach — Wed, 08 Mar 2023 01:10:02 +0000

Day 2 - Debugging (already)

Vision

I thought today I'd get to finish building the home page, but as soon as I sat down to execute npm run dev, the application crashed and I was served

[Error: UNKNOWN: unknown error, readlink 'C:\Users\colby\OneDrive\Desktop\chowder-kettle\chowder-kettle-web\.next\static\webpack\pages'] { errno: -4094, code: 'UNKNOWN', syscall: 'readlink', path: 'C:\\Users\\colby\\OneDrive\\Desktop\\chowder-kettle\\chowder-kettle-web\\.next\\static\\webpack\\pages' }

I'd encountered this same error weeks ago when finishing the Next.js tutorial included on their website. I chose to dig deeper on the matter this time around.

Debugging

After some fruitless googling, I followed the file path C:\\Users\\colby\\OneDrive\\Desktop\\chowder-kettle\\chowder-kettle-web\\.next\\static\\webpack\\pages and discovered a series of inscrutable files therein. I was able to extract some plain text from these files which returned results directing me towards configuring my debugger in VS Code. I created a file in the root of the project's directory .vscode/launch.json and added in the following code to the file:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Next.js: debug server-side",
            "type": "node-terminal",
            "request": "launch",
            "command": "npm run dev"
        },
        {
            "name": "Next.js: debug client-side",
            "type": "chrome",
            "request": "launch",
            "url": "http://localhost:3000"
        },
        {
            "name": "Next.js: debug full stack",
            "type": "node-terminal",
            "request": "launch",
            "command": "npm run dev",
            "serverReadyAction": {
                "pattern": "started server on .+, url: (https?://.+)",
                "uriFormat": "%s",
                "action": "debugWithChrome"
            }
        }
    ]
}

Following directions found on Stack Overflow, I ran the dubugging console and was ultimately returned the message "autoprefixer: start value has mixed support, consider using flex-start instead". I went into the Home.modules.css file I'd created for the NavBar yesterday and updated display: flex; justify-content: start; align-items: start to display: flex; justify-content: flex-start; align-items: flex-start. This circumvented the matter and got the development environment properly running.

Home Page

Debugging took me about two hours to work through, and after I began building a Profile component, I quickly realized that I would need to pull data from Firebase if I wanted to authentically model this component in development (As I write this, I realize that I could also hard-code in values to placehold for data; potential route to pursue tomorrow). This line of thought pulled me towards configuring user authentication, and that matter led into my currently non-existent login page. Tomorrow I plan to begin with building the login page and ensuring user authentication is properly configured.

Takeaways

One thing I realized towards the end of my work day was that I'd left yesterday's terminal session still running. Scrolling through it, I began to discover that when I was still working yesterday, I'd received a series of warnings that explained the issue the compiler was having with start vs. flex-start. While in live development, the compiler was able to reconcile the issue, when I was trying to reload the development environment, the compiler would not move past the issue it was encountering. Essentially, if I had paid more attention to the warnings I was receiving, I would have saved the time I spent deciphering a far more complex error message.

Additionally, I realize I need to approach developing the application more programmatically. Whereas yesterday I came in with the set goal of designing the navbar component, today I set myself the broader task of designing the remainder of the homepage. I ignored my concern about the need to pull data, and as soon as I encountered that issue, I was stunted in my ability to immediately move forward. When planning my days, I must ensure I am staying granular so that development continues to move forward, so that days and hours are not lost to incessant reorientation.

Web Development: Day 1

Colby Sanchez Wagenbach — Tue, 07 Mar 2023 02:00:52 +0000

Day 1 - NavBar Component

Today I undertook to develop a custom navigation bar from scratch for the first time since learning how to utilize the Bootstrap API. With a wireframe I drew over the weekend to guide me, a trial-by-fire refresher on flexboxes, and responsive CSS units, I wound up with a still in development Navigation bar that conformed with my skeletal mock-up.

Challenges

Historically, I've had difficulty tracking the display property when planning a front-end. I credit React's functional components with forcing me to think much more atomically about the DOM, and thus children elements and their inheritance.

globals.css

I knew that I wanted the NavBar to display on every single page across the application, so I scoped it's styling globally. To start, I set properties for the entire document:

html,
body {
  padding: 0;
  margin: 0;
  max-width: 100vw;
  overflow-x: hidden;
  overflow-y: hidden;
  width: 100vw;
  height: 100vh;
  display: flex;
  flex-direction: row;
  justify-content: center;
  align-items: center;
}

Next.JS adds in a root <div> with an id of __next. In order to frame the content of the application proportionally inside of the page, I added styling to this root element.

#__next {
  height: 83.3vh;
  width: 83.3vw;
  display: flex;
  flex-direction: row;
  align-items: center;
}

The NavBar itself consisted of five buttons evenly spaced out in a column. I wanted the buttons to all stretch to fill the same space regardless of their text input. Here's what I came up with:

.navbar {
  height: 83.3vh;
  width: 27.7vw;
  display: flex;
  flex-direction: column;
  justify-content: space-evenly;
}

.navitem {
  width: 100%;
  height: 20%;
  display: flex;
  justify-content: center;
  align-items: center;
}

.navbar button {
  width: 16.6vw;
  height: 8.3vh;
}

Takeaways

Responsive Units

CSS has built-in units which make proportional, responsive sizing easy to do. vh and vw stand for 'viewport height' and 'viewport width,' respectively, and 1 unit of each represents 1% of the viewport's corresponding dimension. I used a straight-edge and pencil when developing the wireframe for the webpage, and I had anticipated a maze of

.nav { height: ??%; width: ??% }

in getting the page to render as desired. Instead, using some middle-school mathematics, I was able to quickly determine the desired sizes in relative terms that translated directly into vws and vhs. Not only does the sizing quickly translate, but it is already responsive.

Display

I left today thinking that the element that is receiving the display: flex property is being told "You will digest your immediate children in this matter." Cronus imagery aside, the flexbox reaches down only one level. This insight seriously assisted in reasoning out where and how each element would land.

Status Update

I ended the day with an extremely raw form of the navbar, but I am satisfied with it's geometry, so to speak. Tomorrow I'll take to building out the remainder of the homepage.