Javascript

Building Your First Application with AWS Amplify

Sep 19, 2022

8 min read

AWS (Amazon Web Services) is popular for the cloud solution it provides across the globe, in various regions with data centers.

In this article, we will be looking at a particular platform by AWS for frontend developers, AWS Amplify.

AWS Amplify is a set of tools and features that let web and mobile developers quickly and easily build full-stack applications on AWS.

This article is a summary of JavaScript Marathon: AWS for Frontend Developers with Michael Liendo. If you want a more detailed explanation of building and deploying frontend apps with AWS Amplify, I recommend you go and check out the video!

Application User Flow

Most applications need certain key features to be created for users. Let’s explore a few of them.

User Login:
- This can be created by spinning up an ExpressJS application with Authentication, and handling things like user hashing, password policy, and forgot password.
API integration:
- This is another common need as we typically need to handle user data with a backend application.
Database:
- Most applications store user information. This would be key in creating an interactive user experience in an application.

Bringing these services together can be a lot for many developers. Developers will also have to consider application scalability as the users increase.

AWS Amplify

AWS Amplify is built to specifically handle scale for frontend developers, and also provides the opportunity for an application to scale as the application and users grow. With scalability handled, this allows developers to focus on providing value for their users versus having to worry about scalability at every stage.

AWS Amplify Tools

AWS Amplify tools for building and deploying frontend applications include:

CLI: To connect frontend with AWS backend cloud resources.
UI Components: AWS UI components library is an open-source design system with cloud-connected components and primitives that simplify building accessible, responsive, and beautiful applications.
Hosting Solution: For deploying frontend applications, static sites, and server-side apps, with a CI/CD pipeline.
Amplify Studio: A GUI for UI to plug a Figma component and automatically convert it into a ReactJS component.

Walking back to how AWS will help manage the user journey we listed above and make developer lives easier, here are some of the services provided by AWS that help spin up applications with ease:

User Login: For user login, we can use Amazon Cognito, AWS’s user directory service to handle user authentication, password policies, forgot password, and more.
API: For API access, we can use AWS AppSync, a serverless GraphQL and Pub/Sub API service.
Database: for Database, we can use Amazon’s DynamoDB, which is a fully managed, serverless, key-value NoSQL database.
Storage: for assets storage, we can be use Amazon Simple Storage Service (Amazon S3).

Building a Project & Project Setup

Now that you’re familiar with a few of the services we can use to build an application easily, let’s get started and build one together!

Before we start, let’s install the AWS Amplify CLI.

Run:

npm install -g @aws-amplify/cli

This will give us access to use Amplify’s commands for our application.

The Application

We will be building a Next framework application.

This application will be a collection of pictures of Dogs.

To scaffold a Next application, run:

npx create-next-app thisdot-dogs

Now cd into the application directory.

cd thisdot-dogs

Install the packages and dependencies we will be using from AWS:

npm i @aws-amplify/ui-react aws-amplify

Now, open the project in your code editor. We will be using VS Code.

First, we will wrap the root component in an AmplifyProvider component. Open _app.js and replace the code:

import { AmplifyProvider } from '@aws-amplify/ui-react';
import '@aws-amplify/ui-react/style.css';
import '../styles/globals.css'

function MyApp({ Component, pageProps }) {
  return (
    <AmplifyProvider>
      <Component {...pageProps} />
    </AmplifyProvider>
  )
}

export default MyApp

This is to make the application aware of Amplify. We also imported the style library from the React Amplify library.

We will be using the install amplify CLI tool to initialize the Amplify configuration in our project.

To do this, run:

amplify init

You can modify the properties as well, but for this demo, we will leave it as default, and when it asks Initialize the project with the above configuration? we will choose NO.

This is because we will replace the src directory with a . directory and the build directory replace with .next directory.

If you don’t already have AWS credentials set up, Amplify will walk you through setting up new credentials.

For this demo, we will be accepting the default credentials settings provided, but we recommend you follow with the required information for your project. Check out the Documentation to learn more.

AWS will add a few cloud functions and create a configuration file in the project directory, aws-exports.js.

You can add services to your Amplify project by running the amplify add command.

For example, to add the authentication service (AWS Cognito), run:

amplify add auth

This will ask for the type of security configuration you want for the project.

Next, it asks how you want users to authenticate.

This will add authentication to your application. To test it out, let's edit the index.js file and replace the content:

import { withAuthenticator } from "@aws-amplify/ui-react"

function Home() {
  return (
    `Home`
  )
}

export default withAuthenticator(Home)

Now, run the application in dev environment:

npm run dev

Navigate to the dev localhost URL in the browser, http://localhost:3000/.

The landing URL is now authenticated, and requires a username and password to login.

The application now has full authentication with the ability to sign in:

There is a registration function and user detail fields:

There is also a forgotten password function that emails the user a code to reset the password, all from just a few lines of code:

This is a fully functioning application with authentication included locally.

To use the full authentication, we will need to push the application to AWS service.

To do that, run:

amplify push

This will list services created in the application and prompt if you want to continue with the command.

Upon accepting, it will push the application to the cloud and update the amplify-exports.js configuration file with the cloud configuration and AWS services that we enabled in our application.

Now, let's modify the _app.js to apply the Amplify configurations.

Add the Amplify and config imports as follows:

import {Amplify} from 'aws-amplify';
import config from "../amplify-exports.js";

Amplify.configure(config)

function MyApp({ Component, pageProps }) {
…

The authentication configuration handles form validation out-of-the-box including password policy and email, or phone number verification depending on what you choose.

You can view ampliy-exports.js to confirm the configuration options available for the project.

Now to add an API to the application, run:

amplify add api

For this demo, we will choose GraphQL for the API service, API key for authentication, and Amazon Cognito. Everything else will be the default.

Amplify will auto generate the GraphQL schema for the project, which you can modify to fit your use case.

Push the API updates to AWS:

amplify push

Amplify will trigger to generate code for your GraphQL API. We suggest you accept the default options.

Storage

We’ll add a storage service to our project to allow users to upload favorite dog images.

Run:

amplify add storage

You can apply default settings or modify it to fit your use case.

Building a Demo app

Now that we have prepared the project, let’s modify index.js to implement file upload for authenticated users.

import { Button, Card, Flex, Heading, Image, Text, TextField, withAuthenticator } from "@aws-amplify/ui-react"
import { API, Storage } from "aws-amplify"
import { useEffect, useState } from "react"
import { createDogs } from "../src/graphql/mutations"
import { listDogs } from "../src/graphql/queries"

function Home({ signOut }) {
  const [ dogItems, setDogItems ] = useState([])
  const handleOnSubmit = async (e) => {
    e.preventDefault()
    const picTitle = e.target.dogTitle.value
    const dogPicFile = e.target.dogPic.files[ 0 ]
    const dogPicName = dogPicFile.name

    const picData = await Storage.put(dogPicName, dogPicFile, {
      level: 'protected'
    })

    const { data } = await API.graphql({
      query: createDogs,
      variables: {
        input: {
          title: picTitle,
          imageId: dogPicName,

        }
      }
    })
    setDogItems([ data.createDogs, ...dogItems ])
  }

  useEffect(() => {
    async function fetchDogData() {
      const res = await API.graphql({ query: listDogs })

      const dogItems = await Promise.all(
        res.data.listDogs.items.map(async (dogItem) => {
          const dogUrl = await Storage.get(dogItem.imageId, { level: 'protected' })
          return {
            ...dogItem,
            dogUrl
          }
        })
      )

      setDogItems(dogItems)
    }

    fetchDogData()
  }, [])

  return (
    <Flex direction='column' alignItems='center'>
      <Button onClick={signOut}>Sign Out</Button>
      <Heading level={2}>ThisDot Dogs</Heading>
      <form onSubmit={handleOnSubmit}>
        <TextField label='Title' name="dogTitle" placeholder="Enter a dog Title" />
        <TextField type="file" name="dogPic" label="Choose a dog image" />
        <Button variation="primary" type="submit">Submit</Button>
      </form>
      <Flex wrap='wrap' justifyContent="center" >
        {dogItems.map((dogItem) => (
          <Card key={dogItem.id} variation="elevated">
            <Image height={'200px'} width="200px" src={dogItem.dogUrl} alt="hassan" objectFit="contain" />
            <Text>{dogItem.createdAt}</Text>
            <Text>{dogItem.Title}</Text>
          </Card>
        ))}
      </Flex>
    </Flex>
  )
}

export default withAuthenticator(Home)

Walk Through

First, we created a state to hold a list of dogs’ data from the API.

We then declared an async function to handle the form submission.

Using the AWS component library, we loop through the dogItems, rendering each item to display the uploaded image and details of the dog.

We imported the Storage module from amplify, passed dogPicFile to dogPicName for upload, and set the level to protected to give user access only to read and update data.

Then, we imported the API module from amplify, and the destructured data property.

Using the GraphQL code generated for us by amplify when we run amplify add api, we imported createDogs from mutations so we can post form data to the database with GraphQL. We set a new state with the return data from the database.

With React’s useEffect, we declared an async function to fetch data from the database with GraphQL query, and set the state with the returned data, and we call the fetchDogData.

To test the application, run:

npm run dev

Conclusion

In this article, we learned how to use AWS Amplify to implement authentication, integrate an API with your frontend application, connect with a database, and also how to store files in AWS storage. This can all be accomplished within a short time, and using very few lines of code.

If you want a more detailed explanation of the content covered in this write up, I recommend you watch the video by JavaScript Marathon: AWS for Frontend Developers with Michael Liendo on This Dot’s YouTube Channel.

What are you planning on building with AWS Amplify?

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Hassan Sani

@inidaname @inidaname

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes Introduction: Next.js, a powerful React framework, offers two essential features - Parallel Routes and Intercepting Routes - that enable developers to create highly dynamic and seamless user experiences in their applications. In this blog post, we will explore both Parallel Routes and Intercepting Routes, highlighting their functionalities, use cases, and how they can be combined to enhance application routing. What are Parallel Routes? Parallel Routes in Next.js allow the rendering of multiple pages within a shared layout. Rather than navigating to a completely separate page, Parallel Routes enable the simultaneous rendering of different pages based on certain conditions such as user roles or tab navigation. By leveraging named slots, defined using the @folder convention, multiple pages can be seamlessly integrated into a single layout, enhancing user experience and reducing code duplication. How to Use Parallel Routes: To utilize Parallel Routes in Next.js, you must define named slots for the desired pages within your application's folder structure. These slots are then passed as props to a shared parent layout component. For example, consider a social networking application where two pages, feed and notifications, must be rendered within a common layout. You can define Parallel Routes using the following structure: ` The layout component in app/layout.js will accept the @feed and @notifications slots as props and render them alongside the children prop. Here's an example of the layout component: ` It's important to note that slots do not affect the URL structure and are not considered route segments. This means the URL would be /mypage/@feed/views for a route like /mypage/views since @feed is a slot. Also, to prevent the application from rendering nothing or throwing an error, we could use the default.tsx file: ` In this example, the default.tsx file specifies the default content (or fallback) to render when none of the named slots match the current route. It acts as a catch-all for routes without a corresponding slot. Some Use Cases: *Conditional Routes:* Parallel Routes can conditionally render routes based on certain conditions, such as user roles. For example, you can render a different dashboard page for admins and users. This can be achieved by creating a layout component specific to the dashboard and checking the user role to determine which slot to render. *Tab Groups:* You can utilize Parallel Routes to create tabbed navigation within a section. This is especially useful for analytics or multi-page views. Adding a layout inside a slot allows users to navigate between different pages within that slot independently. *Loading and Error UI:* Parallel Routes can be independently streamed, allowing you to define custom error and loading states for each route. This enables better control over the user experience by providing distinct feedback for different app sections. *Modals:* Parallel Routes can be combined with Intercepting Routes to create modals with shareable URLs, preserved context on refresh, and customized navigation behavior. By intercepting certain routes and rendering them within a modal component, you can create a seamless modal experience. Understanding Intercepting Routes: Intercepting Routes in Next.js allows you to load content from another route within the current layout without changing the URL or refreshing the page. Using the (..) Convention: Intercepting routes are defined using the (..) convention, which is similar to the relative path convention ../ but for route segments. The convention allows for matching segments on the same level (.), one level above (..), two levels above (..)(..), or from the root app directory (...). For example, to intercept the photo segment from within the feed segment, you can create a (..)photo directory. Integrating Intercepting Routes with Parallel Routes - Modals: One powerful use case for Intercepting Routes is creating modals, which can be combined with Parallel Routes to solve common challenges such as making the modal content shareable through a URL, preserving context on page refresh, and handling backward and forward navigation. Let's make an example: ` Our folder structure will be: In this example, when a user clicks on a photo within the /gallery page, the route /photo/:photoId will be intercepted and rendered within the (..)photo directory, overlaying the gallery content. This means that the photo route is only one segment level higher despite being two file-system levels higher. In the example above, the path to the photo segment can use the (..) matcher since @modal is a slot and not a segment. Common Use Cases - Beyond Modals: Intercepting Routes can also be utilized in other scenarios. Some examples include opening a login modal in a top navbar while having a dedicated /login page, or opening a shopping cart in a side modal for better accessibility or creating wizards or multi-step forms within a single page. The possibilities are endless. Conclusion Next.js Parallel and Intercepting Routes offer powerful methods for enhancing the routing capabilities of your applications. With Parallel Routes, multiple pages can be seamlessly integrated within a shared layout, simplifying navigation and enhancing user experience. By incorporating Intercepting Routes, you can create dynamic overlays like modals, enabling content from different routes to be displayed within the current layout. By leveraging these features, you can unlock exciting possibilities and take your Next.js applications to new heights of user engagement....

Apr 5, 2024

3 mins

NextJSJavaScript

JSR - The cross-platform package manager for ESM

JSR - The cross-platform package manager for ESM Move over NPM, there’s a new package manager in town. JSR is a new open-source package registry for JavaScript and TypeScript. This particular release has caught my attention, and I’m excited to explore if and where JSR fits into our overflowing ecosystem. Setting the stage The JSR website has a page called Why JSR? I want to explore the _why_ a little bit further. I think that the _why_ points to JSR potentially being the future of the JavaScript ecosystem. NPM and JavaScript modules If you’ve found yourself confused about publishing and consuming packages and modules in the modern ESM era, you’re not alone. When NodeJS was created, there was no standard for JS modules. Node introduced CommonJS modules, and NPM provided a way to publish and consume these modules in our applications. It’s been years now since ES Modules became a standard and we are still in a weird module purgatory with no clear end in sight. JSR represents a fresh start, free from the baggage of the Node and NPM ecosystems. JavaScript runtimes and interoperability New JavaScript runtimes are popping up every year. WinterCG (_Web-interoperable Runtimes Community Group)_ was started to improve interoperability for the various runtimes with some standard APIs. Node has made steps towards this goal, but it might never get all the way there and NPM is coupled pretty tightly to that ecosystem. JSR supports several runtimes (depending on the package). This is a huge opportunity for it to become the package manager for the ecosystem at large. See cross-runtime support section for more details. NPM Compatibility JSR doesn’t end up being a complete departure from NPM since it includes an NPM compatibility layer. The docs highlight some limitations and provide deeper technical details on how this piece works. The simple overview is that you can install and use packages from JSR to a Node/NPM based project. The packages will get added to your package.json and node_modules directory. About the same as any package installed from NPM. JSR Overview At a high level, JSR is very similar to NPM. You can search for packages on the website. You can publish packages to their registry, and you can download packages from it as well. We touched on the two major features that set it apart from NPM: It only supports ESModules, and it has cross-runtime support. In the rest of the article we’ll explore the essentials (package management) and also some other really great features that feel like are bringing the JS package management ecosystem up to speed with our modern workflows. Native TypeScript I have to say I’m not surprised by this feature, considering JSR was developed by the same people behind Deno (a runtime that supports TS natively). It’s a great feature. If you haven’t figured it out yet TypeScript is a big deal and doesn’t seem to be fading away anytime soon. So what exactly does TS support look like in a package manager, though? If your runtime supports TypeScript natively (like Deno) - it can consume the TS files in your package directly. For environments that don’t, it will automatically compile your code to JavaScript and package it with type declaration files (.d.ts). Pretty, stinking, cool. The docs include a page called “about slow types”. It is probably worth a read on its own ,but the TLDR is that JSR will analyze your TS code and penalize you in certain ways if you have some type code that it considers to be slow. On the page, it outlines exactly what these penalties are, as well as what it considers slow types to be. Slow types will also come into play when we get into package scoring later in the article. Packages The docs have a page dedicated to packages. It covers some important stuff like deleting packages, versioning, documentation, and publishing. We’ll touch on some of it with an emphasis on the things that are done differently or better than with NPM. jsr.json file jsr.json is a configuration file that specifies a name, version, and exports of a package. It doesn’t include a list of dependencies like you would have in a package.json file. This is a configuration file for a package to be published to JSR. JSR dependencies are defined in an import map file or a package.json file, depending on the runtime. Adding packages to a project Adding packages to your project will vary depending on your target runtime. Here’s an example of installing it for Deno and NPM using various package managers. For Deno, an import map entry is created. For NPM, it gets installed as an NPM package using the JSR NPM compatibility layer. ` If the runtime has native JSR support, you don’t need to explicitly install packages. You can important them using the jsr: scheme. ` As you can see semantic versioning is supported and works similarly to NPM. Publishing packages If you want to publish a package to JSR, there are many important rules you need to be aware of. I recommend reading “Publishing packages” before moving forward with this. The main things to note are: ESModules only, npm packages are supported, JSR packages are supported, and node APIs are supported. So there aren’t many constraints. You just need to understand how exactly to do these things. IE: how do I use NPM dependencies, how do the imports work, etc? Once you’ve got all that down, you will be ready to publish your first package to JSR 😃 Documentation JSR emphasizes quality package documentation. It’s one of the factors in their package scoring algorithm, which we will discuss shortly. The important parts of a package’s documentation include: * a README.md file * symbol documentation - functions, interfaces, classes, etc * module documentation - docs for each exported module in a package The symbol and module documentation are written using JSDoc. The JSR website generates some nice documentation based on these 3 pieces on your package page. This means you can understand a package's entire public API without ever leaving jsr.io. Browser support The cross-runtime support is amazing, but I was curious where the original JavaScript runtime fit (the browser). According to the documentation: “You can use JSR with any tool that supports ES modules, and either has native support for JSR or supports npm packages using node_modules.” Since modern web browsers support ES modules, I will count this as JSR support. From what I can tell, though, there is one caveat. To include a module on a web page, we need a URL to download it from. Can we publish our package to JSR and use it to load a module via a script tag? According to the JSR usage policy, no. The “Unacceptable use” section states: “It is not acceptable to use JSR as a CDN for serving assets directly to web applications in a browser, except for development purposes.” So, it seems that this is a no-go for now. We will probably need to wait a bit for CDN services like jsdelivr to pull packages from the JSR registry, similar to what they do with NPM currently. Other notable features We’ve covered the most important bits about package management, TS support, NPM compatibility, etc. But there are still a few unique features that add an extra bit of sparkle to JSR. Scoring We mentioned earlier that documentation plays a part in a scoring algorithm. JSR analyzes all of the packages published to its registry and assigns them a score based on certain criteria: documentation, best practices, discoverability, and compatibility. This score is shown with every package listed on the website. You can also add a shiny badge to your README if you’re particularly proud of something. It’s still early on, so it’s likely this will evolve as time goes on. It’s an interesting gimmick, at the very least! Summary I am excited to have a new cross-platform compatible package manager that only supports ESM. As useful as NPM has been all these years, it carries a lot of baggage from “the olden days”. JSR’s native TypeScript support and reliance on modern standards is a breath of fresh air. It feels like I can publish a simple package without much ceremony. I’m excited to release my first package to JSR soon :)...

Apr 12, 2024

6 mins

JSRJavaScript

How to Create Better Test Coverage Using Cypress 10

Testing is an integral part of software development, and it is important that all developers learn best testing practices. Jordan Powell, DX engineer at Cypress and Angular Google Developer Expert, has some tips to share with developers on how to write better tests using Cypress 10. In this article, we will take a look at Powell’s tips for writing end-to-end tests, component tests, and advanced testing patterns in Cypress. If you want to learn more from Jordan Powell, please check out his Advanced Cypress JS Drop training. Table of Contents - Why is Testing important? - Types of Testing - A new take on the testing pyramid - Differences between end-to-end testing and component testing - Jordan Powell’s best practices for E2E testing - Don’t use HTML Native selectors - Use Closures - Independent Test - Use Route Aliases - Setting a Global baseUrl - Jordan Powell’s Best Practices for Component Testing - Default Config Mount - Cypress Intercept - Use createOutputSpy - Jordan Powell’s Advanced Cypress Patterns - Session - Origin - Conclusion Why is Testing important? Software testing identifies issues within the application, and helps ensure that only high quality products are shipped to the user. Here are Jordan Powell’s reasons on why testing is important, and how it helps developers: Documentation: Good testing coverage will result in developers creating stronger test plans and better QA testing for new releases. Confidence: Writing good tests allows developers to build new features in confidence because the applications are working as intended. Safe Refactoring: Good test coverage leads to less refactoring down the road, and provides developers more time to work on new features. Improved UX: Good test coverage provides better UX (User Experience) for the end user because the application is working as intended. Types of Testing E2E, Integration, and Unit testing are three common methods for testing software applications. Unit Test: Unit testing serves as the foundation of the test pyramid. If you're working in a functional language, a unit will most likely be a single function. Your unit tests will call a function with different parameters and ensure that it returns the expected values. In an object-oriented language, a unit can range from a single method to an entire class. Integration test: Integration testing is where individual components of your application are tested as a group. End-to-end testing: E2E Testing is a technique that tests your app from the web browser through to the back end of your application, as well as testing integrations with third-party APIs and services. These types of tests are great at making sure your entire app is functioning as a cohesive whole. A new take on the testing pyramid In Jordan Powell’s Advanced Cypress JS Drop training, he challenges developers to rethink the traditional testing pyramid, and believes that component testing should also be included. Component Testing with Cypress 10 allows developers to test individual components quickly, regardless of its complexity. Component tests differ from end-to-end tests in that instead of visiting a URL to pull up an entire app, a component can be "mounted" and tested on its own. Differences between end-to-end testing and component testing Here are a few key differences between End-to-end and component testing: | End-to-end testing | Component testing | | ------------------------------------------------------- | ------------------------------------------------------------------------ | | The entire application and all of its layers are tested | Only the independent components are tested | | Testing can be done by developers and QA Teams | Testing is done by the developers | | Often requires a complex setup | No extra configuration for CI(Continuous Integration) environments needed | | Initialization command: cy.visit(url) | Initialization command: cy.mount() | Jordan Powell’s best practices for E2E testing Don’t use HTML Native selectors It is not good practice to use element selectors, id attributes, or class attributes when writing End-to-end tests. Using HTML Native selectors can lead to team members refactoring tests later on, or changing attributes which could affect the tests. Jordan Powell recommends using data attributes that can inform the team that this is a test attribute. When other team members need to change anything, they will be aware of the function of the attribute and what it may affect. Use Closures Jordan warns against assigned return values for Cypress assertions, and recommends using closures to access the Commands yield like this: ` Independent Test It is not good practice to combine related tests. Jordan Powell suggests that tests should be run independently from one another without sharing or relying on other test states. If test suites are related in any way, run the related properties or methods before each of the test runs, like in the code below: ` Use Route Aliases Another recommended practice is to use route aliases to guard Cypress against proceeding until an explicit condition is met. ` Setting a Global baseUrl It is bad practice to use hardcoded URL strings for the baseUrl because it will eventually fail when the environment changes. Instead, Powell recommends using a config file that holds the environment baseUrl. Jordan Powell’s Best Practices for Component Testing All of the code examples in this next section will be for Angular, but Cypress component testing works for all major Frontend JavaScript frameworks. Default Config Mount Component testing takes two parameters: the component to mount, and the object for configuration. A Custom Mount Config can boost flexibility. It ships a default mount config which you can use, but to manage multiple modules and import without adding too many boilerplate codes, it is recommended to have a custom mount config for specific instances. ` Cypress Intercept Component testing handles the individual components you are testing at a particular time, to access external API it is recommended to use cy.intercept. According to the Doc Cy.intercept can be used to passively listen for matching routes without manipulating the request or its response in any way. ` Use createOutputSpy When working with eventEmitter for components that may contain forms or other elements with events, createOutputSpy will automatically create an EventEmitter and set up the spy on it's .emit() method. ` Jordan Powell’s Advanced Cypress Patterns Session When testing for routes or components that require authentication Cypress provides cy.session which eliminates creating functions in your test to check for sessions on every call to the route or component. cy.session caches the sessions, and it will skip the login process for testing components that need the sessions on a second call. ` Origin Running tests for projects that require a visit to multiple different domains could get CORS, or a limitation of visits, due to browser environment. Cypress provides Origin to help bypass some of the browser limitations. ` Conclusion In this article, we looked at Jordan Powell’s tips for writing End-to-end tests, component tests, and advanced testing patterns in Cypress. I recommend watching the full video for Jordan Powell’s Advanced Cypress JS Drop training. Are you excited about the Cypress Component Testing? Let us know on Twitter....

Dec 19, 2022

6 mins

CypressTesting

Improving INP in React and Next.js

Improving INP in React and Next.js In one of my previous articles, I've explained what INP is, how it works, and how it may affect your website. I also promised you to follow up with more concrete advice on how to improve your INP in your favorite framework. This is the follow-up article, where I'll focus on how to improve your INP score in React and Next.js. How to prepare for INP in React and Next.js? The first thing to do is to ensure you're using the latest version of React. The React team has been working on making React more INP-friendly and has already made some improvements in the latest versions. To enhance your INP score, consider fully taking advantage of new features introduced in React 18, such as Concurrent Rendering, Automatic Batching, and Selective Hydration. However, there are also some general areas to focus on, such as SSR and SSG in Next.js, Web Workers, or optimizing your hooks and state management. Concurrent Rendering The Concurrent Mode in React uses an algorithm that breaks rendering down into so-called "fiber nodes" and schedules the renders based on their expiration and priority. This effectively allows the user to interact with the page while the rendering is still in progress. In previous React versions, all updates, such as setState calls were treated as "urgent" and once the re-render had started, there was no way to interrupt it. Concurrent Mode changes this by being able to prioritize the updates and interrupt a non-blocking state update started with startTransition. For a simple explanation of concurrency in React, you can check out Dan Abramov's explanation. As part of the Concurrent Mode, React introduced several lifecycle methods that allow you to prioritize the rendering of certain parts of your UI, such as: - useTransition hook that allows you to update the state without blocking the UI, - useDeferredValue hook that allows you to defer the rendering of certain parts of your UI, - startTransition API that, similarly to the useTransition hook lets you mark a state update as non-blocking. It lacks, however, an indication of whether it's still pending. Automatic Batching Introduced in React 18, Automatic Batching reduces the number of re-renders that happen on state changes even when they happen outside of event handlers, e.g. in a setTimeout or Promise callback. This feature comes out of the box and you don't have to do anything to enable it, and it makes a great argument for upgrading to React 18. Selective Hydration Selective Hydration allows you to take hydration off the main thread by wrapping your components in a Suspense boundary. This way, components can become interactive faster as the browser can do other work on the main thread while the hydration is happening. To fully take advantage of selective hydration, consider the following: - Prioritizing Above-the-Fold Content: Use Suspense boundaries strategically around any parts of your application that may take the server longer to deliver to ensure they don’t block critical content from becoming interactive as soon as possible. - Hydration on Interaction: Implementing hydration upon user interaction for non-critical components can drastically reduce the main thread's workload, enhancing INP. Vercel even has a small case study showing how using selective hydration improved the performance of a Next.js site. Server-Side Rendering (SSR) and Static Site Generation (SSG) in Next.js Not everything has to run client-side. Next.js excels in SSR and SSG capabilities, which can significantly impact INP by delivering content to users faster. Optimizing SSR with techniques like incremental static regeneration (ISR) or leveraging SSG for static pages ensures that users can interact with content faster, improving the perceived performance. Workers Offloading heavy computations to Web Workers can free up the main thread, enhancing the responsiveness of React and Next.js applications. This strategy is especially useful when dealing with third-party scripts. Offloading such scripts in Next.js can be easily done by specifying the "worker" strategy on your Script component. Be aware that this feature is not yet stable and does not work with the app directory, though. If you want to take things one step further, you could use Partytown, which helps you offload any resource-intensive scripts to Web Workers. It comes with a React component that you can use to wrap your third-party scripts and offload them to a Web Worker, and it's compatible with Next.js as well. Hooks and State Management State management in React applications can easily get out of hand, leading to unnecessary re-renders and effectively an increased INP. Sometimes, using a state management library like Redux or MobX can help you consolidate your state and reduce the number of re-renders. However, they are not silver bullets and can also introduce performance issues if not used properly. If you are dealing with a lot of re-renders due to prop changes, make sure you are leveraging memoization. As of now, you may need to work with useMemo and useCallback hooks to memoize your values and functions, respectively. The upcoming React 19’s Forget Compiler, however, will apparently memoize everything under the hood, making these hooks obsolete. Using memoization properly can help you reduce the number of re-renders and improve your INP. To investigate your hook dependencies and re-renders, you can leverage React Developer Tools or use this handy helper hook I found on the internet to trace your re-renders: ` Conclusion Improving INP in React and Next.js is not easy and can require much investigation and fine-tuning. Still, it's worth doing to avoid being penalized by Google in its search results and provide a better experience for your users. Adopting React 18's new features, leveraging SSR and SSG in Next.js, utilizing Web Workers, and optimizing hooks and state management can significantly boost your INP score and deliver a faster application to your users. Remember, INP is just one among many performance metrics emphasizing the need for a comprehensive approach to performance optimization...

Apr 19, 2024

5 mins

Web PerformanceReactNextJSJavaScript

Building Your First Application with AWS Amplify

Application User Flow

AWS Amplify

AWS Amplify Tools

Building a Project & Project Setup

Storage

Building a Demo app

Conclusion

Hassan Sani

You might also like

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

JSR - The cross-platform package manager for ESM

How to Create Better Test Coverage Using Cypress 10

Improving INP in React and Next.js

You might also like

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

JSR - The cross-platform package manager for ESM

How to Create Better Test Coverage Using Cypress 10

Improving INP in React and Next.js