Forem: Diego (Relatable Code)

How to set up Bun on a Windows Computer

Diego (Relatable Code) — Tue, 25 Oct 2022 11:32:00 +0000

Introduction

Every day it feels like the JavaScript ecosystem undergoes changes. The introduction of Bun is just further proof of that and boy is it powerful.

But, what is Bun?

Bun is a fast all-in-one JavaScript runtime

Source: https://bun.sh/

What makes it “all-in-one” though? Well, let’s just head one line down for their personal description of what makes it stand out amongst the competition.

Bundle, transpile, install and run JavaScript & TypeScript projects — all in Bun. Bun is a new JavaScript runtime with a native bundler, transpiler, task runner and npm client built-in.

That is a ton of functionality baked (heh) into one runtime. One of the things that caught my eye was that it also automatically transpiles files. That means you can just use Typescript and JSX with no setup needed.

That sort of functionality truly does feel like it should be the norm. These tools are tried-and-tested and them just working feels right.

However, I tend to use my Windows computer a lot because I tend to game on the side. For convenience’s sake, I also do a lot of coding on my Windows computer (where applicable). So I decided to give Bun a shot whilst on my Windows computer.

Let’s dive right in on how to set it up.

Setting up WSL

In order for us to install certain functionalities we need to set up a Linux distribution on our Windows machine. Thankfully, the developers at Microsoft have created something called the Windows Subsystem for Linux (WSL)

The Windows Subsystem for Linux lets developers run a GNU/Linux environment — including most command-line tools, utilities, and applications — directly on Windows, unmodified, without the overhead of a traditional virtual machine or dualboot setup.

If you want more info check out the full docs.

This is exactly what we’re looking for to set up Bun.

Open up the Windows Powershell (with admin privileges) and run the following command:

wsl --install

You’ll probably get a line of messages similar to this:

Awesome! Let’s restart our machine.

After restarting the terminal will automatically attempt to run some commands. However, you may get the following error:

Installing, this may take a few minutes... 
WslRegisterDistribution failed with error 0x80370102 
Error: 0x80370102 The virtual machine could not be started because a required feature is not installed

In this case, virtualization may not be enabled on your PC. How to enable this can vary from processor to processor so I just did a quick google search. In my case, I had an AMD Ryzen, so I had to reboot and enable SVM in my BIOS settings.

After enabling open up another terminal and run the following command to re-install the Linux distribution. If it previously worked you can skip this step.

wsl --install -b Ubuntu

This will install and ask you to create a UNIX user account.

Installing Docker Desktop

It’s recommended to use Docker Desktop with WSL. Let’s go ahead and get that set up.

https://www.docker.com/products/docker-desktop/

Download the executable and install Docker Desktop.

This will require a logout. Afterward, head into settings and make sure Use the WSL 2-based engine is enabled.

In Resources, under WSL Integration make sure your installed distro is enabled as well.

For more detailed instructions and troubleshooting check out the WSL docs.

Using Bun on Windows

That was quite a bit of prep just to use Bun. Grab a coffee and come back so we can continue!

Installing Bun

Open up the Ubuntu (just search up Ubuntu from the Start menu and it should appear if it was installed correctly) instance and install unzip.

sudo apt install unzip

And install bun

curl https://bun.sh/install | bash

One more step. We have to add a few lines manually to our .bashrc

Now you have full access to the bun commands! Restart the Ubuntu terminal and run

bun --version

This should confirm if it was correctly installed or not.

Testing out Bun

I’ll be using Vscode to simplify the process but it’s not necessary. Vscode has an extension available to integrate it with WSL easily.

Here are their docs for more info:

https://code.visualstudio.com/docs/remote/wsl

Under extensions just look up WSL to install the respective extension

Awesome!

To test this out create a folder with the name http.js and add the following lines to the file (note this is straight from the docs):

export default {
  port: 3000,
  fetch(request) {
    return new Response("Welcome to Bun!");
  },
};

Open the folder with vscode. In the bottom left of the vscode screen you should see a button with two arrows

Click it and select the option to re-open the folder with WSL. Your terminal should now be connected to the Ubuntu instance. From here run:

bun run http.js

At localhost:3000 you’ll now see the executed file!

Wrapping it up

That was quite the setup but now we can do more complex things with Bun. In the next article, I’ll go over how to set up a more complex project.

Do note that Bun is still in Beta so you may encounter some issues! They have an active discord so I recommend checking them out if you run into any problems.

Let’s Connect

If you liked this feel free to connect with me on LinkedIn or Twitter

Check out my free developer roadmap and weekly tech industry news in my newsletter.

Testing a React Application Working with Codecov

Diego (Relatable Code) — Tue, 18 Oct 2022 11:04:52 +0000

In the previous article, we began our setup for Codecov by instrumenting our codebase. In this final article, we’ll finish our setup with a GitHub workflow that will automatically submit our coverage results.

Just to give a small recap this is what code coverage is and what our application does:

Code coverage is a software testing metric that determines the number of lines of code that is successfully validated under a test procedure, which in turn, helps in analyzing how comprehensively a software is verified. Source

Cool! Next, let’s go over what our application does. When clicking on a button it fetches posts from a service and displays them on the page:

You find the full repository github.com/diballesteros/react-testing

What is a GitHub workflow

Let’s check out the official docs from GitHub for a clear definition:

A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule

That’s a lot to take in. Essentially we can create a folder at the root directory of our project that Github will automatically detect to implement the “workflow”. Magic!

These actions can be monitored in the Actions tab in a repository.

Awesome! But how does this help us? Well, we’re going to create our very own YAML file to create a workflow that will trigger on every push to our repository. This way our code coverage will always stay up to date.

To find out more about workflows and GitHub actions check out the official docs.

Creating our workflow

In the root directory of our project create a .github folder and inside of that create a workflows folder with a single main.yml file inside.

YAML files have a fairly simple structure that is very dependent on the spacing of each line to know what the next step is. Highly recommend checking out their docs if you’re not too familiar with them.

Let’s start off by giving our workflow a name and making it trigger on push.

Afterward, we can start setting up our steps. Let’s think about what this implies. GitHub is spinning up an environment to run our tests. This means that in this environment we must have all the necessary dependencies for Cypress to run correctly.

This may seem complicated at first, but it’ll soon make sense.

We can start adding jobs to our workflow file to do just this:

jobs:
    tests:
        runs-on: ubuntu-latest
        container: cypress/browsers:node14.17.0-chrome88-ff89
        steps:
            - name: 🛫 Checkout
              uses: actions/checkout@v3

            - name: 🌲 Cypress install
              uses: cypress-io/github-action@v4
              with:
                  runTests: false
            - run: npm run build

runs-on specifies the environment we'll use to install our dependencies. To make it simple we'll just use the latest version of Ubuntu that is available.

container is the browser.

The Checkout step gets our code from the repo. Then we install Cypress.

To add to this we’ll use some actions directly from Cypress to run our tests and upload them to Codecov.

jobs:
    tests:
        runs-on: ubuntu-latest
        container: cypress/browsers:node14.17.0-chrome88-ff89
        steps:
            - name: 🛫 Checkout
              uses: actions/checkout@v3

            - name: 🌲 Cypress install
              uses: cypress-io/github-action@v4
              with:
                  runTests: false
            - run: npm run build

            - name: 💻 'UI Tests'
              uses: cypress-io/github-action@v4
              with:
                  start: npm run dev
                  wait-on: http://localhost:3000
                  wait-on-timeout: 120
                  browser: chrome
                  spec: 'cypress/integration/first-test.spec.js'

            - name: ✅ Upload coverage to Codecov
              uses: codecov/codecov-action@v3.1.0

UI Tests will look for the GitHub action directly from Cypress to run our test in a chrome browser. Something very important to note is that in the spec property we specified only the test we created: first-test.spec.js.

You can use an * to capture all files. For example: cypress/integration/*.

Our final step will upload it to Codecov using a GitHub action they have provided for us.

The GitHub Action

After committing and pushing up the new changes we’ll finally be able to test it out. If you head to the repository and go to the GitHub Actions tab you’ll see the action automatically running:

If you click on the action you’ll be able to see a detailed view of what tasks are being run and the steps.

In the screenshot above I made a mistake with the run command for the project.

Wrapping it up

We’ll now be able to see the results in Codecov in our project list:

We’ll also see how much coverage we actually have:

We can also see what lines are not being covered:

Check out the official Codecov docs for more info on how to navigate the dashboard:

https://docs.codecov.com/docs

That wraps up my series. I hope you enjoyed it! Testing is a fundamental part of the software development process and is something that should not be skimmed over.

Thankfully modern-day testing has a plethora of tools that make our job easier. If you have any more questions regarding testing leave them in the comments section below!

Let’s Connect

If you liked this feel free to connect with me on LinkedIn or Twitter

Check out my free developer roadmap and weekly tech industry news in my newsletter.

Testing a React Application Instrumenting the codebase

Diego (Relatable Code) — Mon, 10 Oct 2022 14:05:08 +0000

Introduction

In the previous article, we went over how to update Cypress to its amazing version 10! Now we’ll finish off this series by adding code coverage to our application and incorporating it into our CI. But what is code coverage?

Code coverage is a software testing metric that determines the number of lines of code that is successfully validated under a test procedure, which in turn, helps in analyzing how comprehensively a software is verified. Source

In most cases, this is a percentage of how much the codebase is being covered by tests. How do we know if a test covers a certain amount of code? Instrumentation of our code monitors and traces the test coverage and gives us accurate reports.

Cool! First, let’s go over what our application does. When clicking on a button it fetches posts from a service and displays them on the page:

For reference, you can find the repository here.

Installing codecov

We will be using Codecov

Ship healthier code faster with less risk.

That’s their motto! But how do we go about using it? In the link above make sure to make an account and connect your repository.

In the Not yet setup tab we should find our repository.

This will give us some brief instructions on how to set up code coverage with our repository. First, let’s install a necessary Cypress package:

npm install @cypress/code-coverage --save-dev

Then in our cypress/support/e2e.js file let's go ahead and import this new code.

In our cypress.config.js we also have to set up the events to correctly execute the code coverage:

const { defineConfig } = require('cypress');

module.exports = defineConfig({
    e2e: {
        baseUrl: 'http://localhost:3000',
        specPattern: 'cypress/integration/**/*.spec.js',
        setupNodeEvents(on, config) {
            require('@cypress/code-coverage/task')(on, config);
            return config;
        },
    },
});

Let’s open up our application and cypress to run our test:

npm run dev 

npm run test-e2e

When we run our test we will see the following command:

What we’re missing is the instrumentation for our code. There are a few ways to go about this. But first, let’s add the two new folders to our .gitignore:

# Code coverage files 
coverage 
.nyc_output

To instrument our code we have to install the following plugin:

npm install vite-plugin-istanbul --save-dev

In our vite.config.js we should import the newly installed library and set it up:

Some interesting notes on how the Istanbul plugin works can be found here.

Finally, when we run the rest we’ll no longer see the same warning as before:

To get a better understanding of what’s going on let’s take a look at the root directory you’ll see a folder, coverage:

You’ll see some JSON files that detail exactly what is covered in the files of the directory we provided earlier in the vite.config.js (./src).

Wrapping it up

Instrumenting our code base is crucial to providing Codecov with the necessary information it needs to give us the percentage of code coverage we actually have.

In the next article, I’ll go over how to set up the GitHub Action to automatically send the code coverage report to CodeCov with every push. This way you don’t have to think about it at all!

You can find the full code here at this repo.

Let’s Connect

If you liked this feel free to connect with me on LinkedIn or Twitter

Check out my free developer roadmap and weekly tech industry news in my newsletter.

How to migrate Zustand from Version 3 to 4

Diego (Relatable Code) — Tue, 04 Oct 2022 00:19:02 +0000

Introduction

Zustand is an awesome state management library for React that excels in its simplicity. It's just one hook that can then be called from anywhere in the app to access your store.

This simplicity has made it the perfect choice for personal small-medium sized apps because it requires little boilerplate and it comes baked in with some awesome middleware!

As an aside middleware is:

such as:

Persisting to local storage
Immer to make state changes easier to handle
Store version and migration handling

I used this library to handle persisted data in a personal app of mine. Essentially it's a CRUD app to manage Pokemon you run into in a playthrough of a game.

The important part however is that I have an obsession with keeping my libraries up-to-date (specifically in these small personal apps) so I decided to go ahead and migrate Zustand from version 3 to 4.

As a small disclaimer, this article assumes you have some base-level experience with Zustand.

Migration Process

First and foremost you can check out the changelog and any specific changes you may need to do on the Zustand GitHub repo changelog.

First, let’s go ahead and update the library:

yarn add zustand

In my case, it updated to 4.1.1.

All the previous APIs are backward compatible so keep in mind that the changes I’m going to make apply to Typescript.

Immer is a library that allows you to work with immutable state data in a more convenient way. Before we had to explicitly set the type like this and the function to use it:

const immer =
  <T extends State>(config: StateCreator<T>): StateCreator<T> =>
  (set, get, api) =>
    config(
      (partial, replace) => {
        const nextState =
          typeof partial === 'function' ? produce(partial as (state: T) => T) : (partial as T);
        return set(nextState, replace);
      },
      get,
      api
    );

However, we can now just import it directly from Zustand’s middleware, so we can delete the above code.

import { immer } from 'zustand/middleware/immer';

Next, the section where you’re creating the store requires a small change:

const useStore = create<AppState>(

const useStore = create<AppState>()(

It is now treated as a curried function.

Last but not least, I used the migrate option in the PersisOptions that Zustand provides to persist all data to local storage. However, the state of this app is now considered unknown by Typescript.

We can fix this by explicitly declaring the type with an assert function. For the sake of brevity I did something like this:

migrate: (persistedState, version) => { assertAppState(persistedState);

The assert function looks something like this:

function assertAppState(val: unknown): asserts val is AppState {
  if (typeof val !== 'object') {
    throw new TypeError('Invalid app state');
  }
}

This means anytime I call my state object afterward in the migrate function then it will have the correct typing rather than unknown.

Wrapping it up

Zustand is an awesome library that is simple to use. I recommend using it in any project you may be working on. If you have any other questions or stories about your migration process leave them in the comments below!

Let’s connect

If you liked this feel free to connect with me on LinkedIn or Twitter

Check out my free developer roadmap and weekly tech industry news in my newsletter.

Dealing with Burnout as a Programmer

Diego (Relatable Code) — Mon, 26 Sep 2022 23:52:13 +0000

Burnout is a mix of exhaustion, indifference, and annoyance to something you previously loved. This is a feeling that can be quite common in the world of programming. Where you once had joyful curiosity when opening up Visual Studio Code you now feel anxiety or boredom.

A more textbook definition:

Burn-out is a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed.

World Health Organization

This can happen for a variety of different reasons but can have long-lasting impacts on how you feel towards your craft and job. I strongly feel that it is something that everyone should be careful with. Take note that this article is not a definitive how-to guide but more of my experience with a burnout in the hopes that others can relate.

How it started

I’ve been a developer for several years now. And throughout my entire career, I’ve greatly enjoyed programming and studying outside of work hours. I would do (and throw away) a ton of side projects.

The majority of the time was a ton of fun! I felt like I was picking up new skills and building neat projects even if they were of no monetary value. This continued for several years without an issue.

But, on top of it being fun, I also felt the drive to continue this behavior. I wanted to stay on top of my craft. I felt like it was a necessity.

However, a few months back I had several real-life issues that were affecting my personal mood, and the free time I had available. Since I had always worked on side projects I didn’t see a need to stop but continued doing them despite all the built-up stress.

This continued for almost a year.

The creeping feeling

In the beginning, this wasn’t an issue. I would continue to work. But, something felt off. I would open up my text editor and work but my joy in doing so would decrease every time.

Where my attention before was completely undivided in my project, it was now easily diverted into YouTube, video games, or other things. I would feel justified in procrastinating things I had planned out beforehand.

Pushing it out further and further into the future. “I’ll finish it eventually”

Even after dealing with my other issues in life, I began to feel stress and anxiety when working on projects or articles outside of work.

At its peak, I just couldn’t find the desire to work on much of anything.

The creeping feeling

I just had to stop. Plain and simple. I could no longer bring myself to code as I felt It was quickly becoming a downward cycle. I would feel anxiety when working on side projects, but feel guilty if I didn’t continue them.

I took a few months off where I did limited coding outside of work. Slowly over time, I began feeling the desire to code on projects and begin studying. But I did not want to waste this feeling. I began to see this feeling of curiosity and passion to learn as a resource.

I want to avoid this creeping feeling from now on. I now try to time and intentionally plan the time I dedicate to learning and programming outside of work. I feel like this balanced approach is way healthier.

This may seem obvious to some, but it required introspection on my part. I realized that even if I love what I do I have to be careful not to overdo it.

Passion is awesome and should be treated with care.

If anyone has experienced burnout let me know in the comments below how you dealt with it.

Let’s connect

If you liked this feel free to connect with me on LinkedIn or Twitter

Check out my free developer roadmap and weekly tech industry news in my newsletter.

Testing a React application updating to Cypress 10

Diego (Relatable Code) — Mon, 13 Jun 2022 14:13:00 +0000

Introduction

In the last article of this series, we went over how to create a test with Cypress, an end-to-end testing framework. Check it out here. Cypress is a featureful framework that has only improved with its new version, and its main view got a makeover to give it a more modern look.

Let’s briefly go over the small barebones application we’ve made up to this point.

When clicking on a button it fetches posts from a service and displays them on the page:

For reference, you can find the repository here.

Updating Cypress

First, let’s go ahead and update our Cypress package. If this is your first time using Cypress, it’ll also install it.

yarn add cypress --dev

or if you’re using npm first uninstall it then re-install it. I've had issues with updating the package so I prefer reinstalling it fresh. If someone in the comments has a better way please let me know!

npm uninstall cypress 
npm install cypress --save-dev

This should update Cypress to its newest version 10. As of this article, this is version 10.1.0. If you are having compatibility issues while reading this article I suggest checking out the official Cypress changelog.

Easy enough. Now let’s head into the breaking changes.

Cypress Configuration file

Let’s try running Cypress.

npm run dev 
npm run test-e2e

If you still have cypress open you’ll notice a similar error:

Cypress now uses a different configuration file. Let’s delete our cypress.json and create a new cypress.config.js

This new file has a defineConfig function that will contain all of our old options. Which in this case was just the baseUrl option.

const { defineConfig } = require('cypress');

module.exports = defineConfig({
    e2e: {
        baseUrl: 'http://localhost:3000',
        specPattern: 'cypress/integration/**/*.spec.ts',
    },
});

Now we’ll get the new modern screen:

Resolving errors

We’ll get met with our first error when we click on the end-to-end testing option:

This is simple, head into your Cypress directory and rename cypress/support/index.js to cypress/support/e2e.js

Now we can choose a browser to launch our tests. Let’s start testing in Chrome. When we click on it we’ll see the option to create our first spec. But wait, where did all of our old test files go?

if we click on View spec pattern we’ll see how it’s looking for tests.

Looks like Cypress now defaults to the **.cy.{js,jsx,ts,tsx} extensions. Let's just update the spec pattern for the sake of our example project. In our Cypress configuration file let's add a new specPattern property.

const { defineConfig } = require('cypress');

module.exports = defineConfig({
    e2e: {
        baseUrl: 'http://localhost:3000',
        specPattern: 'cypress/integration/**/*.spec.js',
    },
});

Now we’ll see all of our tests again!

We can now run our tests as normal.

Some clean-up

We can also delete our plugins folder inside our cypress folder as it is no longer needed.

Wrapping it up

Due to Cypress’ new version, I decided it was best to first update our version. Next time we’ll cover what I had to delay, hooking up our testing frameworks with a code coverage functionality.

Let’s connect

If you liked this feel free to connect with me on LinkedIn or Twitter

Check out my free developer roadmap and weekly tech industry news in my newsletter.

Testing a React Application Creating a Cypress Test

Diego (Relatable Code) — Mon, 06 Jun 2022 14:06:23 +0000

Introduction

The seventh part of my ongoing series is on how to test a modern React application. This time I’ll go over how to create our first Cypress test.

Cypress is a robust end-to-end testing framework.

In the previous parts of this series, I went over how to set up our unit-testing framework with Vitest. Unit tests will cover more isolated and individual pieces like our functions or component-only tests if necessary.

We also went over how to initially set up Cypress and its dependencies. Cypress will be handling a big chunk of our tests and give us the most confidence in our tests.

Let’s briefly go over the small barebones application we’ve made up to this point.

When clicking on a button it fetches posts from a service and displays them on the page:

For reference, you can find the repository here.

Cypress examples

Let’s go ahead and run the commands needed to get Cypress up and running:

npm run dev 
npm run test-e2e

When first launching the application you’ll see when it completes through the terminal:

A window will be opened with some tests that we can review with a breadth of examples.

I highly recommend checking out these tests to get a real example of how to use a lot of the syntax with Cypress. They cover quite a bit of use cases. These tests can be found in the following location in our folder structure:

Creating our first test

Let’s go ahead and start creating our first test. In the integrations folder let's create a file first-test.spec.js.

The Cypress syntax is very similar to our vitest syntax. We'll start off by adding an encapsulating describe function.

describe('First Test', () => {});

Inside the second parameter of the function, we’ll add our individual test. Again, similar to vitest we'll add an it function with our first test logic.

describe('First Test', () => {
     it('Fetch posts', () => {});
});

Let’s pause and take a look again at the Cypress window. At the bottom of the list, we’ll find the newly added test.

If we click on the test we’ll get a message that no tests are found. Let’s go ahead and start using the Cypress syntax to navigate to the page.

describe('First Test', () => {
  it('Fetch posts', () => {
    cy.visit('http://localhost:3000/')
  });
});

Just to break down what’s going on, cy is a globally available object with a bunch of our Cypress syntax. cy.visit() allows us to visit the specified URL. In the Cypress window, we'll get our page that is up from our dev environment.

In the center right next to the URL we’ll see a cross-hair icon. If you click on this icon you’ll be able to select other elements on the page. What is this for?

You can select elements to query for in our Cypress tests. Awesome 😎. This is one of the reasons Cypress is so fun to use. It really makes creating tests a breeze. We could just use the existing selector for the fetch button but let’s add a different one to our JSX.

<button data-testid="fetch-posts" onClick={fetchPosts} type="button">
    Fetch Posts
</button>

The attribute data-testid will allow us to query for the button with higher specificity. If we go ahead and use the crosshair icon in our Cypress window we can see the new selector.

Clicking the copy button on the right we can grab the selector and use it in our test.

describe('First Test', () => {
    it('Fetch posts', () => {
        cy.visit('http://localhost:3000/');
        cy.get('[data-testid="fetch-posts"]').click();
    });
});

In our testing window, we’ll see the posts correctly fetched. As the final part of our first test let’s go ahead and assert that the posts were fetched correctly. But our fetch of the posts is asynchronous. No worries here as Cypress has us covered.

describe('First Test', () => {
    it('Fetch posts', () => {
        cy.visit('[http://localhost:3000/'](http://localhost:3000/'));
        cy.get('[data-testid="fetch-posts"]').click();
        cy.intercept('[https://jsonplaceholder.typicode.com/posts').as(](https://jsonplaceholder.typicode.com/posts').as()
            'getPosts'
        );
        cy.wait('[@getPosts](http://twitter.com/getPosts)');
    });
});

Our cy object has an intercept property that allows us to check network requests for a specific endpoint. We alias this request by chaining an as function with the name of the alias. At the very end, we'll wait for the request with the cy.wait('@getPosts') command.

The only thing left to do is check that the posts are correctly loaded. Let’s add another data-testid to the list of our posts.

<section data-testid="posts">
    {posts.map((post) => (
        <article key={post.id}>
            <h3>{post.title}</h3>
            <p>{post.body}</p>
        </article>
    ))}
</section>

With that out of the way, we can query for the number of posts.

describe('First Test', () => {
    it('Fetch posts', () => {
        cy.visit('http://localhost:3000/');
        cy.intercept('https://jsonplaceholder.typicode.com/posts').as(
            'getPosts'
        );
        cy.get('[data-testid="fetch-posts"]').click();
        cy.wait('@getPosts');
        cy.get('[data-testid="posts"]')
            .children()
            .should('have.length.greaterThan', 10);
    });
});

And we’re done, in the Cypress window, you can see the test passing.

Wrapping it up

I hope you enjoyed making our first Cypress test. This framework will give you a ton of coverage of the entire application. Speaking of coverage, in the next article I’ll go over how to hook up vitest and Cypress to a code coverage system.

Let’s connect

If you liked this feel free to connect with me on LinkedIn or Twitter

Check out my free developer roadmap and weekly tech industry news in my newsletter.

JavaScript LeetCode Valid Anagram

Diego (Relatable Code) — Mon, 30 May 2022 21:33:57 +0000

Prompt

An Anagram is a word or phrase formed by rearranging the letters of a different word or phrase, typically using all the original letters exactly once.

Example 1:

Input: s = "anagram", t = "nagaram" 
Output: true

Analyzing the problem

Let’s this of what the problem is asking. We have to know the contents of the strings we’re analyzing. We also have to make sure that we’re keeping track of the letters as they should be exactly the same to confirm that it is an anagram.

Following that train of thought, we can early return if there is ever a difference in the letters they contain. But what does it mean to have the same letters? Well, essentially it’s mapping out the frequency of each letter for the first word we iterate over. When we iterate over the second word we can double-check with what.

Checking back on the first example provided we can visualize this by counting each letter:

Looking at the counts we can use this to validate in place as we iterate over the second word. Let’s see how this would look:

So the first time we run into the n in the second iteration we subtract it from the count. Anytime we go below 0 then we know the words are not valid anagrams.

Cool 😎, let’s get to coding.

The solution

Similar to our last problem we can use a hash table.

var isAnagram = function(s, t) {
    if (s.length != t.length) return false;
    const hashTable = {};

    for(let i = 0; i < s.length; i++) {
        if (!hashTable[s[i]]) {
          hashTable[s[i]] = 0;
        }
        hashTable[s[i]]++;
    }

    for(let j = 0; j< t.length; j++) {
        if (!hashTable[t[j]]){
          return false;  
        } 
        hashTable[s[j]]--; 
    }

    return true;
};

In the first iteration, we add the frequency of every letter. If it doesn’t exist we create a 0 value at that point.

if (!hashTable[s[i]]) {
    hashTable[s[i]] = 0;
}
hashTable[s[i]]++;

On the second iteration, we subtract all values. If no letter ever exists then we’ll hit the number 0 which means we'll return a false.

if (!hashTable[t[j]]){
   return false;  
} 
hashTable[s[j]]--;

Let’s connect

If you liked this feel free to connect with me on LinkedIn or Twitter

Check out my free developer roadmap and weekly tech industry news in my newsletter.

Testing a React Application Setting up Cypress

Diego (Relatable Code) — Mon, 23 May 2022 14:36:56 +0000

Introduction

The sixth part of my ongoing series is on how to test a modern React application. This time I’ll go over how to initially configure Cypress, our End-to-End testing framework.

In the previous parts of this series, I went over how to set up our unit-testing framework with Vitest. Unit tests will cover more isolated and individual pieces of code like our functions or component-only tests if necessary.

On the other hand, Cypress and its test will handle the other big chunk where we can really gain confidence that our tests will behave similarly to how a user would use the application. Just to catch up let’s go over what our simple barebones app does.

When clicking on a button it fetches posts from a service and displays them on the page:

What is Cypress?

The first phrase you’ll see when navigating to their page is the following:

Fast, easy and reliable testing for anything that runs in a browser.

The keyword for this quote is browser. Cypress’ test runner replicates the browser environment. That means whatever test we create will behave exactly as if running in the browser. This gives us a ton of confidence!

On top of that, with Cypress we can test with several different browser environments: Google Chrome and Firefox being among them. Cypress comes with its own syntax at times but if you’re familiar with Vitest or Jest then it should come naturally. The docs are actively maintained and well structured.

Take a look at them

Photo by Sincerely Media on Unsplash

Enough talking, let’s start setting up Cypress.

Configuration Files for Cypress

First, we have to install the necessary dependencies:

npm install cypress --save-dev

yarn add cypress --dev

Much like other libraries, this will have a configuration file at the root of our project: cypress.json. Let's go ahead and create it. Within this file, you can set a variety of different flags. Check out this article in the docs to better understand all the options.

When first launching any Cypress test we have to manually visit the pages we want to test. So instead of writing out the entire URL every single time we’ll go ahead and include the baseUrl in this config.

{
  "baseUrl": "http://localhost:3000"
}

With that, the only other configuration we need to set up is the scripts in our package.json.

"scripts": {
    // ...other scripts,
    "e2e": "cypress open",
  },

Check out the full repository up to this point here.

Next time we’ll create our first test with Cypress as well as make sure our integration with MSW holds up.

Let’s connect

If you liked this feel free to connect with me on LinkedIn or Twitter

Check out my free developer roadmap and weekly tech industry news in my newsletter.

JavaScript LeetCode Best Time to Buy and Sell Stock

Diego (Relatable Code) — Mon, 16 May 2022 13:15:11 +0000

Prompt

You are given an array prices where prices[i] is the price of a given stock on the ith day.

You want to maximize your profit by choosing a single day to buy one stock and choosing a different day in the future to sell that stock.

Return the maximum profit you can achieve from this transaction. If you cannot achieve any profit, return 0.

Example 1:



Input: prices = [7,1,5,3,6,4] 
Output: 5 Explanation: Buy on day 2 (price = 1) and sell on day 5 (price = 6), profit = 6-1 = 5. Note that buying on day 2 and selling on day 1 is not allowed because you must buy before you sell.

Analyzing the problem

As with the previous problems the first apparent solution is to go for the brute force solution. Here we would iterate over the array twice checking every subtraction between every subsequent value and just grab the highest profit.

A visual example of this could look like this:

First solution

Let’s go ahead and write out the code for what we mentioned above.



function maxProfit(prices) {
  let profit = 0;
  for (let i = 0; i < prices.length - 1; i++) {
    for (let j = i + 1; j < prices.length; j++) {
      const currentProfit = prices[j] - prices[i]

if (currentProfit > profit ) {
        profit = currentProfit
      }
    }
  }

return profit;
}

Here we compare the price of the next element in the array with the current. The best way to conceptualize this is that i is our index and j is our pointer that keeps iterating.

We use two for loops to find the maximum profit. This will have a complexity of O(n^2). This is a pretty big problem as it is very slow! However, we can optimize this by iterating over the array only once.

Second Solution

But what would a single iteration look like?

With code it would look something like this:



var maxProfit = function(prices) {
    let profit = 0;

let stockToBuy = prices[0];

for(let i = 1; i < prices.length; i++) {
        if (stockToBuy > prices[i]) {
            stockToBuy = prices[i]
        }

const currentProfit = prices[i] - stockToBuy;

if (currentProfit > profit) {
            profit = currentProfit;
        }
    }

return profit;
};

We grab the initial stockToBuy from the first element in the array. Then we can begin iterating over the array (skipping the first). We compare if the next stock is of a higher price than our currently selected stock. If so it'll yield us a higher profit so we switch it out.

However, this also serves as a reset mechanism. If the stock is of a higher value we know that from this point forward it will not be higher profit than if it was with the previously selected stock.



stockToBuy = prices[i]

After that, we calculate our new currentProfit, this is just a temporary value in our current iteration.



const currentProfit = prices[i] - stockToBuy;

Then we compare it with the value we saved outside of our for loop. If it's higher then that's exactly what we want.

Notice we created the variable with 0 at first so that if we don't find any profit we can just return it as is.

Greedy Algorithm

But what is this called?

What we’re doing here is selecting the best option on every iteration and forgetting about past selections This is called a greedy algorithm.

Here’s a Wikipedia article if you want to read up more on it (you should).

Let’s connect

If you liked this feel free to connect with me on LinkedIn or Twitter

Check out my free developer roadmap and weekly tech industry news in my newsletter.

JavaScript LeetCode Contains Duplicate

Diego (Relatable Code) — Thu, 12 May 2022 16:32:49 +0000

Introduction

Continuing through the problems of LeetCode. I am not haphazardly selecting any questions. I am following along with this list for those that were curious:

techinterviewhandbook.org/best-practice-que..

Prompt

Given an integer array nums , return true if any value appears at least twice in the array, and return false if every element is distinct.

Example 1:

Input: nums = [1,2,3,1] 
Output: true

At first glance, the problem seems to be pretty simple. The idea here is to iterate over the array and find any duplicates. There’s a bit of a cheat code we can use with JavaScript in this one.

First Solution (cheating)

There is a standard built-in object for JavaScript called Set

But what does this object do?

Set objects are collections of values. You can iterate through the elements of a set in insertion order. A value in the Set may only occur once; it is unique in the Set's collection.

Knowing this, the only thing we need to do is convert our array into a Set and compare its length with the original number array length.

var containsDuplicate = function(nums) {
    const set = new Set([...nums]);
    return set.size != nums.length;
};

Converting an array into a Set is simple, just spread it into a new array in the Set constructor. It has a property to calculate the size (number of items). We just have to compare that with the length of the original array, nums.

return set.size != nums.length;

Second Solution

Much like our (first solution) we can create a hash table of our array as we’re iterating and evaluate it in place.

var containsDuplicate = function(nums) {
   const hashTable = new Map();

    for(let i = 0; i < nums.length; i++) {
        if(hashTable.has(nums[i])) return true;
        else hashTable.set(nums[i], true);

    }
    return false;
};

To break this down a little bit: we first iterate over the array of numbers. If the map already has the value then we return true. We check this with the .has property of map s

if(hashtable.has(nums[i]) return true;

Otherwise, we add it to the map and move on.

else hashTable.set(nums[i], true);

The value is pretty irrelevant as we don’t really care much for it. There probably is a data structure more suited here.

Let’s connect

JavaScript LeetCode Two Sum

Diego (Relatable Code) — Mon, 09 May 2022 13:17:32 +0000

Introduction

LeetCode. An unfortunate truth of developer life is that for some job interviews it is necessary to learn Data structure and algorithms (DSA) in a specific way. A way in which you’re expected to code up a solution to a DSA problem where you would otherwise google it.

I say unfortunate because in most cases it is unnecessary to know them to the degree required for the technical interviews and hardly reflects actual job capability.

But I digress, LeetCode is a website that compiles tons of different DSA problems. I’ll be going through several LeetCode problems over the next month, explaining and solving them, to help others out. And also it helps me to re-write the solution. 😎

Prompt

Given an array of integers nums and an integer target, return indices of the two numbers such that they add up to target_._

You may assume that each input would have exactly one solution , and you may not use the same element twice.

You can return the answer in any order.

Example 1:

Input: nums = [2,7,11,15], target = 9 
Output: [0,1] 
Explanation: Because nums[0] + nums[1] == 9, we return [0, 1].

Thinking it through

This is the first LeetCode problem and is quite an easy one. What first comes to mind is just iterating over the array twice and finding the necessary sum. This will 100% give us the solution.

However, as many of you may know about these types of questions. Usually, it is not enough to be correct. For DSA problems you want to be as efficient as possible.

Photo by Aron Visuals on Unsplash

So for example our first solution would be something along these lines:

Where i is the value of our first iteration and j is the value of our second iteration. Once added up we get 9 which is the solution we need.

First solution

I mainly use JavaScript so the solution would look something like this:

const twoSum(nums, target) { 
     for(let i = 0; i < nums.length; i++) { 
         for (let j = 0; j < nums.length; j++) { 
             if(j === i) continue; 
             if((nums[i] + nums[j]) === target) return [i, j]; 
         } 
      } 
}

nums is the array of numbers and target is the desired solution. I iterate over both arrays and check if the sum is the necessary value. However, as stated in the prompt, we should not use the same element twice.

So we can check if the iterations are on the same element and skip:

if(j === i) continue;

However, as I mentioned before this is very unoptimized.

Second Solution

A much better solution would be searching for the target based on the current number. What does that mean?

For example, when you first start iterating over the array you know the exact number you’re looking for. The number you’re looking for is the result of the subtraction of the target and the current iterated value.

Let’s take our first array as an example.

When we’re on the first element 2 we know that we need to find as 9 minus 2 is 7. But, we need a way to quickly re-access data of the array.

Introducing a Hash Table.

Hash Table

A hash table is a data structure that maps keys to values. This is perfect for our use case because we just want to map our number to our index.

But how do we create this hash table?

Map is a Javascript built-in object. The only thing you need to know is that it holds key-value pairs and has an API to quickly check the content:

.set for setting the key and value pair

.get for getting the value based on the key

.has for checking if it has the key

Second Solution

const hashTable = new Map(); 

for(let i = 0; i < nums.length; i++) { 
    const num = nums[i]; 
    const substractionWeWant = target - num; 

    if (hashTable.has(substractionGoal) { 
       return [i, hashTable.get(substractionGoal)]; 
    } else {
       hashTable.set(num, i); 
    } 
}

We now have a simplified way to check for previous values. Going back to the code we first do a single iteration of the loop. By subtracting the target value from the current index value num we can check if the remainder already exists. If it doesn't we just add the value we just tried to the map and move on.

So to reiterate

We loop over the array
We check if our current map of values has the subtraction of our target and current value we are iterating over. If it does we return both the index of the current value and the index of the value in our map
If we don’t find a match we add it to our map and move on

First solution:

Second solution:

Wrapping it up

If you want to keep up with this series feel free to follow me on here or any of my social media below!

Let’s connect

If you liked this feel free to connect with me on LinkedIn or Twitter

Check out my free developer roadmap and weekly tech industry news in my newsletter.