Forem: This Dot

Exploring Angular Forms: A New Alternative with Signals

This Dot Media — Wed, 06 Nov 2024 12:50:43 +0000

Exploring Angular Forms: A New Alternative with Signals

In the world of Angular, forms are essential for user interaction, whether you're crafting a simple login page or a more complex user profile interface. Angular traditionally offers two primary approaches: template-driven forms and reactive forms. In my previous series on Angular Reactive Forms, I explored how to harness reactive forms' power to manage complex logic, create dynamic forms, and build custom form controls.

A new tool for managing reactivity - signals - has been introduced in version 16 of Angular and has been the focus of Angular maintainers ever since, becoming stable with version 17. Signals allow you to handle state changes declaratively, offering an exciting alternative that combines the simplicity of template-driven forms with the robust reactivity of reactive forms. This article will examine how signals can add reactivity to both simple and complex forms in Angular.

Recap: Angular Forms Approaches

Before diving into the topic of enhancing template-driven forms with signals, let’s quickly recap Angular's traditional forms approaches:

Template-Driven Forms: Defined directly in the HTML template using directives like ngModel, these forms are easy to set up and are ideal for simple forms. However, they may not provide the fine-grained control required for more complex scenarios.

Here's a minimal example of a template-driven form:
```
<form (ngSubmit)="onSubmit()">
  <label for="name">Name:</label>
  <input id="name" [(ngModel)]="name" name="name">
  <button type="submit">Submit</button>
</form>
```

```typescript
import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html'
})
export class AppComponent {
  name = '';

  onSubmit() {
    console.log(this.name);
  }
}
```

Reactive Forms: Managed programmatically in the component class using Angular's FormGroup, FormControl, and FormArray classes; reactive forms offer granular control over form state and validation. This approach is well-suited for complex forms, as my previous articles on Angular Reactive Forms discussed.

And here's a minimal example of a reactive form:

import { Component } from '@angular/core';
import { FormGroup, FormControl } from '@angular/forms';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html'
})
export class AppComponent {
  form = new FormGroup({
    name: new FormControl('')
  });

  onSubmit() {
    console.log(this.form.value);
  }
}

```html
<form [formGroup]="form" (ngSubmit)="onSubmit()">
  <label for="name">Name:</label>
  <input id="name" formControlName="name">
  <button type="submit">Submit</button>
</form>
```

Introducing Signals as a New Way to Handle Form Reactivity

With the release of Angular 16, signals have emerged as a new way to manage reactivity. Signals provide a declarative approach to state management, making your code more predictable and easier to understand. When applied to forms, signals can enhance the simplicity of template-driven forms while offering the reactivity and control typically associated with reactive forms.

Let’s explore how signals can be used in both simple and complex form scenarios.

Example 1: A Simple Template-Driven Form with Signals

Consider a basic login form. Typically, this would be implemented using template-driven forms like this:

<!-- login.component.html -->
<form name="form" (ngSubmit)="onSubmit()">
  <label for="email">E-mail</label>
  <input type="email" id="email" [(ngModel)]="email" required email />
  <label for="password">Password</label>
  <input type="password" id="password" [(ngModel)]="password" required />
  <button type="submit">Login!</button>
</form>

// login.component.ts
import { Component } from "@angular/core";

@Component({
  selector: "app-login",
  templateUrl: "./login.component.html",
})
export class LoginComponent {
  public email: string = "";
  public password: string = "";

  onSubmit() {
    console.log("Form submitted", { email: this.email, password: this.password });
  }
}

This approach works well for simple forms, but by introducing signals, we can keep the simplicity while adding reactive capabilities:

// login.component.ts
import { Component, computed, signal } from "@angular/core";
import { FormsModule } from "@angular/forms";

@Component({
  selector: "app-login",
  standalone: true,
  templateUrl: "./login.component.html",
  imports: [FormsModule],
})
export class LoginComponent {
  // Define signals for form fields
  public email = signal("");
  public password = signal(""); // Define a computed signal for the form value

  public formValue = computed(() => {
    return {
      email: this.email(),
      password: this.password(),
    };
  });

  public isFormValid = computed(() => {
    return this.email().length > 0 && this.password().length > 0;
  });

  onSubmit() {
    console.log("Form submitted", this.formValue());
  }
}

<!-- login.component.html -->
<form name="form" (ngSubmit)="onSubmit()">
  <label for="email">E-mail</label>
  <input type="email" id="email" name="email" [(ngModel)]="email" required email />
  <label for="password">Password</label>
  <input type="password" name="password" id="password" [(ngModel)]="password" required />
  <button type="submit">Login!</button>
</form>

In this example, the form fields are defined as signals, allowing for reactive updates whenever the form state changes. The formValue signal provides a computed value that reflects the current state of the form. This approach offers a more declarative way to manage form state and reactivity, combining the simplicity of template-driven forms with the power of signals.

You may be tempted to define the form directly as an object inside a signal. While such an approach may seem more concise, typing into the individual fields does not dispatch reactivity updates, which is usually a deal breaker. Here’s an example StackBlitz with a component suffering from such an issue:

Therefore, if you'd like to react to changes in the form fields, it's better to define each field as a separate signal. By defining each form field as a separate signal, you ensure that changes to individual fields trigger reactivity updates correctly.

Example 2: A Complex Form with Signals

You may see little benefit in using signals for simple forms like the login form above, but they truly shine when handling more complex forms. Let's explore a more intricate scenario - a user profile form that includes fields like firstName, lastName, email, phoneNumbers, and address. The phoneNumbers field is dynamic, allowing users to add or remove phone numbers as needed.

Here's how this form might be defined using signals:

// user-profile.component.ts
import { JsonPipe } from "@angular/common";
import { Component, computed, signal } from "@angular/core";
import { FormsModule, Validators } from "@angular/forms";

@Component({
  standalone: true,
  selector: "app-user-profile",
  templateUrl: "./user-profile.component.html",
  styleUrls: ["./user-profile.component.scss"],
  imports: [FormsModule, JsonPipe],
})
export class UserProfileComponent {
  public firstName = signal("");
  public lastName = signal("");
  public email = signal(""); 
  // We need to use a signal for the phone numbers, so we get reactivity when typing in the input fields
  public phoneNumbers = signal([signal("")]);
  public street = signal("");
  public city = signal("");
  public state = signal("");
  public zip = signal("");

  public formValue = computed(() => {
    return {
      firstName: this.firstName(),
      lastName: this.lastName(),
      email: this.email(), // We need to do a little mapping here, so we get the actual value for the phone numbers
      phoneNumbers: this.phoneNumbers().map((phoneNumber) => phoneNumber()),
      address: {
        street: this.street(),
        city: this.city(),
        state: this.state(),
        zip: this.zip(),
      },
    };
  });

  public formValid = computed(() => {
    const { firstName, lastName, email, phoneNumbers, address } = this.formValue(); // Regex taken from the Angular email validator

    const EMAIL_REGEXP = /^(?=.{1,254}$)(?=.{1,64}@)[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;
    const isEmailFormatValid = EMAIL_REGEXP.test(email);

    return (
      firstName.length > 0 &&
      lastName.length > 0 &&
      email.length > 0 &&
      isEmailFormatValid &&
      phoneNumbers.length > 0 && // Check if all phone numbers are valid
      phoneNumbers.every((phoneNumber) => phoneNumber.length > 0) &&
      address.street.length > 0 &&
      address.city.length > 0 &&
      address.state.length > 0 &&
      address.zip.length > 0
    );
  });

  addPhoneNumber() {
    this.phoneNumbers.update((phoneNumbers) => {
      phoneNumbers.push(signal(""));
      return [...phoneNumbers];
    });
  }

  removePhoneNumber(index: number) {
    this.phoneNumbers.update((phoneNumbers) => {
      phoneNumbers.splice(index, 1);
      return [...phoneNumbers];
    });
  }
}

Notice that the phoneNumbers field is defined as a signal of an array of signals. This structure allows us to track changes to individual phone numbers and update the form state reactively. The addPhoneNumber and removePhoneNumber methods update the phoneNumbers signal array, triggering reactivity updates in the form.

<!-- user-profile.component.html -->
<form class="form">
  <label for="firstName">First Name</label> <input type="text" id="firstName" name="firstName" [(ngModel)]="firstName" required />

  <label for="lastName">Last Name</label> <input type="text" id="lastName" name="lastName" [(ngModel)]="lastName" required />

  <label for="email">Email</label> <input type="email" id="email" name="emailAddress" [(ngModel)]="email" required email />

  <div id="phoneNumbers">
    <label>Phone Numbers</label> @for (phone of phoneNumbers(); track i; let i = $index) {
    <div><input type="tel" name="phoneNumbers-{{ i }}" [(ngModel)]="phone" required /> <button type="button" (click)="removePhoneNumber(i)">Remove</button></div>
    } <button type="button" (click)="addPhoneNumber()">Add Phone Number</button>
  </div>

  <label for="street">Street</label> <input type="text" id="street" name="street" [(ngModel)]="street" required />

  <label for="city">City</label> <input type="text" id="city" name="city" [(ngModel)]="city" required />

  <label for="state">State</label> <input type="text" id="state" name="state" [(ngModel)]="state" required />

  <label for="zip">ZIP Code</label> <input type="text" id="zip" name="zip" [(ngModel)]="zip" required />

  @if(!formValid()) {
  <div class="message message--error">Form is invalid!</div>
  } @else {
  <div class="message message--success">Form is valid!</div>
  }
  <pre>
    {{ formValue() | json }}
  </pre>
</form>

In the template, we use the phoneNumbers signal array to dynamically render the phone number input fields. The addPhoneNumber and removePhoneNumber methods allow users to reactively add or remove phone numbers, updating the form state. Notice the usage of the track function, which is necessary to ensure that the ngFor directive tracks changes to the phoneNumbers array correctly.

Here's a StackBlitz demo of the complex form example for you to play around with:

Validating Forms with Signals

Validation is critical to any form, ensuring that user input meets the required criteria before submission. With signals, validation can be handled in a reactive and declarative manner. In the complex form example above, we've implemented a computed signal called formValid, which checks whether all fields meet specific validation criteria.

The validation logic can easily be customized to accommodate different rules, such as checking for valid email formats or ensuring that all required fields are filled out. Using signals for validation allows you to create more maintainable and testable code, as the validation rules are clearly defined and react automatically to changes in form fields. It can even be abstracted into a separate utility to make it reusable across different forms.

In the complex form example, the formValid signal ensures that all required fields are filled and validates the email and phone numbers format.

This approach to validation is a bit simple and needs to be better connected to the actual form fields. While it will work for many use cases, in some cases, you might want to wait until explicit "signal forms" support is added to Angular. Tim Deschryver started implementing some abstractions around signal forms, including validation and wrote an article about it. Let's see if something like this will be added to Angular in the future.

Why Use Signals in Angular Forms?

The adoption of signals in Angular provides a powerful new way to manage form state and reactivity. Signals offer a flexible, declarative approach that can simplify complex form handling by combining the strengths of template-driven forms and reactive forms. Here are some key benefits of using signals in Angular forms:

Declarative State Management: Signals allow you to define form fields and computed values declaratively, making your code more predictable and easier to understand.
Reactivity: Signals provide reactive updates to form fields, ensuring that changes to the form state trigger reactivity updates automatically.
Granular Control: Signals allow you to define form fields at a granular level, enabling fine-grained control over form state and validation.
Dynamic Forms: Signals can be used to create dynamic forms with fields that can be added or removed dynamically, providing a flexible way to handle complex form scenarios.
Simplicity: Signals can offer a simpler, more concise way to manage form states than traditional reactive forms, making building and maintaining complex forms easier.

Conclusion

In my previous articles, we explored the powerful features of Angular reactive forms, from dynamic form construction to custom form controls. With the introduction of signals, Angular developers have a new tool that merges the simplicity of template-driven forms with the reactivity of reactive forms.

While many use cases warrant Reactive Forms, signals provide a fresh, powerful alternative for managing form state in Angular applications requiring a more straightforward, declarative approach. As Angular continues to evolve, experimenting with these new features will help you build more maintainable, performant applications.

Happy coding!

"How do I undo my most recent commit?" - Mastering the git reset command

This Dot Media — Wed, 06 Nov 2024 12:50:08 +0000

"How do I undo my most recent commit?" - Mastering the git reset command

Git is a powerful version control system, but even experienced developers sometimes make mistakes. Whether you've committed changes to the wrong branch, made a typo in your commit message, or simply want to undo recent changes, the git reset command is your go-to solution. In this post, we'll explore how to use git reset to manage your commit history effectively.

The Basics of git reset

At its core, git reset moves the HEAD and current branch pointer to a specified commit, effectively "resetting" your working directory to a previous state. The basic syntax is:

git reset [<mode>] [<commit>]

Where <mode> specifies how to handle changes in the working directory and staging area, and <commit> is the commit you want to reset to.

Soft vs. Hard Reset: Understanding the Difference

Git reset has two main modes: --soft and --hard. Let's explore each:

Soft Reset (--soft)

A soft reset moves your HEAD to the specified commit but keeps your changes staged. This is useful when you want to undo commits but keep the changes for recommitting.

Example:

git reset --soft HEAD~1

This command undoes the last commit, keeping the changes staged. You can now make additional changes or recommit with a new message.

Hard Reset (--hard)

A hard reset is more drastic. It moves your HEAD to the specified commit and discards all changes after that commit.

Example:

git reset --hard HEAD~1

This command undoes the last commit and discards all changes. Be cautious with this command, as it can lead to data loss!

Specifying a Commit Hash

Instead of using relative references like HEAD~1, you can specify an exact commit hash:

git reset --soft 1a2b3c4

This resets to the commit with hash 1a2b3c4, keeping changes staged.

Using HEAD~n Notation

The HEAD~n notation allows you to specify how many commits back you want to reset. For example:

git reset --hard HEAD~3

This resets to three commits before the current HEAD, discarding all changes.

Reverting Pushed Changes

If you've already pushed commits you want to undo, you should use git revert instead of git reset to avoid rewriting public history. However, if you must use git reset on a shared branch, you'll need to force push:

git reset --hard HEAD~2
git push --force origin branch-name

Be extremely cautious with force pushing, as it can cause issues for other developers.

Generic Usage of git reset

git reset can also be used to unstage changes:

git reset HEAD file.txt

This removes file.txt from the staging area without changing its contents.

Conclusion

The git reset command is a powerful tool for managing your Git history. Whether you're undoing recent commits, unstaging changes, or completely resetting your working directory, understanding the different modes of git reset can help you navigate tricky situations in your Git workflow.

Remember to use git reset with caution, especially when working with shared repositories. When in doubt, create a backup branch before performing any reset operations.

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

This Dot Media — Wed, 06 Nov 2024 12:49:15 +0000

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Dialogs are a common component added to applications, whether on the web or in native applications. Traditionally there has not been a standard way of implementing these on the web, resulting in many ad-hoc implementations that don’t act consistently across different web applications. Often, commonly expected features are missing from dialogs due to the complexity of implementing them.

However, web browsers now offer a standard dialog element.

Why use the dialog element?

The native dialog element streamlines the implementation of dialogs, modals, and other kinds of non-modal dialogs. It does this by implementing many of the features needed by dialogs for you that are already baked into the browser.

This is helpful as it reduces the burden on the developer when making their applications accessible by ensuring that user expectations concerning interaction are met, and it can also potentially simplify the implementation of dialogs in general.

Basic usage

Adding a dialog using the new <dialog> tag can be achieved with just a few lines of code.

<dialog id="example-dialog">
  <button autofocus>Close</button>
  <p>This is a modal with some text!</p>
</dialog>

However, adding the dialog alone won’t do anything to the page. It will show up only once you call the .showModal() method against it.

document.getElementById('example-dialog').showModal();

Then if you want to close it you can call the .close() method on the dialog, or press the escape key to close it, just like most other modals work. Also, note how a backdrop appears that darkens the rest of the page and prevents you from interacting with it. Neat!

Accessibility and focus management

Correctly handling focus is important when making your web applications accessible to all users. Typically you have to move the current focus to the active dialog when showing them, but with the dialog element that’s done for you.

By default, the focus will be set on the first focusable element in the dialog. You can optionally change which element receives focus first by setting the autofocus attribute on the element you want the focus to start on, as seen in the previous example where that attribute was added to the close <button> element.

Using the .showModal() method to open the dialog also implicitly adds the dialog ARIA role to the dialog element. This helps screen readers understand that a modal has appeared and the screen so it can act accordingly.

Adding forms to dialogs

Forms can also be added to dialogs, and there’s even a special method value for them. If you add a <form> element with the method set to dialog then the form will have some different behaviors that differ from the standard get and post form methods.

First off, no external HTTP request will be made with this new method. What will happen instead is that when the form gets submitted, the returnValue property on the form element will be set to the value of the submit button in the form.

So given this example form:

<form id="example-form" method="dialog">
  <input name="value1" type="text" placeholder="text-value1" required />
  <input name="value2" type="text" placeholder="text-value2" />
  <input type="submit" value="Submit" />
</form>

The form element with the example-form id will have its returnValue set to Submit.

In addition to that, the dialog will close immediately after the submit event is done being handled, though not before automatic form validation is done. If this fails then the invalid event will be emitted.

You may have already noticed one caveat to all of this. You might not want the form to close automatically when the submit handler is done running. If you perform an asynchronous request with an API or server you may want to wait for a response and show any errors that occur before dismissing the dialog.

In this case, you can call event.preventDefault() in the submit event listener like so:

exampleForm.addEventListener('submit', (event) => {
  event.preventDefault();
});

Once your desired response comes back from the server, you can close it manually by using the .close() method on the dialog.

Enhancing the backdrop

The backdrop behind the dialog is a mostly translucent gray background by default. However, that backdrop is fully customizable using the ::backdrop pseudo-element. With it, you can set a background-color to any value you want, including gradients, images, etc.

You may also want to make clicking the backdrop dismiss the modal, as this is a commonly implemented feature of them. By default, the <dialog> element doesn’t do this for us. There are a couple of changes that we can make to the dialog to get this working.

First, an event listener is needed so that we know when the user clicks away from the dialog.

dialog.addEventListener('click', (event) => {
  if (event.target === dialog) {
    dialog.close();
  }
});

Alone this event listener looks strange. It appears to dismiss the dialog whenever the dialog is clicked, not the backdrop. That’s the opposite of what we want to do. Unfortunately, you cannot listen for a click event on the backdrop as it is considered to be part of the dialog itself. Adding this event listener by itself will effectively make clicking anywhere on the page dismiss the dialog.
To correct for this we need to wrap the contents of the dialog content with another element that will effectively mask the dialog and receive the click instead. A simple

element can do!

<dialog id="example-dialog" class="dialog">
  <div class="dialog-container">
    <p>This is a modal with some text!</p>

    <form id="example-form" method="dialog">
      <input name="value1" type="text" placeholder="text-value1" required />
      <input name="value2" type="text" placeholder="text-value2" />
      <input type="submit" value="Submit" />
    </form>
  </div>
</dialog>

Even this isn’t perfect though as the contents of the div may have elements with margins in them that will push the div down, resulting in clicks close to the edges of the dialog to dismiss it. This can be resolved by adding a couple of styles the the wrapping div that will make the margin stay contained within the wrapper element. The dialog element itself also has some default padding that will exacerbate this issue.

.dialog {
  padding: 0;
}

.dialog-container {
  display: inline-block;
  padding: 1em;
}

The wrapping div can be made into an inline-block element to contain the margin, and by moving the padding from the parent dialog to the wrapper, clicks made in the padded portions of the dialog will now interact with the wrapper element instead ensuring it won’t be dismissed.

Conclusion

Using the dialog element offers significant advantages for creating dialogs and modals by simplifying implementation with reasonable default behavior, enhancing accessibility for users that need assistive technologies such as screen readers by using automatic ARIA role assignment, tailored support for form elements, and flexible styling options.

How to retry failed steps in GitHub Action Workflows

Allan N Jeremy — Wed, 07 Dec 2022 09:41:54 +0000

Sometimes things can go wrong in your GitHub Action workflow step(s) and you may want to retry the step(s). This article will cover 2 ways to approach the retrying of steps.

Pre-requisites

Git (should be installed in your path)
GitHub account - we'll need this to use GitHub actions

Initial setup

In order to follow along, here are the steps you can take to setup your GitHub actions workflow.

Initialize your git repository

In your terminal, run git init to create an empty git repository or skip this step if you already have an existing git repository.

Create workflow file

GitHub workflow files are usually .yaml/.yml files that contain a series of jobs and steps to be executed by GitHub actions. These files often reside in .github/workflows. If the directories do not exist, go ahead and create them. Create a file retry.yml in .github/workflows. For now, the file can contain the following:

name: "Retry action using retry step"
on:
    # This action is called when this is pushed to github
    push:
    # This action can be manually triggered
    workflow_call:
jobs:
    # This name is up to you
    retry-job:
        runs-on: "ubuntu-latest"
        name: My Job
        steps:
            - name: Checkout repository
              uses: actions/checkout@v3

            - name: Print
              run: |
                echo 'Hello'

Testing your workflow

You can test your GitHub Action workflow by pushing your changes to GitHub and going to the actions tab of the repository or you can choose to test locally using act.

Retrying failed steps

Approach 1: Using the retry-step action

By using the using the retry-step action, we can retry any failed shell commands. If our step or series of steps are shell commands then we can use the retry-step action to retry them.

If however you'd like to try retry a step that is using another action, then the retry-step action will NOT work for you. In that case, you may want to try the alternative steps mentioned below.

Modify your action file to contain the following:

name: "Retry action using retry step"
on:
    # This action is called when this is pushed to github
    push:
    # This action can be manually triggered
    workflow_call:
jobs:
    # This name is up to you
    retry-job:
        runs-on: "ubuntu-latest"
        name: My Job
        steps:
            - name: Checkout repository
              uses: actions/checkout@v3


            - name: Use the reusable workflow
              # Use the retry action
              uses: nick-fields/retry@v2
              with:
                max_attempts: 3
                retry_on: error
                timeout_seconds: 5
                # You can specify the shell commands you want to retry here
                command: |
                    echo 'some command that would potentially fail'

Approach 2: Duplicate steps

If you are trying to retry steps that use other actions, the retry-step action may not get the job done. In such a case, you can still retry steps by retrying steps conditionally depending on whether or not a step failed.

GitHub provides us with two main additional attributes in our steps:

continue-on-error - Setting this to true means that the even if the current step fails, the job will continue on to the next one (by default failure stops a job's running).
steps.{id}.outcome - where {id} is an id you add to the steps you want to retry. This can be used to tell whether a step failed or not, potential values include 'failure' and 'success'.
if - allows us to conditionally run a step

name: "Retry action using retry step"
on:
    # This action is called when this is pushed to GitHub
    push:
    # This action can be manually triggered
    workflow_call:
jobs:
    # This name is up to you
    retry-job:
        runs-on: "ubuntu-latest"
        name: My Job
        steps:
            - name: Checkout repository
              uses: actions/checkout@v3

            - name: Some action that can fail
              # You need to specify an id to be able to tell what the status of this action was
              id: myStepId1
              # This needs to be true to proceed to the next step of failure
              continue-on-error: true
              uses: actions/someaction

            # Duplicate of the step that might fail ~ manual retry
            - name: Some action that can fail
              id: myStepId2
              # Only run this step if step 1 fails. It knows that step one failed because we specified an `id` for the first step
              if: steps.myStepId1.outcome == 'failure'
              # This needs to be true to proceed to the next step of failure
              continue-on-error: true
              uses: actions/someaction

Bonus: Retrying multiple steps

If you want to retry multiple steps at once, then you can use composite actions to group the steps you want to retry and then use the duplicate steps approach mentioned above.

Conclusion

How do you decide which approach to use?

If you are retrying a step that is only shell commands then you can use the retry step action.
If you are retrying a step that needs to use another action, then you can use duplication of steps with conditional running to manually retry the steps.

This Dot Labs is a JavaScript consulting firm that enables companies to build and improve their digital technologies with confidence. For expert architectural guidance, training, consulting, engineering leadership, and development services in React, Angular, Vue, Web Components, GraphQL, Node, Bazel, Polymer, and more, visit thisdot.co

Using PartyTown to improve the performance of VueJS Applications

Allan N Jeremy — Fri, 14 Oct 2022 07:13:07 +0000

What is partytown?

Partytown is a JavaScript library that helps relocate resource intensive scripts (often third-party scripts) into a web worker and off the main thread. This speeds up our site by freeing up the main thread to run our code.

Note:
Partytown does not get bundled with the rest of your site's JavaScript. Instead, it intentionally stays separate from your code so that it can run within a webworker.

Using partytown with VueJS

To use partytown with VueJS, you need to find where your third-party scripts are inserted into your page. Typically, this would mean in the index.html page of your vue application.

Create the VueJS application

If you already have an existing VueJS application, you can skip this step. If you are simply looking to test out partytown, you can do so by creating a new VueJS project.

Create a new vue project by running [and following the steps after that].

npm init vue@latest

You should have an index.html in the generated project. In a new VueJS project, this is generally where we would add global third-party scripts. This file is also going to be where we add partytown

Add third-party scripts

If you already have third-party scripts such as Google Analytics or any other tracking/measurement scripts in your project, you can skip this step. Otherwise, you can set up third-party scripts.

Install partytown

To install partytyown into your application, all you need is to use npm or yarn where your package.json is of your project.

npm install @builder.io/partytown

or (if using yarn)

yarn add @builder.io/partytown

Setup PartyTown

Setup partytown (vite)

Available as of Partytown 0.3.6

Import the partytownVite plugin from @builder.io/partytown/utils into your vite.config.js config file. Next, add partytownVite(opts) to the plugins option.

The Vite plugin will copy Partytown lib directory to the given destination, which must be an absolute file path. The copying will happen at the time of the writeBundle() hook. When in dev mode, the Partytown lib files will be served using the Vite Dev Server.

Below is an example of using a Vite config to copy the Partytown lib to a dist build directory:

// vite.config.js
import path from "path";
import { partytownVite } from "@builder.io/partytown/utils";

export default ({ command }) => ({
  build: {
    plugins: [
      partytownVite({
        dest: path.join(__dirname, "dist", "~partytown"),
      }),
    ],
  },
});

Setup partytown (the long version)

After installing partytown, you need to modify your package.json to setup partytown. You do this by copying the partytown lib files into a directory we can reference from within our VueJS application.

Add the partytown script and change the relevant build/preview scripts to run the partytown script before your actual build/preview script.

// In package.json
"scripts": {
  // ...
  "dev": "partytown && vite",
  "build": "partytown && vite build",
  "preview": "partytown && vite preview --port 4173",
  "partytown": "partytown copylib public/~partytown"
}

You should see a public/~partytown directory in your project now. Inside this directory, we have a partytown.js file. This is the file we will be referencing in our html page.

It is also worth noting that as of the time of writing this article, there is no official integration for partytown with native VueJS applications. There are however other vue tool integrations such as the Nuxt partytown integration that make this process a lot faster. There are also approaches to setting up for different build tools such as vite and webpack

Using partytown with third-party scripts

Before we can use partytown with our thirdparty scripts, we need to include it into our page.
Open the index.html page and add your partytown script.

<!-- ./index.html -->
<head>
  <script src="public/~partytown/partytown"></script>
</head>

In order to use partytown to move the execution of your third-party scripts from the main thread to a web worker (and improve the performance of your VueJS application), all you need to do is mark the script with the type of text/partytown. Add the type="text/partytown" attribute for each script that should run from a web worker.

For example:

<script src="./third-party-script.js"></script>

would turn into

<script src="./third-party-script.js" type="text/partytown"></script>

By adding the text/partytown you are telling partytown that this script should not be executed on the main JavaScript thread. Partytown also makes sure that the script runs in a web worker for you, no additional setup required.

Note: that each script is opt-in, meaning that the updated type attribute should only be added to scripts that should run with Partytown. Partytown will not automatically upgrade any scripts unless this attribute is added.

Browser support

Partytown works to ensure that all browsers can still run third-party scripts, whether they have support for service workers, atomics, or neither. This means if you’re supporting legacy browsers such as IE11, the scripts should continue to work as if Partytown wasn’t being used.

For more information on partytown's browser support, you can check out the official partytown documentation.

Conclusion

By making sure our main thread does only what it needs to do (run our code), we can deliver smoother experiences for our users. PartyTown helps us do this effortlessly. I would recommend that you check it out. To learn more about PartyTown (including how to configure it), check out partytown's documentation.

Svelte Component Testing with Cypress + Vite

Ignacio Le Fluk — Mon, 08 Aug 2022 00:00:49 +0000

Cypress is a well-known e2e and integration testing framework. But since v7, a Cypress Component Test Runner was introduced, and it can be used to render and test components in isolation. It's still in alpha, so things may change!
In this blog post, we will set up our environment to test Svelte components while using Vite.

Starting a new project

First, we will start by creating a new project with Vite.

npm init vite@latest
// Project name: › cypress-svelte-testing
// Select a framework: › svelte
// Select a variant: › svelte-ts

cd cypress-svelte-testing
npm install

*Note: check Vite's documentation to find out how to start a project with other package managers.

The project is now configured to use Svelte and TypeScript.

To start our server, we need to run the command npm run dev.

We will be testing this application which consists of two components: App and Counter.
App is the shell, or the main component wrapping the counter component: a button that updates its count when clicked.

Installing dependencies

To run our tests, we need to install a few dependencies:
cypress: The testing framework
@cypress/vite-dev-server: Responsible for lanching and restarting the server when files change.
cypress-svelte-unit-test: A package to mount our components in the testing environment. Unfortunately, there's is no support at the moment of writing for our current environment, so we will be using a fork, and then we'll install it from the repo.
@testing-library/cypress: Optional. Adds selectors for our queries.

Let's go ahead and install all of these as dev-dependencies.

npm i --save-dev cypress @cypress/vite-dev-server @testing-library/cypress

npm i --save-dev https://github.com/flakolefluk/cypress-svelte-unit-test

Configuring the test environment

Now, we need to follow we will have to update or create some files to configure our environment. We'll go through each of them.

<root>/cypress.json to let cypress know where to find the component test files.

{
  "componentFolder": "src",
  "testFiles": "**/*spec.{js,jsx,ts,tsx}"
}

<root>/cypress/plugins/index.ts to configure the dev server:

import { startDevServer } from '@cypress/vite-dev-server';
import path from 'path';

module.exports = (on, config) => {
  on('dev-server:start', async (options) => {
    return startDevServer({
      options,
      viteConfig: {
        configFile: path.resolve(__dirname, '..', '..', 'vite.config.js'),
      },
    });
  });

  return config;
};

<root>/cypress/support/commands.js to add the testing library commands

import '@testing-library/cypress/add-commands';

<root>/tsconfig.json to add typescript support for the testing library commands

{
  // ...
  "compilerOptions": {
    // ...
    // add the following and preserve the rest of the config file
    "types": ["cypress", "@testing-library/cypress"]
  },
  // ...
}

<root>/package.json to add a few scripts that will run our tests

{
  // ...
  "scripts": {
// ...
    "cy:open-ct": "cypress open-ct",
    "cy:run-ct": "cypress run-ct"
  },
  // ...
}

Our tests are ready to be written!

In our cypress configuration file, we declared that the tests will live inside the src. This makes it possible to locate our tests next to our components.

Writing tests

We will test both components that were created along with the project.

Create two files, one next to each component:

// <root>/src/App.spec.ts
import App from './App.svelte';
import { mount } from 'cypress-svelte-unit-test';
describe('App', function () {
  it('renders App with correct heading', () => {
    mount(App);
    cy.findByRole('heading', { level: 1, name: /hello typescript/i }).should(
      'exist'
    ).should('be.visible');
  });
});

// <root>/src/Counter.spec.ts
import Counter from './Counter.svelte';
import { mount } from 'cypress-svelte-unit-test';
describe('Counter', function () {
  it('Renders button and updates count when clicked', () => {
    mount(Counter);
    cy.findByRole('button', { name: 'Clicks: 0' }).should('exist');
    cy.findByRole('button', { name: /Click/i }).click();
    cy.findByRole('button', { name: 'Clicks: 1' }).should('exist');
  });
});

I wrote a couple of tests as a start.
First, we check the App component and that it contains a heading with content, we also check that the element is visible.

For our Counter component, we first check that it exists. Then we click it and verify that the text inside it is updated with the expected current count.

In both tests, I'm using the queries provided by the *testing-library * package.

Running our tests

We can run our tests in two ways, with the run-ct and open-ct commands. The first one will tun the tests headlessly by default, while the second one will open the test runner.

Let's try both.

npm run cy:run-ct Your tests will run in your terminal and you'll get a nice overview of them.

npm run cy:open-ct Your tests will open in a browser and you'll be able to go through every step of your tests, which will make debugging a lot easier as you can see what's happening.

Time to write more tests!

Final thoughts

I hope this tutorial will help you set up your environment for working with Vite and Cypress to test your Svelte components. I find that testing with the open-ct command is really useful when writing tests. Most of the configuration shown is applicable to other frameworks too (There are other packages that will mount the components). Check the official documentation for more. You can find the code shown here in this repo.

This Dot Labs is a development consultancy focused on providing staff augmentation, architectural guidance, and consulting to companies.

We help implement and teach modern web best practices with technologies such as React, Angular, Vue, Web Components, GraphQL, Node, and more.

How to omit `.value` in refs (Vue 3 Composition API)

Allan N Jeremy — Fri, 17 Jun 2022 08:55:05 +0000

How to omit `.value` in refs (Vue 3 Composition API)

A technical article that expounds on how we can omit using .value in VueJS ref creating APIs by converting them into reactive variables using macros.

Introduction

When Vue 3 first came around, it introduced the Composition API. The API allowed for greater code re-usability as well as a better way to organize Vue JS code. Along with the composition API, came the concept of refs. To access the value of a ref, you needed to append .value to the name of the ref variable. To tackle this, the Vue team came up with a solution (Reactivity Transform) that would allow us to create reactive variables without creating refs.

Prerequisites

This article is primarily aimed at intermediate Vue 3 developers and assumes three things.

Intermediate knowledge of JavaScript
Basic Vue 3 usage
A basic understanding of how to use refs and reactivity in vue

The functionality discussed in this article is purely opt-in and existing behaviour is unnafected.

Tools needed

For this to work, you will need to be using vue@^3.2.25 and above. No additional dependencies are required. Vue 3.2.25+ ships an implementation under the package @vue/reactivity-transform. It is also integrated (with its APIs re-exported) in @vue/compiler-sfc so most userland projects won't need to explicitly install it.

Reactivity in Vue 3

Reactivity refers to the ability to keep track of changes that occur in our applications. One such way to achieve reactivity in Vue 3 is by using refs.

Creating Refs

The syntax for creating a ref would be something on the lines of this.

import { ref } from "vue";

// By wrapping our default value (true) with a ref, we tell vue to keep track of changes made to it
const isReading = ref(true);

This means that when the value of isReading changes, Vue knows about it and it can keep track of the changes. This means that UI is automatically updated whenever the value of isReading changes. In your template file, you would access the reactive value the same way you would access any variable, for example:

<template>
  <h1>{{ isReading ? "Shhh, I'm reading" : "Talk to me" }}</h1>
</template>

Using refs

That's all fine and dandy, but when you want to access or modify the value of the refs in the script, then you need to append a .value at the end of it. This is because ref() wraps the actual variable(isReading) in an object that can keep track of any changes made to it.

import { ref } from "vue";

const isReading = ref(true);

// prints an object that represents the ref object that wraps isReading
console.log(isReading);

// This is how you would need to access the value of isReading
console.log(isReading.value); // prints true

Reactivity Transform

Removing the need for `.value`

The new Vue 3 syntax allows you to use refs without needing to use .value. To make this work, the Vue team implemented Reactivity Transform. This allows us to create reactive variables for every API that creates refs instead of using refs. This means we can use our variables without appending .value everywhere. Reactive variables do not need .value to be accessed while refs need you to append .value.

Previously we used to write code like this

const isReading = ref(true);

console.log(isReading.value);

which can now be written like this

// Prepending $ to ref makes $ref() a macro that wraps around the original ref()
const isReading = $ref(true);

console.log(isReading); // no need to write

Behind the scenes, Vue will unwrap the $ref() and compile into the original .value syntax we are used to writing. The only difference is that this time you don't have to write isReading.value everywhere. This is particularly useful in areas where the ref created is used in multiple places within a script.

It is also worth noting that every reactivity API that returns refs will have a $-prefixed macro equivalent.
These APIs include:

ref -> $ref
computed -> $computed
shallowRef -> $shallowRef
customRef -> $customRef
toRef -> $toRef

Do you need to import `$ref` ?

Since $ref and equivalents are macros, they do not need to be imported. However, if you would like to import them explicitly, you can do so from vue/macros.

import { $ref } from "vue/macros";

Convert an existing ref as reactive variable using `$()`

In situations where we have a function that returns a ref, the Vue compiler would not be able to know that the function will return a ref ahead of time. In such cases, we can wrap the function call with $() to explicitly convert it into a reactive variable.

function getIsReadingRef() {
  return ref(true);
}

const isReading = $(getIsReadingRef());

Destructuring objects of refs

Previously, if you tried to destructure an object that was a ref, the destructured variables would lose their reactivity.

Let's go with an example ref.

const getDefaultReader = () => ref({ name: "VueJS lover", timeOnPage: 30 });

// Vue will be able to tell when any part of `reader` changes
const reader = ref(getDefaultReader());

// Vue won't be able to tell when the values of `name` and `timeOnpage` change
const { name, timeOnPage } = ref(getDefaultReader());

With Reactivity transform, you can destructure the objects of refs and maintain reactivity. You do so by wrapping the value with a $().

// Vue will now be able to tell when the values of `name` and `timeOnpage` change
const { name, timeOnPage } = $(getDefaultReader());

The above code will compile to:

const __temp = getDefaultReader(),
  name = toRef(__temp, "name");
timeOnPage = toRef(__temp, "timeOnPage");

Reactive props destructuring

This example is from the original Reactivity Transform RFC.

There are two pain points with the current defineProps() usage in <script setup>

Similar to .value, you need to always access props as props.x in order to retain reactivity. This means you cannot destructure defineProps because the resulting destructured variables are not reactive and will not update.
When using the type-only props declaration, there is no easy way to declare default values for the props. We introduced the withDefaults() API for this exact purpose, but it's still clunky to use.

<script setup lang="ts">
interface Props {
  msg: string;
  count?: number;
  foo?: string;
}

const {
  msg,
  // default value just works
  count = 1,
  // local aliasing also just works
  // here we are aliasing `props.foo` to `bar`
  foo: bar,
} = defineProps<Props>();

watchEffect(() => {
  // will log whenever the props change
  console.log(msg, count, bar);
});
</script>

The above will be combined to the following in runtime

export default {
  props: {
    msg: { type: String, required: true },
    count: { type: Number, default: 1 },
    foo: String,
  },
  setup(props) {
    watchEffect(() => {
      console.log(props.msg, props.count, props.foo);
    });
  },
};

Using $$() to retain reactivity

To get around reactivity loss in certain scenarios, the $$() macro can be used.

Retaining reactivity when passing refs as function arguments

Consider a situation where you have a function that needs to accept a reactive variable as an argument.

function trackChange(isReading: Ref<boolean>) {
  watch(isReading, (isReading) => {
    console.log("isReading changed!", isReading);
  });
}

let isReading = $ref(true);

// This will not work
trackChange(isReading);

In such a case, reactivity is lost.The reason for this is that the isReading ref is actually unwrapped into isReading.value when being passed in as the argument for trackChange while trackChange expects an actual ref. The above code compiles to this:

import { ref } from "vue";

let isReading = ref(true);

// This is what is actually happening
trackChange(isReading.value);

To get around this, we can wrap the ref in $$() which tells the compiler not to append a .value to it.

// This will work
trackChange($$(isReading));

The above example compiles to this:

import { ref } from "vue";

let isReading = ref(true);

// This is what we want - the isReading variable should be passed as a ref
trackChange(isReading);

Retaining reactivity when returning inside function scope

Another scenario where reactivity is lost is when we are returning reactive variables from within a function.

function useMouse() {
  let x = $ref(0);
  let y = $ref(0);

  // listen to mousemove...

  // doesn't work!
  return {
    x,
    y,
  };
}

Similar to the example with passing refs as arguments, the above return statement compiles to:

return {
  x: x.value,
  y: y.value,
};

In order to maintain the reactivity of x and y, we can wrap the entire return statement with the $$() macro.

function useMouse() {
  let x = $ref(0);
  let y = $ref(0);

  // listen to mousemove...

  // This works
  return $$({
    x,
    y,
  });
}

Retaining reactivity on destructured props

$$() works on destructured props since they are reactive variables as well. The compiler will convert it with toRef for efficiency:

const { count } = defineProps<{ count: number }>();

passAsRef($$(count));

compiles to:

setup(props) {
  const __props_count = toRef(props, 'count')
  passAsRef(__props_count)
}

TypeScript & Tooling Integration

Vue will provide typings for these macros (available globally) and all types will work as expected. There are no incompatibilities with standard TypeScript semantics so the syntax would work with all existing tooling.

This also means the macros can work in any files where valid JS/TS are allowed - not just inside Vue SFCs.

Since the macros are available globally, their types need to be explicitly referenced (e.g. in a env.d.ts file):

/// <reference types="vue/macros-global" />

When explicitly importing the macros from vue/macros, the type will work without declaring the globals.

Conclusion

By taking advantage of the macros added to Vue 3, you can drastically cleanup your code base by getting rid of .value usage. You also get to preserve reactivity within your application when destructuring reactive variables as well as props when using the Composition API and defineProps().

If you'd like to read more on the same, you can do so in the official Vue JS RFC discussion for the feature.

I do hope you find this helpful in reducing your code footprint and making your general life easier. The next time you think of using .value for your refs, remember that you don't have to. With that, thanks for stopping by(e)!

This Dot Labs is a development consultancy focused on providing staff augmentation, architectural guidance, and consulting to companies.

We help implement and teach modern web best practices with technologies such as React, Angular, Vue, Web Components, GraphQL, Node, and more.

7 Tips to be a Successful Developer in a Remote Company

Jessica Wilkins — Tue, 17 May 2022 00:08:23 +0000

When the pandemic hit in March of 2020, most companies were forced to go remote and millions of workers had to learn how to work from home. Two years later, a lot people now prefer the work from home option, and many job seekers are looking for remote-only companies to work for.

For software developers, there are many advantages to working from home and still effectively working as a team to produce high quality results. But how can you be successful in a remote company?

In this article, I will provide 7 tips on what it takes to be a successful developer in a remote company.

Communication is key

It is now more important than ever to communicate effectively with your team. Now that everyone is working from home instead of being in one physical office, you have to be very conscious to reach out to teammates and share your progress on a project. In a physical office, you are surrounded by other co-workers all day, which makes it easier to walk over to someone's office and share what you have been working on. It also makes it easier to have impromptu meetings with other team members throughout the day.

But in a remote setting, it is very easy to become isolated and get carried away with work without reaching out to anyone all day. This becomes an issue for your team, because now they are no longer keeping up to date on the latest changes you have been contributing to the project.

My tip would be to post periodic updates throughout the day of what you have been working on. If your company is using something like Slack or another chat server, make sure to post a detailed update on what you have been up to the past few hours.

Here is an example of one of the status updates I would post to my team.

Status update:

finished making changes to xyz case study and put it up for review
reviewed a couple of PRs
ran accessibility audits for the homepage and working on increasing the performance score

I would usually post this in the middle of the day to update the team on what I have been working on. I also try to ask questions throughout the day to ensure that I don't get blocked on a particular issue for to long. This method of communication helps me stay connected with the team and helps my manager know where I am at in the project.

Find a separate space in your home just for work

When you are working in an office, there is a clear separation between work and home. This makes it easier to end your day and leave your work at the office. But with remote work, sometimes these lines between work and home become a little bit blurry. This is why it is important to designate a separate work space in your home.

In my situation, I have a small desk in another room where I do all of my work. That space is only used Monday through Friday for work purposes. I have found that by creating a work space, it allows me to be in the moment and fully concentrate on my duties. Then at the end of the day, I logout out of everything and leave the work space just like I would leave a physical business. That has given me freedom to relax in my home when I am not working and fully recharge for the next day.

I understand that everyone's living situation is different, and you might not have room for a designated work area. In those cases, do the best you can to carve out some space in your living situation just for work. The more you can do to separate home and business, the more productive you will be at work.

Set consistent work hours

When you are working in an office, you have set hours for when you are going to be there. It might be 9-5 or 8-3 with breaks throughout the day. But when you are working from home, it is very easy to work without a set schedule and put in more time outside of the standard work hours. This can quickly lead to burnout which is a huge issue within the developer community.

It is really important to set a consistent work schedule so your team knows when you are available, and when you are off work. This also forces you to work within a time frame which will lead to better focus, time management and productivity.

I have personally found that setting that time frame from 8-5 with breaks helps me structure my day better and get more done than if I had an open schedule.

Take breaks throughout the day

Developer health is another huge issue within the community. Many developers, including myself have gone for hours hunched over their computers trying to get something to work. In these situations, it is very easy to lose track of time and develop back, neck, shoulder, and eye problems.

One of the key advantages of working from home is being able to take breaks and leave your work space. Take ten minute breaks throughout the day and make sure to walk around, stretch, go outside, and drink water. Taking breaks from the computer will give your body and brain a chance to rest and recharge.

When I first started working remotely, I would be glued to the computer for hours at a time. But I quickly felt the negative health effects and started becoming more intentional about taking breaks. Now, I have developed a healthier work situation and can see the difference in the quality of work I am producing.

Dress appropriately for important meetings

We all enjoy the relaxed dress code that often accompanies working from home. In an office, you will typically be in a more work appropriate attire especially when it comes to meetings with clients. But when you are at home, it is very easy to work in some sweatpants and a t shirt.

If you don't have any meetings that day, then coding in your casual attire is fine. But if you are meeting with clients or interviewing remotely, it is important to dress appropriately. Remember that it is still a business and you want to be as professional as possible, even in a remote setting.

Avoid mixing personal tasks and work tasks

When you are in an office, you don't worry about personal chores like doing laundry or taking the trash out. But when you are working from home, it is very easy to get distracted and mix personal tasks with work tasks. It is very important that while you are working, you are focused on work. Then during breaks, you can take care of personal items.

In my situation, I make sure to finish up the task I was working on and then take a break to put a load of laundry on or take care of another personal chore. There are definitely times where something has come up and I will make sure to communicate that with the team so they know I will be unavailable for a certain amount of time. But just try to do the best that you can separating personal tasks and issues from your work tasks.

Time management and structuring your day

In order to work productively, it is important to plan out your day as best you can and structure your time accordingly. For example, as I am writing this blog today, I made sure to set aside time for writing the first draft, revising it and submitting it for review. During that time block, I am not focused on other PR's or other work responsibilities. That ensures I am focused 100% on writing a high quality article.

Once I complete a large task, then I make sure to take a break, hydrate, walk around and eat something. That allows me to energize and gear up for the next task in my day. I found that breaking up my day into manageable tasks has provided me the opportunity to focus and produce good work.

Conclusion

Those are my 7 tips on what it takes to be a successful developer in a remote company. I encourage you to give each of those tips a try and see how it affects your work productivity.

This Dot Labs is a modern web consultancy focused on helping companies realize their digital transformation efforts. For expert architectural guidance, training, or consulting in React, Angular, Vue, Web Components, GraphQL, Node, Bazel, or Polymer, visit thisdot.co

How to implement a dark to light mode feature in your React/Sass project

Jessica Wilkins — Mon, 16 May 2022 23:30:27 +0000

There are many ways to implement a light/dark theme feature on your website. But how can you create a clean solution that will be easy to use and maintain overtime?

In this article, I will show you how to create a light/dark theme toggle functionality using React and Sass.

I have created a demo project based on the popular TV show Rick and Morty. There are a couple of pages dedicated to the main characters all designed in dark theme.

I will walk you through how to add light theme styles, and how to toggle between the two themes. You can then use this light theme solution in your own projects.

Prerequisites
Installation steps for the Demo App
How does the light/dark theme toggle work?
How to install the useDarkMode hook
Creating a custom useTheme hook
Creating the light/dark theme toggle button
Adding the useTheme hook to all the pages
How to add a Sass map for the light/dark theme styles
Applying the themes to the individual stylesheets

Prerequisites

This article assumes you have a basic fundamental knowledge of React, Sass, and the command line.

This demo project is using Yarn, so it is recommended that you install Yarn.

Installation steps for the Demo App

Clone the project



git clone https://github.com/jdwilkin4/Light-Dark-Theme-Starter-Code.git

cd into the Light-Dark-Theme-Starter-Code directory



cd Light-Dark-Theme-Starter-Code

Install the dependencies



yarn install

Start the local server



yarn start

You should see the homepage with two links that will lead you to the Rick and Morty pages.

How does the light/dark theme toggle work?

We will be creating a button where users can select if they prefer dark or light mode, and this button will toggle between the two styles. By default, the initial setting will be for dark mode.

When the user refreshes the page, their theme preference will be saved in local storage.

How to install the useDarkMode hook

We will be using an npm package called use-dark-mode which is a custom hook used to implement the toggle functionality between light and dark mode.

Keep your server running, open up a new tab in the terminal, and run the command yarn add use-dark-mode.

Creating a custom useTheme hook

The goal of this hook is to return a string value of either light-mode or dark-mode based on the current mode we are in. We will then use this string value as a class and apply it to the JSX elements.

Open up your code editor, locate the src folder and create a new folder called utils. Inside the utils folder, create a new file called useTheme.js.

At the top of your useTheme.js file, include the React and useDarkMode imports.



import React from "react";
import useDarkMode from "use-dark-mode";

Underneath those imports, add these two variables:



const lightTheme = "light-mode";
const darkTheme = "dark-mode";

Below the variable declarations, you will create the useTheme hook.



export const useTheme = () => {};

Inside the useTheme hook, we want to include the useDarkMode hook and assign it to a const variable called darkMode.



const darkMode = useDarkMode();

The return value for the useDarkMode() hook is an object, and one of the property names we are going to use is called value. The value property is a boolean which represents if dark mode is on or not.

Next, we want to add a new state variable and assign it the dark theme value.



const [theme, setTheme] = React.useState(darkTheme);

We are then going to add a useEffect hook and update the theme based on each time the mode changes.



React.useEffect(() => {
  setTheme(darkMode?.value ? darkTheme : lightTheme);
}, [darkMode.value]);

We are adding darkMode.value to the dependency array because we want it to only re-run the effect when the value changes on re-render.

Lastly, we want to return our theme.



return theme;

This is what the entire useTheme hook should look like.



export const useTheme = () => {
  const darkMode = useDarkMode();
  const [theme, setTheme] = React.useState(darkTheme);
  React.useEffect(() => {
    setTheme(darkMode?.value ? darkTheme : lightTheme);
  }, [darkMode.value]);

  return theme;
};

Creating the light/dark theme toggle button

Locate the src/components folder, and create a file ThemeBtn.js and a ThemeBtn.scss file.

Inside that file, add the imports for React, useDarkMode and useTheme.



import React from "react";
import useDarkMode from "use-dark-mode";
import { useTheme } from "../utils/useTheme";

Right underneath those imports, include your stylesheet for this button component.



import "../components/ThemeBtn.scss";

Now, we are going to create our Button component.



const ThemeBtn = () => {};
export default ThemeBtn;

Inside the ThemeBtn component, we are going to use the useDarkMode hook and set the value to true because we want the default to be set to dark mode.



const darkMode = useDarkMode(true);

We are also going to create a variable called theme and assign to it the useTheme hook.



const theme = useTheme();

Inside the return, we are going to create a button. Since darkMode is an object that has a property called toggle, we can use that in the onClick function to toggle between light and dark themes.

For the button text, we will create a ternary operator which will show the text of "Light mode" or "Dark mode" depending on the state of the theme.



return (
  <button className="btn-theme" type="button" onClick={darkMode.toggle}>
    {theme === "dark-mode" ? "Light mode" : "Dark mode"}
  </button>
);

In order to see our toggle button in action, we need to add it to one of the pages. Most people choose to add the toggle button to the navigation bar. For our demo project, we will add it to the App.js file.

Import the ThemeBtn into the App component, and add the <ThemeBtn /> just before the routes.



import ThemeBtn from "./components/ThemeBtn";
function App() {
  return (
    <>
      <ThemeBtn />
      <Routes>
        <Route path="/" element={<Homepage />} />
        <Route path="/rick" element={<RickSanchezPage />} />
        <Route path="/morty" element={<MortySmithPage />} />
      </Routes>
    </>
  );
}

You should now see the button in the browser. Try clicking on it and see the text change between light and dark mode.

Let's add some styling to our button.

Open up the ThemeBtn.scss file and add these styles for the btn-theme class.



@import "../styles/colors";

.btn-theme {
  background-color: $purple100;
  border: none;
  color: $grey100;
  display: block;
  font-size: 1.2rem;
  font-weight: 600;
  width: 150px;
  padding: 5px;
  text-align: center;
  margin: 0;
  cursor: pointer;

  &:hover {
    background-color: $purple200;
  }
}

Adding the useTheme hook to all the pages

We need to import the useTheme hook to all of our pages because we want to apply the dark and light mode classes to the JSX elements.

Inside the App.js file, import the useTheme hook.



import { useTheme } from "./utils/useTheme";

Inside the App component, create a variable called theme, and assign the hook to it.



const theme = useTheme();

Replace the empty React fragments with div elements, and apply the theme variable to the className.



<div className={theme}>
  <ThemeBtn />
  <Routes>
    <Route path="/" element={<Homepage />} />
    <Route path="/rick" element={<RickSanchezPage />} />
    <Route path="/morty" element={<MortySmithPage />} />
  </Routes>
</div>

For the Button.js file, import the useTheme hook, and create the theme variable like before. Then, add that variable to the className.



import { useTheme } from "../utils/useTheme";

export const Button = ({ text, path }) => {
  const theme = useTheme();
  return (
    <Link to={path} className={`btn ${theme}`}>
      {text}
    </Link>
  );
};

For the CharacterTemplate.js file, import the useTheme hook and create the theme variable like before. Then add that variable to the className for the div elements.



// here is the full JSX markup
<div className={theme}>
  <h1>{title}</h1>
  <Button text="Return Home" path="/" />
  <div className="flex-container">
    {characterInfo.map((character, id) => (
      <div key={id} className="character-container">
        <h2>{character.name}</h2>
        <img src={character.image} alt="character avatar" />
      </div>
    ))}
  </div>
</div>

How to add a Sass map for the light/dark theme styles

Inside the styles folder, open up the colors file and add the $grey200: #f5f1f1; variable.

This is what the complete colors file should look like.



$blue700: #1a1a40;
$blue600: #2c2c66;
$black: #000;
$grey100: #fdfcfc;
$grey200: #f5f1f1;
$purple100: #7a0bc0;
$purple200: #650c9d;

Inside the styles folder, create a new file called _light-dark-theme.scss.

At the top of your Sass file, import the colors file.



@import "./colors";

Then, we are going to create a new Sass map called themes.



$themes: ();

Inside the themes map, we are going to add individual maps for the background and text colors used for the light and dark themes.



$themes: (
  bgThemeColor1: (
    darkTheme: $blue700,
    lightTheme: $grey100
  ),
  bgThemeColor2: (
    darkTheme: $blue600,
    lightTheme: $grey200
  ),
  textThemeColor1: (
    darkTheme: $grey100,
    lightTheme: $black
  )
);

We are now going to create a mixin called styles with an argument called $mode. This mixin will be used later on in the dark-mode and light-modeclasses.



@mixin styles($mode) {
}

Inside the mixin, we are going to create an @each rule that will iterate through each key value pair in the themes map.



@each $key, $map in $themes {
}

The $key represents each of the background and text colors we created (Ex. bgThemeColor1). The $map represents each of the values.
For example:



  (
    darkTheme: $blue700,
    lightTheme: $grey100,
  )

Inside that @each rule, we are going to create another rule that iterates over each key/value pair for the individual maps.



@each $prop, $color in $map {
}

Inside that @each rule, we will create a condition that checks which mode we are in and applies the appropriate style to that class.



@if $prop == $mode {
  --#{$key}: #{$color};
}

The reason why we are adding the -- in front of the key, is because we want to reference these color variables in the individual stylesheets using CSS variable syntax.

For example:



var(--color)

This is what the complete mixin should look like.



@mixin styles($mode) {
  @each $key, $map in $themes {
    @each $prop, $color in $map {
      @if $prop == $mode {
        --#{$key}: #{$color};
      }
    }
  }
}

Below the mixin, we are going to add the light and dark theme styles to the appropriate classes using the @include rule.



.dark-mode {
  @include styles("darkTheme");
}

.light-mode {
  @include styles("lightTheme");
}

This is what the entire light-dark-theme file should look like.



@import "src/styles/colors";

$themes: (
  bgThemeColor1: (
    darkTheme: $blue700,
    lightTheme: $grey100,
  ),
  bgThemeColor2: (
    darkTheme: $blue600,
    lightTheme: $grey200,
  ),
  textThemeColor1: (
    darkTheme: $grey100,
    lightTheme: $black,
  ),
);

@mixin styles($mode) {
  @each $key, $map in $themes {
    @each $prop, $color in $map {
      @if $prop == $mode {
        --#{$key}: #{$color};
      }
    }
  }
}

.dark-mode {
  @include styles("darkTheme");
}

.light-mode {
  @include styles("lightTheme");
}

Applying the themes to the individual stylesheets

Inside the App.scss file, import the light-dark-theme file.



@import "./styles/light-dark-theme";

We are going to replace the background and text colors with the variables we created earlier.



body {
  background-color: var(--bgThemeColor1);
  color: var(--textThemeColor1);
  text-align: center;
}

If you test out the light/dark theme toggle button, you will notice that the background and text colors will change.

It would be nice if there were a gradual transition between the two colors. We can accomplish this by using the CSS transition property.



body {
  background-color: var(--bgThemeColor1);
  color: var(--textThemeColor1);
  text-align: center;
  transition: background-color 0.5s ease;
}

Inside the CharacterTemplate.scss file, import the light-dark-theme file.



@import "../styles/light-dark-theme";

Then replace the background and text colors with the CSS variables we created earlier.



  .character-container {
    color: var(--textThemeColor1);
    background-color: var(--bgThemeColor2);

Go to the browser and test out the light/dark theme button. You should be able to see both themes.

Conclusion

We have successfully created a light/dark theme solution using React and Sass.

You can implement this solution into your own projects and it will be easy to scale and maintain over time.

Here is the final demo project and source code.

12 Web Development Podcasts That Inform and Inspire

Jessica Wilkins — Fri, 06 May 2022 16:46:28 +0000

Podcasts can be a great source of entertainment and education. But with the sheer volume of podcasts out there, sometimes it is hard to know what to listen to.

In this article, I will share my favorite podcasts to listen to that discuss the latest in web technologies and careers.

Modern Web
CodeNewbie
The Changelog: Software Development, Open Source
JS Party: JavaScript, CSS, Web Development
Front End Happy Hour
Developer Tea
React Podcast
JavaScript Jabber
Syntax
HTML All The Things
Virtual Coffee Podcast
freeCodeCamp

Modern Web

The Modern Web podcast explores the latest in web development by interviewing leading industry professionals. Past guests have included Evan You (Creator of Vue.js), Jem Young (Engineering Manager at Netflix) and Mark Thompson (Developer Relations Engineer at Google).

The hosts are all Software Architects at This Dot Labs and they do a great job coming up with thought provoking questions for the guests.

My favorite episode is when Jesse Tomchak interviewed Jem Young and discussed his role as an engineering manager and the challenges he has faced so far.

CodeNewbie

If you are new developer and looking to learn more about the industry, then CodeNewbie is the podcast for you. Saron Yitbarek (host) and the rest of the team do a great job selecting a diverse range of topics and make it accessible to all developers.

Some of the guests have included Danny Thompson, Arit Amana, Cassidy Williams, Quincy Larson and Angie Jones.

My favorite episode is titled How freeCodeCamp has evolved over time with Quincy Larson. This episode chronicles Quincy's journey with freeCodeCamp and covers future developments for the organization.

The Changelog: Software Development, Open Source

The Changelog has over 400 episodes of interviews with leading industry professionals discussing everything from AI, to open source, UI/UX, engineering management, and more.

Adam Stacoviak and Jerod Santo do a great job creating engaging conversations with their guests and keeping it educational for the audience. Some of their guests have included Feross Aboukhadijeh, Annie Sexton and legendary computer scientist Brian Kernighan.

My favorite episode would have to be the interview on Brian Kernighan as he shares his thoughts on how software has evolved over his 50+ year career.

JS Party: JavaScript, CSS, Web Development

If you are interested in learning about all things JavaScript, then JS Party is the place to start. You will learn about the latest developments in popular web technologies, performance, open source projects and more.

Each week, they have a different set of hosts that include Jerod Santo, Feross Aboukhadijeh, Kevin Ball, and Amelia Wattenberger. Some of their previous guests have included Kent Dodds, Zach Leatherman, and Jen Looper.

My favorite episode is titled Remix helps bridge the network chasm where Kent Dodds talks about this new framework and why it is a good addition to the web ecosystem.

Front End Happy Hour

If you are looking for a laid back podcast discussing all things frontend web development, then take a listen to Front End Happy Hour.

Each week, a panel of Software Engineers from Netflix, Twitch, & Atlassian will invite guests to discuss their experiences with frontend development over a casual conversation with drinks. Previous guests have included Sumana Mohan, Joe King, Nazanin Delam, and Dan DiGangi.

My favorite episode is titled Standing out in a crowded bar where the hosts bring on Taylor Desseyn and Jono Grayson to discuss ways to stand out in the job market.

Developer Tea

Developer Tea produces short impactful episodes on career advancement. Jonathan Cutrell (host) covers a variety of topics including effectively working with management, staying motivated, and building better work relationships with your team.

A good episode to listen to would be Swizec Teller's two part episode on the Senior Engineering Mindset.

React Podcast

If you learning about React and want to hear about the latest developments, then the React Podcast is for you.

Michael Chan (host) interviews leading professionals about their thoughts on the industry and all things React development. Previous guests have included Shawn Swyx Wang, Cassidy Williams and Kent C. Dodds.

My favorite episode is titled Kent C. Dodds on Epic React where they discuss his popular React course and how it will help you level up as a developer.

JavaScript Jabber

JavaScript Jabber covers all things JavaScript including frontend architecture, Web3, React, D3 and more. The panel of hosts include Aimee Knight, AJ O'Neal, Charles Max Wood, Dan Shappir, and Steve Edwards.

My favorite episode is about Sam Sycamore's story on transitioning from landscape construction worker to full time developer.

Syntax

The Syntax podcast explores all this web related including the latest in Gatsby, AWS, Web3, Remix and more. Wes Bos and Scott Tolinski (hosts) do a great job creating fun and educational content for their listeners.

My favorite episode to listen to would be the JavaScript × STUMP’D episode where the two hosts try to answer JavaScript interview questions.

HTML All The Things

HTML All The Things cover all things web development, web design and small business. Matt Lawrence and Mike Karan (hosts) discuss a variety of topics including entrepreneurship, how to handle stress, Web3, web performance, and more.

My favorite episode to listen to is the one titled The Dark Side of Web Development which provides a look into the not so pleasant side of this industry.

Virtual Coffee Podcast

Virtual Coffee is a community of developers at all stages of their software journey who collaborate and support each other along the way. Each week, Dan Ott and Bekah Hawrot Weigel interview one of the community members to discuss their journey into tech.

My favorite episode is titled Yolanda Haynes - Breaking into Tech: It Takes Time which follows her journey into web development and the lessons she learned along the way.

There are plenty of inspiring stories to listen to on The Virtual Coffee Podcast that are both entertaining and educational.

freeCodeCamp

freeCodeCamp is an educational non-profit company with a mission to provide free programming education to everyone regardless of age, race or socioeconomic background. Their podcast features a lot of stories on how career changers made the transition into web development.

My favorite episode is titled How a former music teacher taught herself to code and landed a job at GitHub.

Conclusion

I hope you enjoyed my list of 12 podcasts that will inform and inspire your coding journey! I enjoy listening to these podcasts during work and I hope you do too.

Here are some more podcasts I am looking forward to exploring in the future and have been well received by the developer community.

State of React Wrap-up | April 26, 2022

Jessica Wilkins — Fri, 06 May 2022 16:41:37 +0000

In this State of React event, the main topic focused on the React 18 release. Our panelists had a lot of thoughts on the release, its latest features, and the React working group. We also got an update on the state of Redux, and heard about our panelists' experiences at the 2022 React Miami conference.

Here is a complete list of the hosts and panelists that participated in the online event.

Hosts

Dustin Goodman, Engineering Manager, This Dot Labs, @dustinsgoodman
Dane Grant, Senior Software Engineer, This Dot Labs, @danecando

Panelists

Jen Luker, Senior Staff Frontend Engineer, Nav, Inc., @knitcodemonkey
Ben Ilegbodu, Frontend Architect, Stitch Fix, @benmvp
Romello Goodman, Educator at MICA & Senior Engineer, Shopify, @mellogood
Kathleen McMahon, Senior Design Systems Engineer, Northwestern Mutual, @resource11
Chantastic, DX Engineer, Chromatic, @chantastic
Mark Erikson, Senior Front-End Engineer, Replay, @acemarke

You can watch the full State of React event on the This Dot Media YouTube Channel.

React 18 is finally here!!!

The conversation got started with the panelists sharing their thoughts on the latest release and why they felt like it was a little bit anti-climatic. After years of hard work and anticipation, the final release didn't generate as much noise in the community as previous versions of React. Some of the panelists believe that a lot of the blog posts and conversations about the latest changes happened months ago. This might have contributed to a quiet release this time around.

There was also praise for the React 18 working group which did a great job of communicating with the community over the years about progress of the new version. They also tried to incorporate a lot of the community feedback into this latest release. The hard work and care of the React 18 working group also contributed to the quiet and stable release of this latest version.

Does the anti-climatic release of React 18 signal that people are tired of React?

There was a question posed to the group that maybe people were tired of React and that is why it was anti-climatic. But the panelists believe that this quiet release means that React is becoming more of a standard in the JavaScript ecosystem. They also brought up the good point that a lot of developers have already been working with some of the new features before the official release date.

What do the panelists think about the new features of React 18?

One of the panelists expressed interest in trying out the new useTransition hook which allows you to specify some states as a lower priority. But they also made the point that there wasn't an immediate need in their current projects to incorporate some of the newer features. Sometimes you are comfortable working in your codebase and it is fine to use the existing hooks that are already there. It might become a situation where new developers learning React for the first time will push for the use of these new features.

This led to conversation about how React 18 helped solve a lot of problems that library authors were experiencing. For example, the new concurrent suspense and transition APIs will make it easier for loader indicators. But there was another hook mentioned that peaked the interest of some of the panelists. The useId hook generates a unique random ID that is consistent in server side and client side rendering. The panelists were excited about how easy it was to use and how it would improve on accessibility. They were also grateful that the name was changed from useOpaqueIdentifier to useId.

Will the React working group continue?

There are no current plans for the React working group, and it has been relatively quiet since the release. But the panelists do believe that this group set the tone for future major releases. As mentioned earlier, the React working group did a great job working with the community and creating a smooth transition from React 17 to React 18.

What are some of the new features that developers need to learn before migrating to React 18?

The first feature that was mentioned was the new root API. In React 17, this is how you would render your App component.

import { render } from "react-dom";
import App from "App";
render(<App tab="home" />, document.getElementById("app"));

But with React 18, you would use the new createRoot API.

import { createRoot } from "react-dom/client";
import App from "App";

const root = createRoot(document.getElementById("app"));
root.render(<App tab="home" />);

Another feature that was mentioned was flushSync which allows you to opt out of automatic batching.

The State of Redux with Mark Erikson

At this point of the conversation, we transitioned into a short powerpoint presentation on the state of Redux.
Here are the key points mentioned in that presentation.

React-Redux v8.0 is now live.
Redux JS/TS templates for Create React App have been updated.
This new version works with React 16.8, 17, 18 and React Native
React-Redux v8.0 has been converted to TypeScript
Redux Toolkit 1.8 has a new "listener" side effects middleware which allows you to do powerful async/await workflows.
Redux 4.2.0 has officially marked createStore as deprecated

Should people start migrating over to React 18 now or is there a waiting period?

During this part of the conversation panelists talked about what is supported by React 18. For example, if your application uses Enzyme for testing, then it will not be supported by React 18. This would require you to rewrite all of your tests just to accommodate this latest version. Developers need to understand what is supported by this new version before migrating over. The panelists also pointed out that it will take a few months of the community working with React 18 before potential issues come to light.

What was React Miami like? What was it like to have in person conferences again?

I think Mark Erikson had the best quote to sum up the 2022 React Miami conference.

"Warm, fun, awesome, tiring, weird"

Well, that works for me. :)

But in all seriousness, both Ben and Kathleen gave talks and enjoyed their time at the conference. The general consensus was that it was nice to connect with the community again in person, even if it was weird at times.

Are there any new exciting courses or articles coming out for React 18?

There was a lot of a great discussions in the React working group GitHub repository. A lot of authors were able to create great blog posts out of those discussions.

There was also a quick shout out to Dustin and Dane for their involvement with the new React beta site. You can learn more about that in this Meta case study.

The downside of React being unopinionated

Mark brought up the issue he has seen with React developers not knowing what to use for styling, state management and build tools. Since React is unopinionated, there should be a place where developers can learn about the common technologies that work well with React.

Luckily for us, This Dot Labs has created a tool to tackle this issue. react.framework.dev is a community driven list of resources for React.

Accessibility matters

In the closing conversation, there was a lot of discussion on how the new Rect 18 features will improve on accessibility. The panelists also felt like all developers should care more about creating well built accessible applications and take the time to learn about best accessibility practices.

Conclusion

This was an incredible conversation with a great group of panelists and I would highly suggest you watch the video. You can watch the full State of React event on the This Dot Media YouTube Channel.

Migrating a classic Express.js to Serverless Framework

Dustin Goodman — Thu, 21 Apr 2022 03:37:03 +0000

Problem

Classic Express.js applications are great for building backends. However, their deployment can be a bit tricky. There are several solutions on the market for making deployment "easier" like Heroku, AWS Elastic Beanstalk, Qovery, and Vercel. However, "easier" means special configurations or higher service costs.

In our case, we were trying to deploy an Angular frontend served through Cloudfront, and needed a separately deployed backend to manage an OAuth flow. We needed an easy to deploy solution that supported HTTPS, and could be automated via CI.

Serverless Framework

The Serverless Framework is a framework for building and deploying applications onto AWS Lambda, and it allowed us to easily migrate and deploy our Express.js server at a low cost with long-term maintainability. This was so simple that it only took us an hour to migrate our existing API, and get it deployed so we could start using it in our production environment.

Serverless Init Script

To start this process, we used the Serverless CLI to initialize a new Serverless Express.js project. This is an example of the settings we chose for our application:

$ serverless
What do you want to make? AWS - Node.js - Express API
What do you want to call this project? example-serverless-express

Downloading "aws-node-express-api" template...
Installing dependencies with "npm" in "example-serverless-express" folder
Project successfully created in example-serverless-express folder

What org do you want to add this service to? [Skip]
Do you want to deploy your project? No

Your project is ready for deployment and available in ./example-serverless-express
Run **serverless deploy** in the project directory
    Deploy your newly created service
Run **serverless info** in the project directory after deployment
    View your endpoints and services
Run **serverless invoke** and **serverless logs** in the project directory after deployment
    Invoke your functions directly and view the logs
Run **serverless** in the project directory
    Add metrics, alerts, and a log explorer, by enabling the dashboard functionality

Here's a quick explanation of our choices:

What do you want to make? This prompt offers several possible scaffolding options. In our case, the Express API was the perfect solution since that's what we were migrating.

What do you want to call this project? You should put whatever you want here. It'll name the directory and define the naming schema for the resources you deploy to AWS.

What org do you want to add this service to? This question assumes you are using the serverless.com dashboard for managing your deployments. We're choosing to use Github Actions and AWS tooling directly though, so we've opted out of this option.

Do you want to deploy your project? This will attempt to deploy your application immediately after scaffolding. If you don't have your AWS credentials configured correctly, this will use your default profile. We needed a custom profile configuration since we have several projects on different AWS accounts so we opted out of the default deploy.

Serverless Init Output

The init script from above outputs the following:

.gitignore
handler.js
package.json
README.md
serverless.yml

The key here is the serverless.yml and handler.js files that are outputted.

serverless.yml

service: example-serverless-express
frameworkVersion: '2 || 3'

provider:
  name: aws
  runtime: nodejs12.x
  lambdaHashingVersion: '20201221'

functions:
  api:
    handler: handler.handler
    events:
      - httpApi: '*'

handler.js

const serverless = require("serverless-http");
const express = require("express");
const app = express();

app.get("/", (req, res, next) => {
  return res.status(200).json({
    message: "Hello from root!",
  });
});

app.get("/hello", (req, res, next) => {
  return res.status(200).json({
    message: "Hello from path!",
  });
});

app.use((req, res, next) => {
  return res.status(404).json({
    error: "Not Found",
  });
});

module.exports.handler = serverless(app);

As you can see, this gives a standard Express server ready to just work out of the box. However, we needed to make some quality of life changes to help us migrate with confidence, and allow us to use our API locally for development.

Quality of Life Improvements

There are several things that Serverless Framework doesn't provide out of the box that we needed to help our development process. Fortunately, there are great plugins we were able to install and configure quickly.

Environment Variables

We need per-environment variables as our OAuth providers are specific per host domain. Serverless Framework supports .env files out of the box but it does require you to install the dotenv package and to turn on the useDotenv flag in the serverless.yml.

Babel/TypeScript Support

As you can see in the above handler.js file, we're getting CommonJS instead of modern JavaScript or TypeScript. To get these, you need webpack or some other bundler. serverless-webpack exists if you want full control over your ecosystem, but there is also serverless-bundle that gives you a set of reasonable defaults on webpack 4 out of the box. We opted into this option to get us started quickly.

Offline Mode

With classic Express servers, you can use a simple node script to get the server up and running to test locally. Serverless wants to be run in the AWS ecosystem making it. Lucky for us, David Hérault has built and continues to maintain serverless-offline allowing us to emulate our functions locally before we deploy.

Final Configuration

Given these changes, our serverless.yml file now looks as follows:

service: starter-dev-backend
frameworkVersion: '2 || 3'
useDotenv: true # enable .env file support

plugins: # install serverless plugins
  - serverless-bundle
  - serverless-offline

custom: # configure serverless-offline
  serverless-offline:
    httpPort: 4000

provider:
  name: aws
  profile: exampleprofile # use your own profile
  stage: production # use your specified stage
  runtime: nodejs14.x
  lambdaHashingVersion: '20201221'

functions:
  api:
    handler: handler.handler
    events:
      - httpApi: '*'

Some important things to note:

The order of serverless-bundle and serverless-offline in the plugins is critically important.
The custom port for serverless-offline can be any unused port. Keep in mind what port your frontend server is using when setting this value for local development.
We set the profile and stage in our provider configuration. This allowed us to use specify the environment settings and AWS profile credentials to use for our deployment.

With all this set, we're now ready to deploy the basic API.

Deploying the new API

Serverless deployment is very simple. We can run the following command in the project directory:

$ serverless deploy

This command will deploy the API to AWS, and create the necessary resources including the API Gateway and related Lambdas. The first deploy will take roughly 5 minutes, and each subsequent deply will only take a minute or two! In its output, you'll receive a bunch of information about the deployment, including the deployed URL that will look like:

https://<hash-string>.execute-api.<region>.amazonaws.com

You can now point your app at this API and start using it.

Next Steps

A few issues we still have to resolve but are easily fixed:

New Lambdas are not deploying with their Environment Variables, and have to be set via the AWS console. We're just missing some minor configuration in our serverless.yml.
Our deploys don't deploy on merges to main. For this though, we can just use the official Serverless Github Action. Alternatively, we could purchase a license to the Serverless Dashboard, but this option is a bit more expensive, and we're not using all of its features on this project. However, we've used this on other client projects, and it really helped us manage and monitor our deployments.

Conclusion

Given all the above steps, we were able to get our API up and running in a few minutes. And due to it being a 1-to-1 replacement for an existing Express server, we were able to port our existing implementations into this new Serverless implementation, deploy it to AWS, and start using it in just a couple of hours.

This particular architecture is a great means for bootstraping a new project, but it does come with some scaling issues for larger projects. As such, we do not recommend a pure Serverless, and Express for monolithic projects, and instead suggest utilizing some of the amazing capabilities of Serverless Framework with AWS to horizontally scale your application into smaller Lambda functions.

This Dot Labs is a development consultancy focused on providing staff augmentation, architectural guidance, and consulting to companies.

We help implement and teach modern web best practices with technologies such as React, Angular, Vue, Web Components, GraphQL, Node, and more.

Forem: This Dot

Exploring Angular Forms: A New Alternative with Signals

Exploring Angular Forms: A New Alternative with Signals

Recap: Angular Forms Approaches

Introducing Signals as a New Way to Handle Form Reactivity

Example 1: A Simple Template-Driven Form with Signals

Example 2: A Complex Form with Signals

Validating Forms with Signals

Why Use Signals in Angular Forms?

Conclusion

"How do I undo my most recent commit?" - Mastering the git reset command

"How do I undo my most recent commit?" - Mastering the git reset command

The Basics of git reset

Soft vs. Hard Reset: Understanding the Difference

Soft Reset (--soft)

Hard Reset (--hard)

Specifying a Commit Hash

Using HEAD~n Notation

Reverting Pushed Changes

Generic Usage of git reset

Conclusion

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Why use the dialog element?

Basic usage

Accessibility and focus management

Adding forms to dialogs

Enhancing the backdrop

Conclusion

How to retry failed steps in GitHub Action Workflows

Pre-requisites

Initial setup

Initialize your git repository

Create workflow file

Testing your workflow

Retrying failed steps

Approach 1: Using the retry-step action

Approach 2: Duplicate steps

Bonus: Retrying multiple steps

Conclusion

Using PartyTown to improve the performance of VueJS Applications

What is partytown?

Using partytown with VueJS

Create the VueJS application

Add third-party scripts

Install partytown

Setup PartyTown

Setup partytown (vite)

Setup partytown (the long version)

Using partytown with third-party scripts

Browser support

Conclusion

Svelte Component Testing with Cypress + Vite

Starting a new project

Installing dependencies

Configuring the test environment

Writing tests

Running our tests

Final thoughts

How to omit `.value` in refs (Vue 3 Composition API)

How to omit .value in refs (Vue 3 Composition API)

Introduction

Prerequisites

Tools needed

Reactivity in Vue 3

Creating Refs

Using refs

Reactivity Transform

Removing the need for .value

Do you need to import $ref ?

Convert an existing ref as reactive variable using $()

Destructuring objects of refs

Reactive props destructuring

Using $$() to retain reactivity

Retaining reactivity when passing refs as function arguments

Retaining reactivity when returning inside function scope

Retaining reactivity on destructured props

TypeScript & Tooling Integration

Conclusion

7 Tips to be a Successful Developer in a Remote Company

How to omit `.value` in refs (Vue 3 Composition API)

Removing the need for `.value`

Do you need to import `$ref` ?

Convert an existing ref as reactive variable using `$()`