One of the more frustrating things in the development cycle is when you have your code all tested and working as intended locally, and even in staging. But then when we deploy it to production and it breaks. What the hell. It worked on my machine!
I recently had to add a new <code>prop</code> to a component we use to showcase different types of entries from our CraftCMS instance and display it in a carousel fashion. The prop being added was pretty simple, called <code>ungatedResources</code> and it was a boolean. If set to true, my component would grab any entries labeled <code>resources</code> and display them in the carousel as usual but in addition, adds a bypass to the url so that the user doesn't have to fill out a form to download the resource. Nothing too crazy.
It wasn't until I tested the component that I realized our bypass wasn't working as intended. Rather than take us to the thank you page with the resource ready to download, I got stuck with an ugly broken page with a "Loading..." indicator that never went away.

It Works on My Machine: Debugging Production bugs in NextJS

TypeScript is certainly here to stay and in modern development setups it's nearly impossible to avoid. In this post I'll be breaking down some basic concepts of TypeScript, specifically Types &#x26; Interfaces and how they can benefit your codebase.
<h2>Types</h2>
In TypeScript types are used to specify the kind of data a variable can hold. For example, you can define a variable to hold a <code>string</code>, <code>number</code>, <code>boolean</code>, <code>object</code>, etc. But how is this helpful? By defining types, we are able to catch errors at compile time, rather than at runtime. Meaning we can catch errors before they actually happen in the browser. If you're using VS Code like myself, you'll notice that anytime there is an error in your TypeScript file, it will be very clearly underlined in red. TypeScript is great at catching these errors and helping you fix them before they become a real problem.
Diving into the different types that TypeScript has to offer, we have:
<pre><code>//String
let myString: string = 'Hello world!';

//Number
let myNumber: number = 42;

//Boolean
let myBoolean: boolean = true;

//Array
let myArray: number[] = [1, 2, 3, 4, 5];

//Object
let myObject: { name: string, age: number } = {
	name: 'Mikel Arteta',
	age: 39
};

//Any
let myAny: any = 'Howdy, world!';

//Void
function myFunction(): void {
	console.log('');
}

//Null
let myNull: null = null;

//Undefined
let myUndefined: undefined = undefined;

//Never
function myError(message: string): never {
	throw new Error(message);
}
</code></pre>
Granted there are more types that TypeScript has to offer, and you can even go as far as creating your own custom types but for now, just know that these are some of the basic types that you'll come across in TypeScript.
<h2>Interfaces</h2>
Interfaces are a bit different from types in that they are used to define the structure of an object, rather than the type of data a variable can hold. In a typical JavaScript object, you can add any property to an object at any time. While convenient, this can be a bit dangerous as you may not always know what properties an object has. This is where interfaces come into play. They allow you to define the structure of an object, sort of like a blueprint. This way, you can be sure that an object has the properties you expect it to have, thus reducing the chances of unexpected behavior.
Let's take a look at what an interface looks like in your typical TypeScript file.
<pre><code>interface footballPlayer {
	name: string;
	age: number;
	position: string;
	team: string;
	retired: boolean;
}

let player: footballPlayer = {
	name: 'Martin Odegaard',
	age: 22,
	position: 'Midfielder',
	team: 'Arsenal'
	retired: false
};
</code></pre>
In the example above, we've defined an interface called <code>footballPlayer</code> that has five properties: <code>name</code>, <code>age</code>, <code>position</code>,<code>team</code>, and <code>retired</code>. We then create a variable called <code>player</code> that is of type <code>footballPlayer</code>. This means that the <code>player</code> object must have the properties defined in the <code>footballPlayer</code> interface. If we were to add a property that is not defined in the interface, let's say <code>goalsScored</code>, TypeScript would throw an error, letting us know that <code>goalsScored</code> is not a valid property for the <code>footballPlayer</code> interface.
While TypeScript may seem like it's doing the most to keep your JavaScript code rigid and strict, it's truly doing us a favor by not only catching errors before they happen but also making our code more predictable and easier to understand. The benefits of including TypeScript in any team based project are certainly up there.

TypeScript: Types & Interfaces

NextJS is our preferred framework for building React applications here at Abnormal. It's relatively ease of use and the ability to handle server-side rendering out of the box makes it a great choice for our projects. However, one thing that can be a bit tricky to handle in NextJS is client-side errors.
Server-side errors I generally find a bit easier to debug, as they're usually logged on the Vercel dashboard. Client-side errors, on the other hand, can be a bit more tricky to debug as those errors will not show up on the dashboard. Instead they show up as a broken page on your app, generally causing a bit of panic. But before we dive into debugging, I think it's best we first understand what the difference is between a client-side vs server-side error?
<h2>Client-side vs Server-side Errors</h2>
The names should give it away almost immediately but just to clarify: client-side errors happen on the client side, like a users browser or mobile phone. Server-side errors happen on the server, like your API or database. While both are errors, they are handled differently and thus we must approach debugging them differently.
<h2>Debugging Client-side Errors</h2>
Whenever I come across a client-side error in one of our NextJS apps, the first thing I do is open up the browser console to see if there is any information that is relevant or helpful in debugging the error. Don't let the haters fool you, the browser console is a fantastic tool for debugging client-side errors as it will usually give you a stack trace and the line number where the error occurred.
If I find that the browser console isn't necessarily helping me. My next go-to is to boot up my application locally and navigate to the page or component where the error occurred. Here, we can usually find detailed information about the error that is happening, down to the exact line of code that is causing the issue. Once the fix is applied, tested and confirmed, we push those changes up and deploy the app.
Another option is to use a service like Sentry to log client-side errors. Sentry is a solid tool for logging errors in your application and can be another way to track down client-side errors that are happening in your app. Though I personally find that the browser console and local debugging are usually enough to track down and fix client-side errors, some may find Sentry to be a better option, especially if you're working on a larger team.
That being said, client-side errors can be a bit tricky to debug in NextJS, but with the right tools and approach, they can be tracked down and fixed in no time. If you're working on a NextJS app and are struggling with client-side errors, I recommend using the tips above to help track down those errors. And when all else fails, we can always hit up the NextJS community for help.

Client Side Errors in NextJS

If you've worked with JavaScript for a bit, you've likely heard the term "memory management". But what exactly does this mean in a language that's supposed to handle all that stuff for you? In this post, we're peeling back the layers of JavaScript's memory management, to try and understand a bit about what's going on.
In JavaScript, when you create objects, functions, or any types of variables, you're taking up memory. Think of memory as a giant toy box where all your code's variables are toys. As with any toy box, there's a limit to how much it can hold. This is where JavaScript's memory management comes in, more specifically through a process called garbage collection (GC).
<h2>The Concepts Behind Garbage Collection</h2>
Garbage collection is a systematic process in JavaScript designed to identify and reclaim memory that is no longer in use by the program, preventing memory leaks and optimizing the application's performance. This mechanism operates automatically in the background, relieving the developer from manual memory management.
The primary principle guiding garbage collection is reachability. In the realm of JavaScript, certain entities, like global variables and currently executing functions, are always accessible and thus, kept in memory. They serve as the starting point or "roots" from which the garbage collector begins its operation.
<pre><code>let rootVariable = {
 name: "GlobalObject"
};
</code></pre>
Here, rootVariable is a global variable, hence it's inherently reachable and retained in memory.
One common algorithm employed for garbage collection in JavaScript is the Mark-and-Sweep algorithm. This algorithm operates in two main phases:
Marking: Initially, the garbage collector marks all objects that are accessible from the roots, directly or indirectly, as reachable. This marking process identifies the set of objects that are still in use.
<pre><code>let associatedObjects = {
 objectA: { type: 'Object A', parent: 'GlobalObject' },
 objectB: { type: 'Object B', parent: 'GlobalObject' }
};

rootVariable.associated = associatedObjects;
</code></pre>
Sweeping: Following the marking phase, the garbage collector enters the sweeping phase, where it goes through the memory and reclaims the space occupied by the unmarked objects, those that were not marked as reachable in the marking phase.
<pre><code>rootVariable.associated = null;
</code></pre>
Now, associatedObjects is no longer reachable, and will be collected in the next garbage collection cycle.
The garbage collection process operates continuously in the background, ensuring that memory is efficiently managed. By identifying and cleaning up the memory of objects that are no longer in use, the garbage collector plays a vital role in maintaining the performance and stability of JavaScript applications.
Understanding the principles of garbage collection and its operation is crucial for writing efficient code, troubleshooting memory-related issues, and developing scalable, performance-optimized applications.
<h3>A Practical Example</h3>
Say you're coding up a form on a website
<pre><code>function handleFormSubmit() {
 let formData = {
 name: document.getElementById('name').value,
 email: document.getElementById('email').value
 };

 sendFormData(formData);

 // After sendFormData, formData is no longer needed
}

function sendFormData(data) {
 // Code to send data to the server...
}
</code></pre>
After <code>handleFormSubmit</code> runs, <code>formData</code> is not needed anymore. And in our example since it's not reachable by any other parts of the code, our GC fairy will clean it up next time she's around.
Understanding JavaScript memory management is crucial for developers aiming to enhance application performance and avoid memory leaks, which can lead to sluggish behavior or crashes. In essence, a solid understanding of how memory is allocated, used, and reclaimed is foundational to writing robust JavaScript that adheres to best practices and delivers ultimately the best user experience.

JavaScript Memory Management: An intro

So I finally dove straight into Next.js, thanks to my new job and as of late last week... my new blog! For the uninitiated - Next is a framework that extends React to allow for server-side rendering. Server-side rendering is the process of rendering your React components on the server and sending the fully rendered HTML to the client, rather than traditional way of sending an empty HTML file that gets it's content filled in by JavaScript once it's downloaded.
In your standard client-side React app, all of the JavaScript and HTML from the app are downloaded to a users browser or the "client". The downloaded JavaScript is then responsible for rendering said app.
With Next, we can make use of server-side rendering to have the component rendered on the server before sending it to the client. This means that the user receives a fully-rendered component or page from the server, which can be faster to load and better for search engine optimization.
<h2>So what happens when a component needs to update on the client?</h2>
When the server sends a page to the client, this page includes an initial state of the app and the JavaScript needed to "hydrate" it on the client-side.
Hydration is the process of taking the initial state provided by the server and using it to re-render the React components on the client-side. This allows your web app to load quickly and still being interactive once loaded.
<h2>The Benefits of Server-Side Rendering</h2>
<h3>Faster Load times</h3>
With server side rendering (SSR) the user receives a fully rendered page from the server, meaning the user can start interacting with the page much sooner than if they had to wait for the JavaScript to download and render the page. This can be pretty important for users with low-powered devices, since it can reduce the amount of processing required by their devices.
<h3>Better SEO</h3>
With SSR, search engines can index your pages more easily. Since the search engine can see the fully rendered HTML, rather than just the empty HTML file that gets filled in by JavaScript, crawlers index your pages with ease.
<h3>Improved Accessibility</h3>
Not everybody has JavaScript enabled, and if they don't, they won't be able to interact with a traditional web app. SSR allows users to interact with the page even if JavaScript is disabled making it the far more accessible approach to modern development.
All-in-all server-side rendering is a great way to improve the performance and accessibility of your web app. By rendering your pages and components on the server, you can improve the user performance and make your app more accessible to a wider audience. If you're interested in learning more about Next.js, I highly recommend checking out the <a href="https://nextjs.org/docs/getting-started">Next.js documentation</a> and giving the framework a go. Thanks for reading ✌🏼

Exploring the Benefits of Server-Side Rendering with Next.js

If you're working with objects in JavaScript, you'll sometimes find yourself needing to transform an array into a new one with modified values.
In comes the .map() method - .map() is an immutable method that creates a new array with the results of calling a function on every element in the original array. Think of it like copying and pasting an existing array as a brand new one with a modified version of each element.
Let's take a look at an example to understand the .map() method in action. Consider the following array of numbers
<pre><code>const numbers = [1, 2, 3, 4, 5];
</code></pre>
Now, let's say we want to create a new array where each element is 2X the value of the corresponding element in the original array. Using the .map() method we can do it like so
<pre><code>const doubledNumbers = numbers.map(num => num * 2);
console.log(doubledNumbers);
// Output: [2, 4, 6, 8, 10]
</code></pre>
In this example, we use an arrow function as an argument on the .map() method. The function takes one argument (num), which represents the current element being processed, and returns a new value (num * 2). The .map() method then returns a new array with the new values.
To recap: the .map() method is a powerful tool in JavaScript for transforming arrays into new ones with modified values. It allows you to create a new array without modifying the original one, which is particularly useful when working with large datasets. Keep in mind that it always returns a new array with the same number of elements as the original, and that the original array remains unchanged.

The .map() Method

I was working on some intro animations the other day for my site and had an idea to have a user land on the homepage, and the word “hello” would slide in from the left greeting them.
The animation bit was reasonably straightforward, I used CSS animations to translate the text’s X value from -100% to zero. When testing the animation, I got what I wanted; the text now slid in from the left.
<pre><code>@keyframes slideInFromLeft {
	0% {
		transform: translateX(-100%);
	}

	100% {
		transform: translateX(0);
	}
}
</code></pre>
<img src="https://dev-to-uploads.s3.amazonaws.com/i/kvbo9s9le9tv6m3nf41t.gif" alt="Alt Text">
There was a problem though, every time I refreshed the page, the animation would replay, this got pretty annoying when navigating through the site and returning home. So I decided to use some JavaScript and the Window's session-storage property to solve my problem.
For those who may be unfamiliar with the session-storage property: think of it like local-storage. With local-storage, we can store data that won't expire. The difference with session-storage is that the data expires after the window or browser tab is closed.
I started with an if statement that read something like “If a property called animated within the session-storage property is equal to null, run the following code”
<pre><code>if (window.sessionStorage.getItem(‘animated’) === null) {} 
</code></pre>
Within that if statement code block, I targeted the text that would be animating, added the “animate” class to it, which contained the CSS animation rule, and then set the animated property within session-storage to 1.
<pre><code>if (window.sessionStorage.getItem(‘animated’) === null) { 
	document.getElementById(‘my-text’).classList.add(‘animate’);
	window.sessionStorage.setItem(‘animated’ ,1);
} 
</code></pre>
And now, the animation only fires once per session. A quick and easy way to ensure we don’t annoy our users with our fancy animations.

Running CSS Animations Once Per Session

I recently reworked my site to feature cards on the homepage that acts as a gallery for some of the recent drawings that I’ve done.
Initially, I had the cards pop a bit on hover by giving them a drop shadow. I played around with various other properties for a few hours before ending up with the following
<img src="https://dev-to-uploads.s3.amazonaws.com/i/ibo0jrauamuyh5tvzex8.gif" alt="Demonstrating the zoom-in and text-stretch effect that happens on mouse hover">
A few micro-interactions are happening in the GIF above.
<ul>
<li>Zoom effect on the image</li>
<li>Increased letter spacing in the title</li>
<li>Box-shadow transitions between a subtle/noticeable state</li>
</ul>
These are all done in conjunction with CSS transitions, to give it a smooth effect, both in and out.
To create that, I started with three divs. One is the actual card, the second is where we will house the background image, and the third is our title box.
<pre><code>&#x3C;div class="card">
 &#x3C;div class="card_background"> &#x3C;/div>
 &#x3C;div class="title">
 &#x3C;h2>Parallax Galaxy&#x3C;/h2>
 &#x3C;/div>
&#x3C;/div>
</code></pre>
The CSS was a bit more involved. I also had to mess around with the transitions a bit until I got it just right.
<pre><code>.card {
 position: relative;
 cursor: pointer;
 overflow: hidden;
 box-shadow: 0 1px 3px rgba(0, 0, 0, 0.12), 0 1px 2px rgba(0, 0, 0, 0.24);
 transition: all .3s cubic-bezier(0.25, 0.8, 0.25, 1);
}

.card:hover {
 box-shadow: 0 14px 28px rgba(0,0,0,0.25), 0 10px 10px rgba(0, 0, 0, 0.295);
}

.card_background {
 background-size: cover;
 background-position: center;
 background-repeat: no-repeat;
 width: 100%;
 height: 50vh;
 transition: all 2s cubic-bezier(0.25, 0.8, 0.25, 1);
}

.card:hover .card_background {
 transform: scale(1.1);
}

.card:hover .title {
 letter-spacing: 4px;
}

.title {
 position: absolute;
 left: 0;
 top: 2rem;
 padding: 0.5rem 1rem;
 background: rgba(255, 255, 255, 1);
 max-width: 400px;
 transition: all 3s cubic-bezier(0.25, 0.8, 0.25, 1);
 letter-spacing: 2px;
 text-transform: uppercase;
}

.title h2 {
 display: inline-block;
 width: auto;
 font-size: 1.3rem;
 font-weight: 700;
 margin: 0;
}

</code></pre>
The end-effect functioning on multiple images. A relatively quick and easy way to spice-up any gallery.
<img src="https://dev-to-uploads.s3.amazonaws.com/i/9oe5k60k38wgxhuh2e7o.gif" alt="Alt Text">

A little bit of CSS micro-interactions and some cards

Golden hour transforms the desert landscape into a canvas of light and shadow.