DEV Community: This Dot Media

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

This Dot Media — Tue, 12 Nov 2024 08:56:11 +0000

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

I have learned my fair share about the importance of keyboard accessibility, so I know that visual indication of the focused element is very important. But the well-known :focus pseudo-class is not always the best fit for this job. That's where :focus-visible comes in. Let's look at the differences between these two pseudo-classes and explore the best practices for using them effectively.

What is the `:focus` Pseudo-Class?

The :focus pseudo-class is a CSS selector that applies styles to any element that receives focus, regardless of how that focus was triggered. This includes focus events from keyboard navigation, mouse clicks, and touch interactions.

Example Usage of `:focus`

button:focus {
  outline: 2px solid blue;
}

In this example, the button will display a blue outline whenever it is focused, whether the user clicks on it with a mouse, taps it on a touchscreen, or navigates to it using the keyboard.

What is the `:focus-visible` Pseudo-Class?

The :focus-visible pseudo-class is more specialized. It only applies styles to an element when the browser determines that the focus should be visible. This typically occurs when the user navigates via the keyboard or assistive technologies rather than through mouse or touch input.

Example Usage of `:focus-visible`

button:focus-visible {
  outline: 2px solid blue;
}

Here, the button will only show a blue outline when focused through keyboard navigation or another input method that usually requires visible focus indicators.

Key Differences Between `:focus` and `:focus-visible`

`:focus`

Behavior: Applies to any element that receives focus, regardless of the input method.
Use Cases: Ensures that all interactions with the element are visually indicated, whether by mouse, keyboard, or touch.

`:focus-visible`

Behavior: Applies styles only when the focus should be visible, such as using a keyboard or assistive technology.
Use Cases: Ideal for scenarios where you want to provide focus indicators only to keyboard and assistive technology users while avoiding unnecessary outlines for mouse and touch users, typically required by design.

Accessibility Implications

`:focus`

Pros:
Guarantees that all users can see when an element is focused, which is critical for accessibility.
Cons:
Can lead to a suboptimal experience for mouse users, as focus styles may appear unnecessarily during mouse interactions.

`:focus-visible`

Pros:
Enhances user experience by showing focus indicators only when necessary, thus keeping the interface clean for mouse and touch users.
Tailors the experience for keyboard and assistive technology users, providing them with clear visual cues.
Cons:
Additional considerations may be required to ensure that focus indicators are not accidentally omitted, especially in older browsers that do not support :focus-visible.
- There may be cases where you want to show focus indicators for all users, regardless of input method.

Best Practices for Using `:focus` and `:focus-visible`

To achieve the best accessibility and user experience, combining both :focus and :focus-visible in your CSS is often a good idea.

Combining `:focus` and `:focus-visible`

button:focus {
  outline: none; /* Remove default focus for all interactions */
 /* maybe some subtle general focus style */
}

button:focus-visible {
  outline: 2px solid blue; /* Only show outline when the element was interacted with via keyboard or assistive technology */
}

Here is a Stackblitz example of what such styling could look like for you to try out and play with:

Additional Tips

Test with Keyboard and Assistive Technology: Ensure that your web application is navigable using a keyboard (Tab, Shift + Tab, etc.) and that focus indicators are visible for those who rely on them. It's never a bad idea to include accessibility testing in your e2e testing suite.
Provide Clear Focus Indicators: Make sure that focus indicators are prominent and easy to see. A subtle or hard-to-spot focus indicator can severely impact accessibility for users who rely on keyboard navigation.

Conclusion

The :focus-visible pseudo-class offers a more refined way to manage focus indicators, improving accessibility and user experience, particularly for keyboard and assistive technology users. By understanding the differences between :focus and :focus-visible, and applying best practices in your CSS, you can create more accessible and user-friendly web applications.

Remember, accessibility should never be an afterthought. By thoughtfully applying focus styles, you ensure that all users, regardless of how they interact with your site, can easily navigate and interact.

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 build an AI assistant with OpenAI, Vercel AI SDK, and Ollama with Next.js

This Dot Media — Wed, 06 Nov 2024 12:47:53 +0000

In today’s blog post, we’ll build an AI Assistant using three different AI models: Whisper and TTS from OpenAI and Llama 3.1 from Meta.

While exploring AI, I wanted to try different things and create an AI assistant that works by voice. This curiosity led me to combine OpenAI’s Whisper and TTS models with Meta’s Llama 3.1 to build a voice-activated assistant.

Here’s how these models will work together:

First, we’ll send our audio to the Whisper model, which will convert it from speech to text.
Next, we’ll pass that text to the Llama 3.1 model. Llama will understand the text and generate a response.
Finally, we’ll take Llama’s response and send it to the TTS model, turning the text back into speech. We’ll then stream that audio back to the client.

Let’s dive in and start building this excellent AI Assistant!

Getting started

We will use different tools to build our assistant. To build our client side, we will use Next.js. However, you could choose whichever framework you prefer.

To use our OpenAI models, we will use their TypeScript / JavaScript SDK. To use this API, we require the following environmental variable: OPENAI_API_KEY—

To get this key, we need to log in to the OpenAI dashboard and find the API keys section. Here, we can generate a new key.

Awesome. Now, to use our Llama 3.1 model, we will use Ollama and the Vercel AI SDK, utilizing a provider called ollama-ai-provider.

Ollama will allow us to download our preferred model (we could even use a different one, like Phi) and run it locally. The Vercel SDK will facilitate its use in our Next.js project.

To use Ollama, we just need to download it and choose our preferred model. For this blog post, we are going to select Llama 3.1. After installing Ollama, we can verify if it is working by opening our terminal and writing the following command:

Notice that I wrote “llama3.1” because that’s my chosen model, but you should use the one you downloaded.

Kicking things off

It's time to kick things off by setting up our Next.js app. Let's start with this command:

npx create-next-app@latest

After running the command, you’ll see a few prompts to set the app's details. Let's go step by step:

Name your app.
Enable app router.

The other steps are optional and entirely up to you. In my case, I also chose to use TypeScript and Tailwind CSS.

Now that’s done, let’s go into our project and install the dependencies that we need to run our models:

npm i ai ollama-ai-provider openai

Building our client logic

Now, our goal is to record our voice, send it to the backend, and then receive a voice response from it.

To record our audio, we need to use client-side functions, which means we need to use client components. In our case, we don’t want to transform our whole page to use client capabilities and have the whole tree in the client bundle; instead, we would prefer to use Server components and import our client components to progressively enhance our application.

So, let’s create a separate component that will handle the client-side logic.

Inside our app folder, let's create a components folder, and here, we will be creating our component:

app
 ↳components
  ↳audio-recorder.tsx

Let’s go ahead and initialize our component. I went ahead and added a button with some styles in it:

// app/components/audio-recorder.tsx
'use client'
export default function AudioRecorder() {
    function handleClick(){
      console.log('click')
    }

    return (
        <section>
        <button onClick={handleClick}
                    className={`bg-blue-500 text-white px-4 py-2 rounded shadow-md hover:bg-blue-400 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:ring-offset-2 focus:ring-offset-white transition duration-300 ease-in-out absolute top-1/2 left-1/2 -translate-x-1/2 -translate-y-1/2`}>
                Record voice
            </button>
        </section>
    )
}

And then import it into our Page Server component:

// app/page.tsx
import AudioRecorder from '@/app/components/audio-recorder';

export default function Home() {
  return (
      <AudioRecorder />
  );
}

Now, if we run our app, we should see the following:

Awesome! Now, our button doesn’t do anything, but our goal is to record our audio and send it to someplace; for that, let us create a hook that will contain our logic:

app
 ↳hooks
  ↳useRecordVoice.ts

import { useEffect, useRef, useState } from 'react';

export function useRecordVoice() {
  return {}
}

We will use two APIs to record our voice: navigator and MediaRecorder. The navigator API will give us information about the user’s media devices like the user media audio, and the MediaRecorder will help us record the audio from it. This is how they’re going to play out together:

// apps/hooks/useRecordVoice.ts
import { useEffect, useRef, useState } from 'react';

export function useRecordVoice() {
    const [isRecording, setIsRecording] = useState(false);
    const [mediaRecorder, setMediaRecorder] = useState<MediaRecorder | null>(null);

     const startRecording = async () => {
        if(!navigator?.mediaDevices){
            console.error('Media devices not supported');
            return;
        }

        const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
        const mediaRecorder = new MediaRecorder(stream);
        setIsRecording(true)
        setMediaRecorder(mediaRecorder);
        mediaRecorder.start(0)
    }

    const stopRecording = () =>{
        if(mediaRecorder) {
            setIsRecording(false)
            mediaRecorder.stop();
        }
    }

  return {
    isRecording,
    startRecording,
    stopRecording,
  }
}

Let’s explain this code step by step. First, we create two new states. The first one is for keeping track of when we are recording, and the second one stores the instance of our MediaRecorder.

 const [isRecording, setIsRecording] = useState(false);
    const [mediaRecorder, setMediaRecorder] = useState<MediaRecorder | null>(null);

Then, we’ll create our first method, startRecording. Here, we are going to have the logic to start recording our audio.
We first check if the user has media devices available thanks to the navigator API that gives us information about the browser environment of our user:

If we don’t have media devices to record our audio, we just return. If they do, then let us create a stream using their audio media device.

// check if they have media devices
if(!navigator?.mediaDevices){
 console.error('Media devices not supported');
 return;
}
// create stream using the audio media device
const stream = await navigator.mediaDevices.getUserMedia({ audio: true });

Finally, we go ahead and create an instance of a MediaRecorder to record this audio:

// create an instance passing in the stream as parameter
const mediaRecorder = new MediaRecorder(stream);
// Set this state to true to 
setIsRecording(true)
// Store the instance in the state
setMediaRecorder(mediaRecorder);
// Start recording inmediately
mediaRecorder.start(0)

Then we need a method to stop our recording, which will be our stopRecording. Here, we will just stop our recording in case a media recorder exists.

if (mediaRecorder) {
  setIsRecording(false)
  mediaRecorder.stop();
}

We are recording our audio, but we are not storing it anywhere. Let’s add a new useEffect and ref to accomplish this.
We would need a new ref, and this is where our chunks of audio data will be stored.

const audioChunks = useRef<Blob[]>([]);

In our useEffect we are going to do two main things: store those chunks in our ref, and when it stops, we are going to create a new Blob of type audio/mp3:

export function useRecordVoice() {   
   const audioChunks = useRef<Blob[]>([]);

   ...
   useEffect(() => {
        if (mediaRecorder) {
            // listen to when data is available and store it as chunks in our ref
            mediaRecorder.ondataavailable = (e) => {
                audioChunks.current.push(e.data);
            }

            mediaRecorder.onstop = () => {
                // Listen to when we stop recording audio 
                // Then, convert our data to a Blob of type audio/mp3 and reset the ref
                const audioBlob = new Blob(audioChunks.current, { type: 'audio/mp3' });
                audioChunks.current = [];
            }
        }

    }, [mediaRecorder]);
    ...
}

It is time to wire this hook with our AudioRecorder component:

'use client'
import { useRecordVoice } from '@/hooks/useRecordVoice';

export default function AudioRecorder() {
    const { isRecording, stopRecording, startRecording } = useRecordVoice();

    async function handleClick() {
        if (isRecording) {
           stopRecording();
         } else {
         await startRecording();
       }
     }

    return (
        <div>

            <button onClick={handleClick}
                    className={`bg-blue-500 text-white px-4 py-2 rounded shadow-md hover:bg-blue-400 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:ring-offset-2 focus:ring-offset-white transition duration-300 ease-in-out absolute top-1/2 left-1/2 -translate-x-1/2 -translate-y-1/2`}>
                {isRecording ? "Stop Recording" : "Start Recording"}
            </button>

        </div>
    )
}

Let’s go to the other side of the coin, the backend!

Setting up our Server side

We want to use our models on the server to keep things safe and run faster. Let’s create a new route and add a handler for it using route handlers from Next.js. In our App folder, let’s make an “Api” folder with the following route in it:

app
 ↳api
  ↳chat
    ↳route.ts

Our route is called ‘chat’. In the route.ts file, we’ll set up our handler. Let’s start by setting up our OpenAI SDK.

const openai = getOpenai();

export async function POST(req: Request) {
  // our logic will go here
}

// inside a utils folder apps/utils/get-openai.ts
import OpenAI from 'openai';

const openai = new OpenAI({
    apiKey: process.env.OPENAI_API_KEY,
});

export function getOpenai() {
    return openai;
}

In this route, we’ll send the audio from the front end as a base64 string. Then, we’ll receive it and turn it into a Buffer object.

export async function POST(req: Request) {
    const { audio } = await req.json();
    const audioBuffer = Buffer.from(audio, 'base64');
 }

It’s time to use our first model. We want to turn this audio into text and use OpenAI’s Whisper Speech-To-Text model. Whisper needs an audio file to create the text. Since we have a Buffer instead of a file, we’ll use their ‘toFile’ method to convert our audio Buffer into an audio file like this:

import { toFile } from 'openai';

export async function POST(req: Request) {
    const { audio } = await req.json();
    const audioBuffer = Buffer.from(audio, 'base64');

    try {
        // FileLike object
        const audioFile = await toFile(audioBuffer, 'audio.mp3');

    } catch (err) {
        console.error(err);
        return NextResponse.json(
            {
                err: err,
                error: 'Error converting audio',
            },
            {
                status: 500,
            }
        );
    }
}

Notice that we specified “mp3”. This is one of the many extensions that the Whisper model can use. You can see the full list of supported extensions here: https://platform.openai.com/docs/api-reference/audio/createTranscription#audio-createtranscription-file

Now that our file is ready, let’s pass it to Whisper! Using our OpenAI instance, this is how we will invoke our model:

import { toFile } from 'openai';
const openai = getOpenai();

export async function POST(req: Request) {
        ...
        const audioFile = await toFile(audioBuffer, 'audio.mp3');

        const transcription = await openai.audio.transcriptions.create({
            // here we specify the model
            model: 'whisper-1',
            // our audio file
            file: audioFile,
        });
        ...
}

That’s it! Now, we can move on to the next step: using Llama 3.1 to interpret this text and give us an answer. We’ll use two methods for this. First, we’ll use ‘ollama’ from the ‘ollama-ai-provider’ package, which lets us use this model with our locally running Ollama. Then, we’ll use ‘generateText’ from the Vercel AI SDK to generate the text.
Side note: To make our Ollama run locally, we need to write the following command in the terminal:

ollama serve

import { toFile } from 'openai';
// new imports
import { ollama } from 'ollama-ai-provider';
import { generateText } from 'ai';

const openai = getOpenai();

export async function POST(req: Request) {
        ...
        const audioFile = await toFile(audioBuffer, 'audio.mp3');

        const transcription = await openai.audio.transcriptions.create({
            model: 'whisper-1',
            file: audioFile,
        });

        const { text: response } = await generateText({
            // we specify our model running locally in the background
            model: ollama('llama3.1'),
            // we can set initial instructions to our model
            system: 'You know a lot about video games',
            // the text we want the model to interpret
            prompt: transcription.text,
        });
        ...
}

Finally, we have our last model: TTS from OpenAI. We want to reply to our user with audio, so this model will be really helpful. It will turn our text into speech:

import { toFile } from 'openai';
// new imports
import { ollama } from 'ollama-ai-provider';
import { generateText } from 'ai';

const openai = getOpenai();

export async function POST(req: Request) {
        ...
        const audioFile = await toFile(audioBuffer, 'audio.mp3');

        const transcription = await openai.audio.transcriptions.create({
            model: 'whisper-1',
            file: audioFile,
        });

        const { text: response } = await generateText({
            model: ollama('llama3.1'),
            system: 'You know a lot about video games',
            prompt: transcription.text,
        });

        const voiceResponse = await openai.audio.speech.create({
            // Specify here our tts model
            model: 'tts-1',
            // we pass in our response
            input: response,
            // We can choose a variety of different voices
            // I chose 'onyx' but you can pick from this list: <https://platform.openai.com/docs/guides/text-to-speech/quickstart>
            voice: 'onyx',
        });
        ...
}

The TTS model will turn our response into an audio file. We want to stream this audio back to the user like this:

import { toFile } from 'openai';
import { getOpenai } from '@/utils/getOpenai';
import { ollama } from 'ollama-ai-provider';
import { NextResponse } from 'next/server';
import { generateText } from 'ai';

const openai = getOpenai();

export async function POST(req: Request) {
    const { audio } = await req.json();
    const audioBuffer = Buffer.from(audio, 'base64');

    try {
        const audioFile = await toFile(audioBuffer, 'audio.mp3');

        const transcription = await openai.audio.transcriptions.create({
            model: 'whisper-1',
            file: audioFile,
        });

        const { text: response } = await generateText({
            model: ollama('llama3.1'),
            system: 'You know a lot about video games',
            prompt: transcription.text,
        });

        const voiceResponse = await openai.audio.speech.create({
            model: 'tts-1',
            input: response,
            voice: 'onyx',
        });

        // stream back our audio
        return new Response(voiceResponse.body, {
            headers: {
                 // we specify the content type         
                'Content-Type': 'audio/mpeg',
                // we indicate that this is going to be streamed in chunks of data
                'Transfer-Encoding': 'chunked',
            },
        });
    } catch (err) {
        console.error(err);
        return NextResponse.json(
            {
                err: err,
                error: 'Error converting audio',
            },
            {
                status: 500,
            }
        );
    }
}

And that’s all the whole backend code! Now, back to the frontend to finish wiring everything up.

Putting It All Together

In our useRecordVoice.tsx hook, let's create a new method that will call our API endpoint. This method will also take the response back and play to the user the audio that we are streaming from the backend.

// app/hooks/useRecordVoice.tsx
...
export function useRecordVoice() {
// new state to track when our server is loading the response for us
const [loading, setLoading] = useState(false);

async function getResponse(audioBlob: Blob) {
  // We transform our audio to base64 to send it to the endpoint
  const audioBase64 = await transformBlobToBase64(audioBlob);

  try {
            setLoading(true);
            // Calling out "chat" endpoint
            const res = await fetch('/api/chat', {
                method: 'POST',
                // Sending our base64 audio here
                body: JSON.stringify({ audio: audioBase64 }),
                headers: {
                    'Content-Type': 'application/json',
                },
            });

            if (!res.ok) {
                throw new Error('Error getting response');
            }

      } catch (err) {
         console.error(err);
      } finally {
        setLoading(false);
      }

}

    useEffect(() => {
        if (mediaRecorder) {
            mediaRecorder.ondataavailable = (e) => {
                audioChunks.current.push(e.data);
            };

            mediaRecorder.onstop = () => {
                const audioBlob = new Blob(audioChunks.current, {
                    type: 'audio/mp3',
                });
                // we call our method here
                void getResponse(audioBlob);
                audioChunks.current = [];
            };
        }
    }, [mediaRecorder]);

...

// app/utils/transform-blob-to-base64.ts
export function transformBlobToBase64(blob: Blob): Promise<string> {
    return new Promise((resolve, reject) => {
        const reader = new FileReader();
        reader.onloadend= () => {
            resolve(reader?.result?.toString().split(',')[1] || '');
        }
        reader.onerror = reject;
        reader.readAsDataURL(blob);
    })
}

Great! Now that we’re getting our streamed response, we need to handle it and play the audio back to the user. We’ll use the AudioContext API for this. This API allows us to store the audio, decode it and play it to the user once it’s ready:

...
async function getResponse(audioBlob: Blob) {
    const audioBase64 = await transformBlobToBase64(audioBlob);

    try {
        setLoading(true);
        const res = await fetch('/api/chat', {
            method: 'POST',
            body: JSON.stringify({ audio: audioBase64 }),
            headers: {
                'Content-Type': 'application/json',
            },
        });

        if (!res.ok) {
            throw new Error('Error getting response');
        }

        // Create an instance of AudioContext
        const audioContext = new AudioContext();

        // Create a reader to read the streaming response
        const reader = res.body?.getReader();
        if (!reader) {
            throw new Error('Error getting response');
        }

        // Create a buffer source to store the audio
        const source = audioContext.createBufferSource();

        // Array to hold the audio chunks received from the backend
        let audioChunks: Uint8Array[] = [];

        // Flag to check if the audio streaming has finished
        let isDataStreamed = false;

        while (!isDataStreamed) {
            // Start reading the data
            const { value, done } = await reader.read();

            // If true, the stream has finished
            if (done) {
                isDataStreamed = true;
                break;
            }

            // Add each data chunk to our list of audio chunks
            if (value) {
                audioChunks.push(value);
            }
        }

        // Merge all buffer chunks into a single Uint8Array
        const audioBuffer = new Uint8Array(
            audioChunks.reduce(
                (acc, val) => acc.concat(Array.from(val)),
                [] as number[]
            )
        );

        // Decode the audio data and store it in our source buffer
        source.buffer = await audioContext.decodeAudioData(
            audioBuffer.buffer
        );

        // Connect the source to the audio output (speakers or headphones)
        source.connect(audioContext.destination);

        // Start playing the audio
        source.start(0);
    } catch (err) {
        console.error(err);
    } finally {
        setLoading(false);
    }
}

...

return {
    startRecording,
    stopRecording,
    isRecording,
    // Return the loading state
    loading,
};

And that's it! Now the user should hear the audio response on their device. To wrap things up, let's make our app a bit nicer by adding a little loading indicator:

// app/components/audio-recorder.tsx

'use client';
import { useRecordVoice } from '@/hooks/useRecordVoice';

export default function AudioRecorder() {
    const { isRecording, stopRecording, startRecording, loading } =
        useRecordVoice();
    async function handleClick() {
        if (isRecording) {
            stopRecording();
        } else {
            await startRecording();
        }
    }

    // New condition
    if (loading) {
        return <div>Loading...</div>;
    }

    return (
        <div>
            <button
                onClick={handleClick}
                className={`bg-blue-500 text-white px-4 py-2 rounded shadow-md hover:bg-blue-400 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:ring-offset-2 focus:ring-offset-white transition duration-300 ease-in-out absolute top-1/2 left-1/2 -translate-x-1/2 -translate-y-1/2`}
            >
                {isRecording ? 'Stop Recording' : 'Start Recording'}
            </button>
        </div>
    );
}

Conclusion

In this blog post, we saw how combining multiple AI models can help us achieve our goals. We learned to run AI models like Llama 3.1 locally and use them in our Next.js app. We also discovered how to send audio to these models and stream back a response, playing the audio back to the user.

This is just one of many ways you can use AI—the possibilities are endless. AI models are amazing tools that let us create things that were once hard to achieve with such quality. Thanks for reading; now, it’s your turn to build something amazing with AI!

You can find the complete demo on GitHub: AI Assistant with Whisper TTS and Ollama using Next.js

How to Run End-to-End Tests on Vercel Preview Deployments

This Dot Media — Mon, 23 Sep 2024 08:18:34 +0000

How to Run End-to-End Tests on Vercel Preview Deployments

End-to-end (E2E) tests are an essential part of modern web development. They simulate real user interactions and ensure your application works as expected in a live environment. When you're working with platforms like Vercel, which provide seamless deployment experiences, running E2E tests on preview deployments makes sense to catch any issues before merging your changes into the main branch.

However, running E2E tests on preview deployments can be challenging as if the deployment isn’t ready when the tests start running, you’ll get errors when they should have succeeded.

The Challenge: Timing Your E2E Tests

Imagine you're working on a feature and pushing your changes to a branch. Vercel starts deploying the preview, and once that's done, you want to run your E2E tests automatically. But if the deployment isn't ready when the tests start, they might fail, and you'll be left wondering if the issue is with your code or the deployment process.

Github Actions allow us to leverage a combination of actions that work together to ensure that your E2E tests only start once the Vercel deployment is ready.

The Solution: Combining GitHub Actions for Seamless Testing

To solve this problem, we can use two GitHub Actions in tandem:

vercel-preview-url: This action retrieves the preview URL of the Vercel deployment. It runs on push and pull request events, ensuring you get the exact URL of your deployment, which can then be used for further tests or other integrations.
github-action-await-vercel: This action waits until the Vercel deployment is marked as "READY". It continuously checks the deployment status, ensuring your tests only run once the deployment is fully prepared.

jobs:
  e2e-tests:
    runs-on: ubuntu-latest
    steps:
      # Step 1: Retrieve the Vercel Preview URL
      - name: vercel-preview-url
        uses: zentered/vercel-preview-url@v1.1.9
        if: github.event_name != 'pull_request'
        id: vercel_preview_url
        env:
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
          GITHUB_REF: "main"
          GITHUB_REPOSITORY: "your-repo/your-project"
        with:
          vercel_project_id: ${{ secrets.VERCEL_PROJECT_ID }}

      # Step 2: Wait for the Vercel deployment to be ready
      - uses: UnlyEd/github-action-await-vercel@v1
        id: await-vercel
        if: github.event_name != 'pull_request'
        env:
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
        with:
          deployment-url: ${{ steps.vercel_preview_url.outputs.preview_url }}
          timeout: 420
          poll-interval: 15

      # Step 3: Run your end-to-end tests
      - name: Run E2E Tests
        run: npm run test:e2e

Breaking Down the Workflow

Fetch the Preview URL: The vercel-preview-url action first retrieves the URL of the Vercel deployment. This URL is unique to the deployment, and we need to know it to run our E2E tests against the correct environment. This step ensures that we have the right URL before proceeding to the next steps.
Await Deployment Readiness: The github-action-await-vercel action waits for the deployment to be fully ready. It checks the deployment status at intervals (e.g., every 15 seconds) and only proceeds once the deployment is marked as "READY." This step ensures that your E2E tests don't run prematurely, preventing false failures.
Run E2E Tests: Once the deployment is ready, your E2E tests are executed against the live preview. By this point, you can be confident that the environment is fully set up, and any failures will likely be due to actual issues in the code rather than deployment timing.

Why This Workflow Matters

This workflow is essential for teams that rely on automated testing as part of their CI/CD pipelines. By waiting for the Vercel deployment to be fully ready, you minimize the risk of flaky tests that fail due to timing issues rather than code problems. This approach saves time and effort, as developers can focus on fixing real bugs rather than troubleshooting deployment issues.

Moreover, this setup is flexible and can be adapted to various project needs. Whether you're running tests on a simple static site or a complex application, ensuring that your deployment is ready before running tests can dramatically improve the reliability of your CI/CD pipeline.

Conclusion

In modern web development, ensuring the reliability of your CI/CD pipeline is crucial. By leveraging GitHub Actions like vercel-preview-url and github-action-await-vercel, you can confidently run E2E tests on Vercel preview deployments.

However, remember that the Vercel deployment can take some time to deploy, especially for larger projects, so use this approach wisely and ensure you only run it when necessary.

How to Truncate Strings Easily with CSS

This Dot Media — Tue, 17 Sep 2024 11:29:41 +0000

You'll often need to truncate text when working with user interfaces, especially when displaying content within a limited space. CSS provides a straightforward way to handle this scenario, ensuring that long text strings are cut off gracefully without affecting the overall layout.

CSS Truncation Techniques

Single-Line Truncation

If you want to truncate a single line of text, CSS provides a simple solution. The key properties to use here are overflow, white-space, and text-overflow.

.truncate {
  white-space: nowrap; /* Prevent the text from wrapping to the next line */
  overflow: hidden; /* Ensure content is clipped within the container */
  text-overflow: ellipsis; /* Add ellipsis (…) when the text is truncated */
  width: 200px; /* Adjust the width as needed */
}

Explanation of properties:

white-space: nowrap: This ensures the text stays on a single line, preventing wrapping.
overflow: hidden: This hides any content that overflows the container.
text-overflow: ellipsis: This adds the ellipsis (…) at the end of the truncated text.

Multi-Line Truncation

While truncating a single line of text is common, sometimes you may want to display multiple lines but still cut off the text when it exceeds a certain number of lines. You can use a combination of CSS properties such as -webkit-line-clamp along with the display and overflow properties.

.multi-line-truncate {
  display: -webkit-box;
  -webkit-line-clamp: 3; /* Limit to 3 lines */
  -webkit-box-orient: vertical;
  overflow: hidden;
  text-overflow: ellipsis;
}

Live example:

Explanation of properties:

display: -webkit-box: This is a legacy flexbox-like display property that works with the -webkit-line-clamp property.
-webkit-line-clamp: Specifies the number of lines to show before truncating.
-webkit-box-orient: vertical: Ensures the box is laid out vertically for proper multi-line truncation.
overflow: hidden: Prevents content overflow.
text-overflow: ellipsis: Adds an ellipsis after the truncated content.

Why Use CSS for Text Truncation Over JavaScript Techniques?

While it’s possible to truncate text using JavaScript, CSS is often a better choice for this task for several reasons. Let's explore why CSS-based truncation techniques are generally preferred over JavaScript.

Performance Efficiency

CSS operates directly within the browser's layout engine, meaning it doesn’t require additional processing or event handling as JavaScript does. When using JavaScript to truncate text, the script needs to run on page load (or after DOM manipulation), and sometimes, it needs to listen for events such as window resizing to adjust truncation. This can introduce unnecessary overhead, especially in complex or resource-constrained environments like mobile devices.

CSS, on the other hand, is declarative. Once applied, it allows the browser to handle text rendering without any further execution or processing. This leads to faster load times and a smoother user experience.

Simplicity and Maintainability

CSS solutions are much simpler to implement and maintain than their JavaScript counterparts. All it takes is a few lines of CSS to implement truncation. In contrast, a JavaScript solution would require you to write and maintain a function that manually trims strings, inserts ellipses, and re-adjusts the text whenever the window is resized.

Here's the JavaScript Truncation Example to compare the complexity:

JavaScript Truncation Example:

function truncateText(element, maxLength) {
  const originalText = element.textContent;
  if (originalText.length > maxLength) {
    element.textContent = originalText.substring(0, maxLength) + '...';
  }
}

const element = document.querySelector('.truncate');
truncateText(element, 50);

At the example above, we truncated the text to 50 characters which may be 1 line on large screens and 6 lines on mobile and in that case we will need to add more code to truncate it responsively. As you can see, the CSS solution we used earlier is more concise and readable, whereas the JavaScript version is more verbose and requires managing the string length manually.

Responsiveness Without Extra Code

With CSS, truncation can adapt automatically to different screen sizes and layouts. You can use relative units (like percentages or vw/vh), media queries, or flexbox/grid properties to ensure the text truncates appropriately in various contexts.

If you were using JavaScript, you’d need to write additional logic to detect changes in the viewport size and update the truncation manually. This would likely involve adding event listeners for window resize events, which can degrade performance and lead to more complex code.

CSS Example for Responsive Truncation:

.truncate {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
  max-width: 50%; /* Automatically adjusts based on screen size */
}

To achieve this in JavaScript, you’d need to add more code to handle the width adjustments dynamically, making it more complex to maintain and troubleshoot.

Separation of Concerns

CSS handles the presentation layer of your website, while JavaScript should focus on dynamic functionality or data manipulation. By keeping truncation logic within your CSS, you're adhering to the principle of separation of concerns, where each layer of your web application has a clear, well-defined role.

Using JavaScript for visual tasks like truncation mixes these concerns, making your codebase harder to maintain, debug, and scale. CSS is purpose-built for layout and visual control, and truncation is naturally a part of that domain.

Browser Support and Cross-Browser Consistency

Modern CSS properties like text-overflow and -webkit-line-clamp are widely supported across all major browsers. This means that CSS solutions for truncation are generally consistent and reliable. JavaScript solutions, on the other hand, may behave differently depending on the browser environment and require additional testing and handling for cross-browser compatibility.

While older browsers may not support specific CSS truncation techniques (e.g., multi-line truncation), fallback options (like single-line truncation) can be easily managed through CSS alone. With JavaScript, more complex logic might be required to handle such situations.

Reduced Risk of Layout Shifting

JavaScript-based text truncation risks causing layout shifting, especially during initial page loads or window resizes. The browser may need to recalculate the layout multiple times, leading to content flashing or jumpy behavior as text truncation is applied.

CSS-based truncation is applied as part of the browser’s natural rendering flow, eliminating this risk and ensuring a smoother experience for the user.

Conclusion

CSS is the optimal solution for truncating text in most cases due to its simplicity, efficiency, and responsiveness. It leverages the power of the browser’s rendering engine, avoids the overhead of JavaScript, and keeps your code clean and maintainable. While JavaScript truncation has its use cases, CSS should always be your go-to solution for truncating strings, especially in static or predictable layouts. If you like this post, check out the other CSS posts on our blog!

Quality of Life With Static Site Generator

This Dot Media — Thu, 25 Mar 2021 16:00:51 +0000

Intro

We're building a new marketing site here at Fancy Pants Inc. A totally new greenfield project within an existing organization is fun and exciting, but offers a unique set of challenges. Let's outline some of the most common scenarios and see how to tackle them head on.

For this, we're going to start with the idea of sort of a team meeting, a kind of round table discussion. We have a new site that has static content and maybe some forms.

Some of the requirements from our collective bosses: everyone needs to be able contribute, but only the director or those bestowed with the power can publish content. The other big need is to be able to see changes, updates, new material on the site and pass around an internal url to gather feedback before it ever goes live. There are a few more catches that will come up as we scaffold out this exciting new project.

Like all good sized projects, we've made some choices up front and want to tease out if they will meet our needs before writing up the work and getting started. Based on a few of the requirements outlined earlier, we'll be using Sanity content platform. Everything will hopefully go there from importing existing content, rich media, and even copy for the landing page. For our development choice and deployment, we've chosen Eleventy paired with Netlify for deploy. The idea is to make the developer experience vastly superior to our current system: to make deployment and preview of the project as seamless and transparent as possible. Let's get started.

Where do we start

When we talk about everyone in the company being able to 'contribute', what exactly do we mean? Everyone should be able to make a blog post about the latest and greatest? That sounds fine. What about changing the copy on the homepage or updating the Terms and Service fine print buried in the footer? That's a little less clear now, right? These questions raise important technical decisions about were to apply friction. We often talk about 'reducing friction' as a positive thing. We want to reduce the friction of custom checkout so that more people will buy our product or goods. There are cases, however, were we want to increase friction. We want to ensure that updating legal copy or replacing the hero image on the home page is not just a one click away. There needs to be some amount of process or intentional friction to be a sort of checks and balance.

With that in mind we'll create some simple roles within Sanity 'creator' and 'moderator'. Sanity has a great sample project and the CMS studio itself is React components all the way down, so we can customize it to great extent. We're not entirely sure what the fine grain controls will look like, so let's start broad and then we can narrow down those controls overtime.

For now, creators can create any new content that includes page updates and posts, but only moderators can actually publish that content from its draft version to production. With the content up and running, the actual site will be built leveraging Eleventy Static Site Generator, and the main reason is for its simplicity and flexibility.

In Eleventy, data is merged from multiple different sources before the template is rendered. The data is merged in what Eleventy calls the Data Cascade.

While we are only getting data from Sanity to start with, we have multiple other data sources that will need to be added. Even if that list were zero, a growing business and product will need to evolve and take on new responsibilities in the future. You'll thank your past self when you need to add Shopify or some other datasource in addition to the CMS.

We don't needs gates

Just when we are starting to get some momentum in the project, a hiccup. As we onboard different departments into adding content, there are several requests for a more fine grain approach to content permissions. Our "anyone can create" approach isn't going to fly. After some research, it's decided that Contentful has the sort of finer permissions built in that teams are looking for. Great, but what do we do with our implementation now?

A suggestion is to run git init a new project and just start over. We've spend a nontrivial mount of time working on templates and layouts in Eleventy, is it salvagable? The short answer is, yeah absolutely. Remember: our site doesn't care where the data comes from or how many places it comes from. We can wire-up Contentful as a data source, adjust the templates to any changes in the structure of the content (post.body may now be something like post.content) and then run a new build. Having this deployed on Netlify, a couple of us can work on a feature branch, deploy, and share it without slowing down the group working on the page layout, footers, or contact page!

Cache is still hard

Cache continues to be awful. Humans are not built for the level complexity Goldberg machines that deploy software. We want to keep things simple, and more importantly deterministic. We don't want deployment should not be a constant consideration when creating, improving, or trying new and inventive things within the company.

Our goal is whatever is merged into the main branch will be deployed to the production url. So let's follow those steps. A pull request is merged into main. This kicks off a build of the app on Netlify. It runs npx @11ty/eleventy, gathers up all the data sources from across a pleura of sources, and starts to build, on success Netlify points, all the incoming http requests from Fancy Pants dot com to the newly built site that our build step outputted to _site.

What if it fails? That might happen. Sooner or later it's going to happen. Will the customers of our fine establishment be forever disappointed with the HTTP 500 ERROR they witnessed? Nope. They won't even know. When a build fails, not if, the site continues to run the last successful build it has been. We can setup a web hook to send us a slack message, 'ops, looks like the build failed'. This is a very different message then: 'the software team broke production and we're losing money every minute it's down, everything is on fire!!!'.

Those messages invoke very different feelings, don't they? When you've broken a build, gone back and fixed it, then deployed again, you likely forget about it the next day. If you've ever broken production and spent endless hours trying to put it back together again, you'll never forget it.

Quality of Life

This is very much a quality of life that a system like the JamStack provides us: it's secret sauce. Things are going to go wrong, and when they do, you have the time, space, and mental where-with-all to fix it. When it fails, and it will at some point fail, it doesn't affect the product in production. Other teams internally may not even notice. This gives everyone explicit permission to ship. If that's publishing content with some cool new media, or the latest and greatest GraphQL data collection: if it fails, it's fine. The risk is so low as to be trivial to ship and to try new things. If this all sounds too good to be true, it's not, I promise. Come join us on the moon.

'What a waste of time. It's physically draining to do release engineering. There are other things we want to be doing. And it's not FE release engineering. ' ~ Jason Lengstorf

'It's not something we worry about on our team' ~ Zach Leatherman

I want to thank my guests on Build In Better, Jason Lengstorf with Netlify and Zach Leatherman, Open Source Author of Eleventy, for an amazing conversation and sharing their knowledge with me. This article would not be possible without their time and insight. Thank you. 👋

Special Thanks to the fine folks at Fancy Pants wearables and underoos 😉

Improve User Experience in Vue 3 with Suspense

This Dot Media — Wed, 24 Mar 2021 17:08:28 +0000

Introduction

When building applications that leverage the internet, it's important to remember that not every user will have the same connection speed that developers have. A developer working on a local machine isn't going to have the same experience as an end user in a coffee shop, or even at home. It is important to remember that some users may think that parts of your application are broken, simply because the internet connection isn't fast enough!

While we can't control internet speeds, we can plan accordingly and prevent users from experiencing a broken application. Luckily, Vue 3 provides a new way to handle situations like this, called Suspense. "Suspense" is a new built-in component in Vue that we can wrap around another component needing to perform an asynchronous action before it can render. The implementation of Suspense in Vue is very similar to React Suspense. If the component inside <Suspense></Suspense> has an async setup() method, then a fallback is presented to the user until it is completed.

An example of the below code can be found on CodeSandbox.

`<Suspense> Component`

Let's explore a basic example using Suspense. We will build a basic application that utilizes the Pokemon API to fetch a list of berries and display them in a dropdown. To start, we have two files, App.vue and Berries.vue:

Berries.vue

<template>
  <h1 class="text-3xl pb-2">Select a Berry</h1>
  <select v-model="selectedBerry" class="px-4 py-2 w-40 shadow">
    <option value="" disabled>Select...</option>
    <option
      v-for="berry in berries.results"
      :key="berry.url"
      :value="berry.url"
    >
      {{ berry.name }}
    </option>
  </select>
</template>

<script lang="ts">
import { defineComponent, ref } from "vue";
import useBerries from "../hooks/useBerries";

export default defineComponent({
  name: "Berries",
  async setup() {
    const selectedBerry = ref("");
    const berries = await useBerries();

    return { berries, selectedBerry };
  },
});
</script>

App.vue

<template>
  <Suspense>
    <Berries />

    <template #fallback>
      <span class="text-3xl">Picking berries...</span>
    </template>
  </Suspense>
</template>

<script lang="ts">
import { defineComponent } from "vue";
import Berries from "./components/Berries.vue";

export default defineComponent({
  name: "App",
  components: {
    Berries,
  },
});
</script>

Let's take a look at these two files.

In Berries.vue, we have an async setup() method which returns two values: selectedBerry and berries. In this example, berries is created by the custom function useBerries, but under the hood, it's a regular HTTP request to the Pokemon API for a list of berries. The exact implementation of the API request is not important to our example. These values are then referenced in the template as normal. If any of this looks confusing, I would recommend checking out this article on using "ref" and "reactive" or this article explaining the Composition API in general.

In App.vue, we import Berries.vue and register it as normal. In the template, however, we use the <Suspense> compontent. Remember it's built into Vue 3, so there's no need to register it anywhere. Within Suspense, we have the Berries component and a template with the name fallback. Until the setup method in Berries.vue returns its promise, the content within the fallback will be displayed. Once setup has returned, the default template will be rendered (in this case, the Berries component).

Let's take this a step further, and add some functionality to our app. When a user selects a berry from the dropdown, we want to request the provided URL and display the flavor of the berry. To do this, we'll add another component, BerryDetails.vue, and use Suspense within Berries.vue.

Below are the changes:

BerryDetails.vue

<template>This berry is {{ berryFlavor.flavor.name }}.</template>

<script lang="ts">
import { defineComponent } from "vue";
import useBerryFlavor from "../hooks/useBerryFlavor";

export default defineComponent({
  name: "BerryDetails",
  props: {
    url: {
      type: String,
      required: true,
    },
  },
  async setup(props) {
    const berryFlavor = await useBerryFlavor(props.url);

    return {
      berryFlavor,
    };
  },
});
</script>

Berries.vue

<template>
  <h1 class="text-3xl pb-2">Select a Berry</h1>
  <select v-model="selectedBerry" class="px-4 py-2 w-40 shadow">
    <option value="" disabled>Select...</option>
    <option
      v-for="berry in berries.results"
      :key="berry.url"
      :value="berry.url"
    >
      {{ berry.name }}
    </option>
  </select>
  <!-- Add section to display BerryDetails -->
  <div class="w-3/5 m-auto p-5">
    <Suspense v-if="selectedBerry">
      <BerryDetails :url="selectedBerry" />

      <template #fallback> Fetching berry details... </template>
    </Suspense>
  </div>

</template>

<script lang="ts">
import { defineComponent, ref } from "vue";
import useBerries from "../hooks/useBerries";
import BerryDetails from "./BerryDetails.vue";

export default defineComponent({
  name: "Berries",
  async setup() {
    const selectedBerry = ref("");
    const berries = await useBerries();

    return { berries, selectedBerry };
  },
  components: {
    BerryDetails,
  },
});
</script>

BerryDetails.vue is very straightforward - it displays a string with the flavor of the berry. It also accepts a prop of url, which is a string. This URL is passed into a custom method, useBerryFlavor (again, the implementation of making an API request is not important to our example).

Berries.vue is updated to include a Suspense block, which looks very similar to the one in App.vue. The only difference here is that we are waiting for selectedBerry to be set to a value before rendering, which makes sense; if we don't have a selected berry, we don't want to make an API request.

Error Handling

Great! Our application is up and running, and any slowness will be represented to the user so they know that the application is working. Right? Well, almost. What if one of these API requests throws an error? We need to communicate this to the user, rather than leaving the application suspended forever. In this case, Vue 3 provides us with a hook called onErrorCaptured, which we can use to capture the error and update the display. Let's take a look at our updated Berries.vue component:

Berries.vue

<template>
  <h1 class="text-3xl pb-2">Select a Berry</h1>
  <select v-model="selectedBerry" class="px-4 py-2 w-40 shadow">
    <option value="" disabled>Select...</option>
    <option
      v-for="berry in berries.results"
      :key="berry.url"
      :value="berry.url"
    >
      {{ berry.name }}
    </option>
  </select>
  <div class="w-3/5 m-auto p-5">
    <!-- Added error handling block -->
    <div v-if="error">Oh, snap! The berries are all gone!</div>
    <Suspense v-else-if="selectedBerry">
      <template #default>
        <BerryDetails :url="selectedBerry" :key="selectedBerry" />
      </template>
      <template #fallback> Fetching berry details... </template>
    </Suspense>
  </div>
</template>

<script lang="ts">
import { defineComponent, ref, onErrorCaptured, watch } from "vue";
import useBerries from "../hooks/useBerries";
import BerryDetails from "./BerryDetails.vue";

export default defineComponent({
  name: "Berries",
  async setup() {
    const selectedBerry = ref("");
    // Added error ref
    const error = ref();

    // Added onErrorCaptured lifecycle hook
    onErrorCaptured((e) => {
      error.value = e;
      return true;
    });

    // Reset error when selectedBerry is updated
    watch(selectedBerry, () => (error.value = null));

    const berries = await useBerries();

    return { berries, selectedBerry, error };
  },
  components: {
    BerryDetails,
  },
});
</script>

We did three things in this component:

We added a variable named error, which is a ref.
We added the lifecycle hook onErrorCaptured, which will trigger whenever an error is captured from a child component. In this case, if the API request fails, we will catch the error, and update our display accordingly.
We added a watch method on selectedBerry to reset the error whenever a new berry is selected.

Alternatively, this could be handled with a try/catch in BerryDetails.vue. In that case, the child component would need to handle the error, rather than let it bubble up to the parent, which is suspending render.

Conclusion

Suspense provides a built-in method to handle use cases that involve fetching data from an API, or performing some other asynchronous action. Rather than having to write custom logic, Vue 3 provides developers with the tools to build user-friendly applications and experiences. Fetching or loading data is a common task for single-page applications, and it is important that users are informed that something is happening behind the scenes. Next time you find yourself fetching data, consider whether the Suspense API is a good fit for the interface you are building.

An example of the code presented above can be found on CodeSandbox.

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 thisdotlabs.com.

This Dot Media is focused on creating an inclusive and educational web for all. We keep you up to date with advancements in the modern web through events, podcasts, and free content. To learn, visit thisdot.co.

Vue 3 Composition API - "ref" and "reactive"

This Dot Media — Tue, 23 Mar 2021 14:11:24 +0000

Introduction

With the release of Vue 3, developers now have access to the Composition API, a new way to write Vue components. This API allows features to be grouped together logically, rather than having to organize your single-file components by function. Using the Composition API can lead to more readable code, and gives the developer more flexibility when developing their applications.

The Composition API provides two different ways to store data locally in the component - “ref” and “reactive”. These two methods serve a similar role as the “data” function in the traditional Options API that is commonly used in Vue applications today. In this article, we will explore both of these new methods, and when to use them in your own application.

If you want to read more about the Composition API, you can read this article by Bilal Haidar for an overview.

You can view the code examples below in a working app on CodeSandbox by clicking this link.

Options API - `data`

If you have used Vue in the past, you have probably seen how different parts of your components are divided by function. Each single-file component has access to a number of attributes: data, computed, methods, lifecycle hooks, and so on. This is referred to as the "Options API". Below is an example application implementing local state with the Options API:

<template>
  <button @click="count++">count is: {{ count }}</button>
</template>

<script lang="ts">
import { defineComponent } from "vue";

export default defineComponent({
  name: "App",
  data() {
    return {
      count: 0
    };
  }
});
</script>

Composition API - `ref`

Now let's look at the same example as above, using the Composition API. First, we'll take a look at ref. From the Vue 3 documentation:

ref takes an inner value and returns a reactive and mutable ref object. The ref object has a single property .value that points to the inner value.

Below is our example code using ref:

<template>
  <button @click="count++">count is: {{ count }}</button>
</template>

<script lang="ts">
import { ref, defineComponent } from "vue";

export default defineComponent({
  name: "App",
  setup: () => {
    const count = ref(0);

    return { count };
  },
});
</script>

Let's take a closer look. What changed between these two examples?

Rather than using the data function to add local state, we are using the setup function. This new function replaces data, beforeCreate, and created, and is the place for utilizing the Composition API.
Like with data, setup returns an object. The contents of that object is any variable that needs to be accessible from the template. Since we want the count to be available in the template, we include it in the return object.

Before we continue to reactive, we should make one more change. Let's move the click event into its own method, rather than performing the action in the template.

<template>
  <button @click="increaseCount">count is: {{ count }}</button>
</template>

<script lang="ts">
import { ref, defineComponent } from "vue";

export default defineComponent({
  name: "App",
  setup: () => {
    const count = ref(0);

    const increaseCount = () => {
      count.value++;
    }

    return { count, increaseCount };
  },
});
</script>

Unlike in the Options API, methods are simply functions. We don't need any special syntax or Composition API methods to make them work. However, just like the count variable above, we do need to return the method from the setup function in order for it to be available in the template.

Notice that in the template, we used count++ to increase the value, but in the setup function, we use count.value. This is because in the setup function, count has a type of Ref<number>, where in the template the internal value is directly available.

Composition API - `reactive`

Now let's try out the reactive method. From the Vue 3 docs:

reactive returns a reactive copy of the object. The reactive conversion is "deep"—it affects all nested properties. In the ES2015 Proxy based implementation, the returned proxy is not equal to the original object. It is recommended to work exclusively with the reactive proxy, and avoid relying on the original object.

Here is our code example using reactive instead of ref:

<template>
  <button @click="increaseCount">count is: {{ state.count }}</button>
</template>

<script lang="ts">
import { reactive, defineComponent } from "vue";

export default defineComponent({
  name: "App",
  setup: () => {
    const state = reactive({
      count: 0
    });

    const increaseCount = () => {
      state.count++;
    }

    return { state, increaseCount };
  },
});
</script>

Within the setup function, we can use the return value of reactive very similarly to how we use the data function in the Options API. Because the object is deeply reactive, we can also make changes to it directly. So instead of count.value++, we can simply increment the value with state.value++.

When to use `ref` and `reactive`

In general, ref is useful for primitives (string, number, boolean, etc), and reactive is useful for objects and arrays. However, there are some key points to consider:

First, if you pass an object into a ref function call, it will return an object that has been passed through reactive. The below code works perfectly fine:

<template>
  <button @click="increaseCount">count is: {{ state.count }}</button>
</template>

<script lang="ts">
import { ref, defineComponent } from "vue";

export default defineComponent({
  name: "App",
  setup: () => {
    const state = ref({
      count: 0
    });

    const increaseCount = () => {
      state.value.count++;
    }

    return { state, increaseCount };
  },
});
</script>

Second, while the object returned from reactive is deeply reactive (setting any value to the object will trigger a reaction in Vue), you can still accidentally make the values non-reactive. If you try to destructure or spread the values of the object, for example, they will no longer be reactive. The below code does not work as you might expect:

<template>
  <button @click="increaseCount">count is: {{ count }}</button>
</template>

<script lang="ts">
import { reactive, defineComponent } from "vue";

export default defineComponent({
  name: "App",
  setup: () => {
    const state = reactive({
      count: 0
    });

    const increaseCount = () => {
      state.count++;
    }

    return { ...state, increaseCount };
  },
});
</script>

If you want to do something like this, Vue 3 has you covered. There are a number of functions to convert between Refs and their values. In this case, we will use the toRefs function. From the docs:

Converts a reactive object to a plain object where each property of the resulting object is a ref pointing to the corresponding property of the original object.

If we update our above code example to spread the result of toRefs, then everything works as we'd expect:

<template>
  <button @click="increaseCount">count is: {{ count }}</button>
</template>

<script lang="ts">
import { toRefs, reactive, defineComponent } from "vue";

export default defineComponent({
  name: "App",
  setup: () => {
    const state = reactive({
      count: 0
    });

    const increaseCount = () => {
      state.count++;
    }

    return { ...toRefs(state), increaseCount };
  },
});
</script>

There are other ways to combine these two functions, both with setting a value in a reactive object to its own variable with toRef or adding a ref to an object directly. ref and reactive are two parts of the solution, and you will find yourself reaching for each of them as needed.

Conclusion

The Vue 3 Composition API provides a lot of benefit to developers. By allowing features to be grouped together, rather than functions, developers can focus on what they are building, and less on fitting their code into a predetermined structure.

By leveraging the ref and reactive functions to maintain local state, developers have new tools to write more maintainable and readable code. These methods work well together, rather than one or the other, each solving a different problem.

Remember that the Composition API is optional! The existing Options API is not going anywhere, and will continue to work as expected. I would encourage you to try out the Composition API, and see how these new methods can improve your own workflow and applications.

To view the above examples in a working application, click here to view them in CodeSandbox.

Nuxt.js for Complete Beginners

This Dot Media — Mon, 22 Mar 2021 15:47:38 +0000

The Vuejs Amsterdam online conference was held at the end of February in 2021. It brought together Vue.js enthusiasts and community members from around the world. Many interesting topics were presented and covered. The focus, of course, was on Vue.js 3. In addition, the creators of Nuxt.js had the opportunity to showcase it from the current standpoint in development, to their intentions for it down the track. They even demonstrated a pre-alpha version of Nuxt.js 3, that’s based on Vue.js 3.

This article will start by briefly covering general Nuxt.js concepts, creating a new Nuxt.js app using the create-nuxt-app CLI, and finally, going through the different files and folders that Nuxt.js auto-generates for us.

Let’s start!

Nuxt.js Concepts

Nuxt.js is a web development framework that builds on top of the Vue.js framework. It allows you to use your Vue.js skills to build a more confident, structured, SEO friendly website purely in Vue.js.

Remember when you had to mess with the Vue.js SSR module and the Vue Meta module to build a SEO friendly website? On top of that, you had to install and use Vuex and Vue Router too!

Well, Nuxt.js takes care of that! No more chaotic setup and scaffolding to start a new Vue.js app. With the help of the create-nuxt-app CLI, you can scaffold a Nuxt.js app in no time.

What’s remarkable about Nuxt.js is its capacity to enforce convention over configuration. This means, you write less configuration files by sticking to a specific directory structure that makes Nuxt.js happy and saves you a ton of time!

Apps supported by Nuxt.js

Nuxt.js supports building a variety of web apps, including the following:

Server-Side Rendering (SSR)SSR apps are also known as Universal Apps. The app gets rendered on the server-side before it is sent to the client-side, and is displayed in the browser. This is the best option when working on an SEO friendly website written in Vue.js.

You can read the full documentation for the SSR apps here: SSR Apps

Single Page Apps (SPA)This is what you’ve been doing so far with Vue.js. The app is compiled into a few JS and CSS files. When the user requests the app, the files are downloaded to the client-side, and the Vue.js engine takes over rendering and displaying the app.

Static Site Generation (SSG)Nuxt.js can pre-render your app at build time. This means the entire app will be converted to simple static HTML files that can be hosted and served over a Content Delivery Network (CDN). The SSG option makes an app a legal JAMStack app.

You can read the full documentation for the Static Site Generation here: Static Site Generation.

File System Routing

Nuxt.js automatically generates all the Vue.js Routes in your app based on the folder structure inside the pages folder.

For example, consider having this folder structure:

pages/
  --| user/
  -----| index.vue
  --| index.vue

Nuxt.js automatically generates the following route configuration:

router: {
  routes: [
    {
      name: 'index',
      path: '/',
      component: 'pages/index.vue'
    },
    {
      name: 'user',
      path: '/user',
      component: 'pages/user/index.vue'
    },
  ]
}

You can read about File System Routing here: File System Routing.

Data Fetching

Inside a Nuxt.js app, you can still use the old techniques you kmow when developing Vue.js apps. However, we have a new player here! Server-side rendering. Nuxt.js provides a new set of data-hooks that you can implement so that Nuxt.js can prefetch data when generating the app at the server-side.

Here are two data-hooks offered by Nuxt.js:

fetch() hookThis hook was introduced with Nuxt.js 2.12+ release. It can be used inside Vue.js components stored in the pages folder and components folder.

asyncData() hookThis hook has been around for a while now, and can be used only inside the Vue.js components stored in the pages folder.

You can read more about Data Fetching hooks here: Data Fetching.

Meta Tags and SEO

Nuxt.js makes it so intuitive to add SEO support to your SSR app. You can add Metadata to your app at two different levels:

Globally using the nuxt.config.js file
Locally inside a Nuxt.js Page

You can read about Meta Tags and SEO hooks here: Meta Tags and SEO.

Create our first Nuxt.js app

Let’s use the create-nuxt-app CLI, and create our first Nuxt.js app!

Before you start, you want to make sure you have all the perquisites required before you can install and run the CLI.

For this article, I am going to use npx. However, you can also use npm, or feel free to use yarn.

Step 0

Start by running the following command:

npx create-nuxt-app my-first-nuxt

This command uses the create-nuxt-app tool, and specifies the name of the project- in this case my-first-nuxt-app.

The CLI will ask you a few questions that are important to scaffold the new Nuxt.js app based on your own preferences and decisions. Here’s what to expect.

Step 1

First, let’s confirm the project name as shown in the Figure 1. Give the app a name and hit Enter.

_ Figure 1 : Specify project name_

Step 2

You’ve got to choose whether you want to develop your app with TypeScript or JavaScript. I will select JavaScript as shown in Figure 2.

_ Figure 2 : Programming language_

Step 3

Next, you need to choose between Npm or Yarn. I will select Npm as shown in Figure 3.

_ Figure 3 : Package manager_

Step 4

In this step, you’ve got to select the UI framework you are going to use in the app. I will select Tailwind CSS as shown in Figure 4. Even if you skip this step, you can add any UI framework you want later.

_ Figure 4 : UI framework_

Step 5

Nuxt.js offers a set of modules that you can use right away in your apps. For this app, I will pick the Axios module. Figure 5 shows the selection.

_ Figure 5 : Nuxt.js modules_

Step 6

The CLI makes it super intuitive to integrate linters in your app. I will pick up both ESLint and Prettier. Figure 6 shows the selection.

_ Figure 6 : Linting tools_

Step 7

Now it’s time to select a testing framework. For the sake of this article, I will select None. Feel free to add any. Figure 7 shows the selection.

_ Figure 7 : Testing framework_

Step 8

By default, Nuxt.js supports two rendering modes. SSR/SSG and SPA. I will pick SSR/SSG to take advantage of the Server-side rendering. Figure 8 shows the selection.

_ Figure 8 : Rendering mode_

Step 9

The deployment target depends on our selection in Step 8. In this case, we have two options to select from. Server (using a Node.js server hosting) or Static (CDN/JAMStack hosting). I will select the Server deployment target as shown in Figure 9.

_ Figure 9 : Deployment target_

Step 10

For the development tools, I will keep it simple and select the jsconfig.json option as shown in Figure 10.

_ Figure 10 : Development tools_

Step 11

I won’t be using any continuous integration for this app. I will simply select None as shown in Figure 11.

_ Figure 11 : Continuous integration_

Step 12

Finally, the CLI asks whether you want to use any version control system. A version control system is always recommended when doing any kind of development. I will select Git as shown in Figure 12.

_ Figure 12 : Version control system_

These twelve questions are enough for the CLI to start scaffolding and generating your app based on your preferences. It takes a few seconds to have everything ready for you.

If all goes well, you should see the following as in Figure 13.

_ Figure 13 : create-nuxt-app new app instructions_

The CLI gives you instructions on how to run and build the app.

Step 13

Let’s run the app by following the steps highlighted in Figure 13. Run the following commands:

cd my-first-nuxt
npm run dev

The CLI compiles both the client and server parts of the app and starts the Node.js server on port 3000 as shown in Figure 14.

_ Figure 14 : App is running_

Step 14

Open a browser instance and navigate to the URL http://localhost:3000/ and you should see the default Nuxt.js app rendering. Figure 15 shows the app running in a browser.

_ Figure 15 : App rendering in a browser_

That’s all you need to get started on your first Nuxt.js app. Enjoy!

Nuxt.js Directory Structure

Let’s quickly go through the different folders the CLI generated for us. I will start by opening the new app inside Visual Studio Code. Figure 16 shows the app open inside the editor.

_ Figure 16 : App folders and files_

Let’s go through each folder, and explain their roles briefly.

.nuxt

The .nuxt folder is (re-)generated by the CLI every time you run or build the app. It has all the automatically generated files that Nuxt.js uses to run your app.

You can read more about the .nuxt folder here: .nuxt.

assets

The assets folder contains all of your uncompiled files such as Sass files, images, or font files. Nuxt.js makes use of Webpack to load all the files inside this folder.

You can read more about the assets folder here: assets.

components

This folder holds all of your Vue.js components. Nuxt.js components are not different from any other Vue.js component.

Read more about the components folder here: components.

layouts

This folder contains all of your layout components. These are Vue.js components with placeholders for content. At run time, the component and the layout it uses get merged together into a single component. Layouts in Nuxt.js allows you to define fixed UI sections in your app instead of having to repeat things over and over.

You can read more about the layouts folder here: layouts.

pages

This folder also holds Vue.js components. It is unique because Nuxt.js converts this folder structure (components with sub-folders) into actual Vue.js Routes.

You can read about the pages folder here: pages.

plugins

This folder contains global JavaScript functions that you want to run before Nuxt.js instantiates the root Vue.js app. These functions are called Plugins. They can take multiple forms. For instance, you create a Nuxt.js Plugin to load a Vue.js Plugin to your app. You can also install, and make use of a third-party Nuxt.js Plugin.

You can read more about the plugins folder here: plugins.

static

The name of this folder says it all! This folder is directly mapped to the server root. You can place any file in this folder that you do not want Webpack to process. For example, you can place a favicon file, any CSS files, and many other such files.

You can read more about the static folder here: static.

store

The store folder holds all the Vuex store files. Nuxt.js comes with the Vuex module installed, but keeps it disabled. In order to enable the Vue store in your Nuxt.js app, create an index.js file inside this folder, and Nuxt.js will automatically enable it for you.

You can read more about store folder here: store.

nuxt.config.js

As I mentioned, Nuxt.js prefers convention over configuration. However, at some times you may need to tweak the configuration a little. Nuxt.js provides the nuxt.config.js file to allow for custom configuration settings on the app level.

Read more about nuxt.config file here: nuxt.config.

That’s just a quick overview of what folders are generated by the Nuxt.js CLI. There are more you can read up on. You can find all the information you need on Nuxt.js Documentation website.

Conclusion

In this article, you were introduced to Nuxt.js and took a few baby steps towards creating your first Nuxt.js app. In the coming articles, we will immerse ourselves in the Nuxt.js world, and explore this fresh and promising web development framework together.

You can follow me on Twitter to see more of my work.

Introduction to building an Angular app with Nx Workspace

This Dot Media — Thu, 18 Mar 2021 17:52:25 +0000

Introduction to building an Angular app with Nx Workspace

Nx Workspace is a tool suite designed to architect, build and manage monorepos at any scale. It has an out of the box support for multiple frontend frameworks like Angular and React as well as backend technologies including Nest, Next and Express. In this article, we will focus on building a workspace for an Angular-based project.

Monorepo fundamentals

The most basic definition of a monorepo is that it is a single repository that consists of multiple applications and libraries. This all is accompanied by a set of tooling which enables to work with those projects. This approach has several benefits as following:

shared code - it enables to share the code across the whole company or organization. This can result in code that is more DRY as we can reuse the common patterns, components, and types. This enables to share the logic between frontend and backend as well.
atomic changes - without the monorepo approach whenever we need to make a change that will affect multiple projects we might need to coordinate those changes across multiple repositories and possibly by multiple teams. Ie. API change might need to be reflected both on a server app and a client app. With monorepo all of those changes can be applied in one commit on one repository which greatly limits the coordination efforts necessary
developer mobility - with a monorepo approach we get one, consistent way of performing similar tasks even when using multiple technologies. The developers can now contribute to other team's projects and make sure that their changes are safe across the whole organization.
single set of dependencies - By using a single repository with one set of dependencies we make sure that our whole codebase depends on one single version of the given dependency. This way there are no version conflicts between libraries. It is also less likely that the less used part of the repository will be left with an obsolete dependency because it will be updated along the way when other parts of the repository do this update.

Create a new workspace

With all that said about the monorepo how do we actually create one using Nx Workspace and Angular? Just like with Angular CLI there is an Nx CLI that does all the heavy lifting for us. With the following command we can create a new workspace that leverages all of the aforementioned benefits of a monorepo:

npx create-nx-workspace --preset=angular

The tool will ask for a project name, stylesheet format, and linting tool. For the linting I recommend using ESLint which is a more modern tool. The CLI will also ask whether we want to use Nx Cloud in our workspace. We can opt-out from this for now as we can easily add that later on. After the command finishes, we end up with a brand new project all set up. Let's start by analyzing what has been generated for us.

Nx uses certain toolset by default:

Jest for testing (instead of Karma and Jasmine)
Cypress for e2e testing (instead of Protractor)
ESLint for linting (instead of TSLint) in case you have decided so when creating a workspace All of these are a modern tools and I recommend sticking to them as they provide very good developer's experience and are actively maintained.

The base structure that is created for us looks as following:

- apps/
  - {{appName}}
  - {{appName}}-e2e
- libs
- tools

apps/*: here go all the application projects - by default it'll be the app we created and an accompanying e2e tests app
libs/*: here go all the libraries that we create
tools/*: here we can put all the necessary tooling scripts etc. that are necessary in our project
and all the root configuration files like angular.json, config files for Jest, ESLint, Prettier etc

This whole structure is created for us so that we can focus on building the solution right from the beginning.

Migration from an existing Angular project

If you already have an existing Angular app that was build using Angular CLI you can still easily migrate to an Nx Workspace. A project that contains only a single Angular app can be migrated automatically with just one command:

ng add @nrwl/workspace

This will install all the dependencies required by Nx and create the folder structure mentioned in the previous section. It will also migrate the app into apps folder and e2e suite into apps/{{appName}}-e2e folder. Nx modifies package.json script and decorates Angular CLI so you can still use the same commands like ng build, ng serve, or npm start. It is important to remember that the version of Angular and Nx must match so that this process goes smoothly. Ie. if your project is using version 10 of Angular please make sure to use the latest 10.x.x version of Nx CLI.

In case you already have multiple projects you still can migrate with few manual steps described in the Nx docs

Create a library

One of the core ideas behind the Nx Workspace monorepo approach is to divide our code into small, manageable libraries. So by using Nx we will end up creating a library often. Luckily this is done as simple as typing one command in the terminal:

nx g @nrwl/angular:lib mylib

This will create a libs/mylib folder with the library set up so we can build, test, and use it in other libraries or applications right away. To group your libraries you can use --directory={{subfolderName}} additional parameter to specify a subfolder under which a library should be created. You don't have to worry though about choosing the perfect place for your library from the start. You can always move it around later on using @nrwl/workspace:move schematics. And you can find all the other options for generating a new Angular library in the official docs

Every library has an index.ts file at its root which should be the only access point to a library. Each part of the library that we want to be part of lib's public API should be exported from this file. Everything else is considered private to the library. This is important for maintaining the correct boundaries between libraries and applications which makes for a more well-structured code.

Affected

One of the greatest things about Nx Workspace is that it understands dependencies within the workspace. This allows for testing and linting only the projects that are affected by a given change. Nx comes with a few built-in commands for that.

npx nx affected:lint
npx nx affected:test
npx nx affected:e2e
npx nx affected:build

Those commands will run lint, test, e2e, and build targets, but only on projects that are affected and therefore it will lower the execution time by a lot in most use-cases. The commands below are equivalent to the ones above but they use more generic syntax which can be extended to different targets if necessary.

nx affected --target=lint
nx affected --target=test
nx affected --target=e2e
nx affected --target=build

For all of the commands mentioned above we can parallelize them by using --parallel flag and --maxParallel={{nr}} to cap the number of parallel tasks. There are multiple additional useful parameters that the affected task can take. Please visit the official docs for more details.

Conslusion

Working with a monorepo has a lot of advantages and Nx Workspace provides us with multiple tools to get the most of that. By using it we can speed up our development loop by being able to create atomic changes to the repository and make sure that the whole workspace is compatible with that change. All of this is done with blazing fast tooling that can be scaled to any project size we might have.

In case you have any questions you can always tweet or DM me @ktrz. I'm always happy to help!

DEV Community: This Dot Media

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

Understanding the Difference Between :focus and :focus-visible in CSS

What is the :focus Pseudo-Class?

Example Usage of :focus

What is the :focus-visible Pseudo-Class?

Example Usage of :focus-visible

Key Differences Between :focus and :focus-visible

:focus

:focus-visible

Accessibility Implications

:focus

:focus-visible

Best Practices for Using :focus and :focus-visible

Combining :focus and :focus-visible

Additional Tips

Conclusion

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 build an AI assistant with OpenAI, Vercel AI SDK, and Ollama with Next.js

Getting started

Kicking things off

Building our client logic

Setting up our Server side

Putting It All Together

Conclusion

How to Run End-to-End Tests on Vercel Preview Deployments

How to Run End-to-End Tests on Vercel Preview Deployments

The Challenge: Timing Your E2E Tests

The Solution: Combining GitHub Actions for Seamless Testing

Breaking Down the Workflow

Why This Workflow Matters

Conclusion

How to Truncate Strings Easily with CSS

CSS Truncation Techniques

Single-Line Truncation

Explanation of properties:

Multi-Line Truncation

Explanation of properties:

Why Use CSS for Text Truncation Over JavaScript Techniques?

Performance Efficiency

Simplicity and Maintainability

Responsiveness Without Extra Code

Separation of Concerns

Browser Support and Cross-Browser Consistency

Reduced Risk of Layout Shifting

Conclusion

Quality of Life With Static Site Generator

Intro

Where do we start

We don't needs gates

Cache is still hard

Quality of Life

Improve User Experience in Vue 3 with Suspense

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

What is the `:focus` Pseudo-Class?

Example Usage of `:focus`

What is the `:focus-visible` Pseudo-Class?

Example Usage of `:focus-visible`

Key Differences Between `:focus` and `:focus-visible`

`:focus`

`:focus-visible`

`:focus`

`:focus-visible`

Best Practices for Using `:focus` and `:focus-visible`

Combining `:focus` and `:focus-visible`

`<Suspense> Component`

Options API - `data`

Composition API - `ref`

Composition API - `reactive`

When to use `ref` and `reactive`