ReactJS

Next.js Conf 2021 Highlights

Nov 18, 2021

6 min read

Given how well-presented it was, it's hard to believe that Next.js Conf 2021 was only the second edition of Vercel's Next.js Conf. Vercel is the creator of the industry-leading React and JavaScript framework for full-stack web development called Next.js. This year also marked a milestone birthday celebration for Next.js as it turned 5 years old.

Guillermo Rauch, CEO of Vercel and co-creator of Next.js, started off the conference with a keynote talk. Guillermo announced Next.js version 12, the biggest release ever. Guillermo highlighted the following features of Next.js 12.

A new Rust-based compiler

Next.js 12 uses a Rust compiler built with SWC, which stands for Speedy Web Compiler. It's an open platform for fast tooling. This compiler improves both local and production environments. This new Rust-based compiler achieves around 5 times faster builds and around 3 times faster Hot Module Replacement (or HMR).

Zero code updates are required to benefit from these improvements. Simply update your Next.js app to version 12 to begin enjoying the benefits of this new compiler.

ES Modules

Next.js 11.1 added experimental support for ES modules. In Next.js 12, ES modules are now the default. ES modules are the official, standardized module system for JavaScript. They are supported by all major browsers and Node.js. This standardized module system allows for smaller package sizes.

URL Imports

Next.js 12 includes experimental support for URL Imports. This allows developers to use any package directly via a URL. There is no install or build step required. Remote resources can be processed exactly like local dependencies.

Middleware & Edge Functions

Over the past few years, Next.js has provided tremendous support for serverless deployments, thereby eliminating the DevOps burden for developers. Next.js continued on this mission by introducing middleware and edge functions on Vercel serverless deployments.

Middleware

Next.js middleware allow developers to run code before a request is completed. The response to an incoming request can be modified by rewriting, redirecting, adding headers, or streaming HTML. This allows middleware to be used for things like authentication, feature flags, A/B testing, logging, server-side analytics, and more.

Next.js middleware provide the same flexibility on serverless platforms that is available with traditional web servers. Next.js middleware support Web APIs like fetch and they work out of the box in Next.js 12, or deployed as edge functions on Vercel.

Edge functions

Edge functions allow developers to run code close to their users. Vercel now supports edge functions for all users on their platform. It's important to note that other hosting providers can also be configured to support middleware at the edge, and not just Vercel.

Multi-region deployment is often avoided due to cost and complexity. With edge functions, server-side logic can now be moved to the Edge, close to the geographic location of the website visitor. This results in improved loading times for visitors, no matter where they visit from.

As developers, we typically serve dynamic content for visitor personalization reasons and serve static content for faster load times. However, with a Next.js middleware deployed as an edge function, dynamic content can be served at the speed of static content.

Edge functions help to solve the common issues with serverless deployments because they boot up instantly, deploy globally, and support streaming data.

The future of React

Next.js 12 brings the future of React to Next.js. It includes experimental support for React 18 and React server components. It was reassuring to hear how closely Next.js is working with the React team to prepare Next.js for React 18, server-side streaming, and React server components.

React server components

React server components allow individual components to be rendered on the server-side. It's different from Server-Side Rendering (SSR), which pre-generates the HTML of an entire web page on the server. Server-Side Rendering renders all the HTML on the page or nothing at all. With React server components, a web page can progressively update at the component level as data comes in.

With React server components, data fetching can be done at the component level. This simplifies things, because getServerSideProps and getStaticProps will no longer be needed. This aligns more closely to the React hooks model, which advocates for combining data fetching with components.

Using server components

React server components can be used in Next.js 12 with an experimental flag. To try out React server components, we can simply give any page a .server.js or .server.ts suffix. Client-side rendered components can be used within the server component. These client components will hydrate and become interactive when the server component is rendered. This can be useful for adding client-side functionality to a page, like upvoting and downvoting behaviors.

Benefits of server components

React server components require no client-side JavaScript and they improve page rendering speeds, as well as the user experience. React server components provide greater flexibility, allowing the developer to choose where a component renders, either on the client or on the server.

Granular component caching

The Next.js team showcased a new exploration that is currently underway using a new Data component that works like a React suspense boundary. This new component supports granular component caching. It's similar to Incremental Static Regeneration (ISR).

Next.js Analytics

Last year, Next.js announced Next.js Analytics to help monitor web vitals. Since then, it has seen amazing adoption, processing over 7 billion data points.

This year, Next.js announced Checks, automated performance checks that start automatically and report results when a deployment finishes.

A preview deployment is checked to ensure that there are no runtime errors and that good performance makes its way into production. This is all thanks to the end-to-end reliability checks and Web Vitals performance checks that are done.

Next.js Live

During the conference, we learned about the evolution of Next.js Live, which was presented at last year's Next.js Conf. Next.js Live provides an instant development and real-time collaboration experience for Next.js. All it takes to collaborate with Next.js Live is a link. Next.js Live makes it possible to code, chat, draw, and edit, directly from a web browser.

Next.js Live now provides new Git integrations. Next.js Live runs natively in web browsers, and now boots up instantly thanks to innovations like ES Modules and Web Assembly, which the new compiler takes advantage of.

Notable Talks

Next.js 12 Overview

Developer Experience of the Future by Lee Robinson. Learn more about the features included in Next.js 12.

Edge functions

Next.js at the Edge by Suzanne Aldrich and Lee Robinson. Learn more about Edge functions with Next.js and Vercel.

Edge Functions Explained by Kelsey Hightower and Lee Robinson. See a demo of edge functions and learn how they're different from the traditional way of building for the web.

Next.js and databases

Next.js and Prisma: Databases in Serverless Made Easy by Daniel Norman. Learn how Prisma makes building database-driven applications with Next.js a breeze.

Streaming

Streaming in Next.js by Kara Erickson. Learn about the benefits of streaming with Next.js.

Getting Started

Getting Started with Next.js by Delba de Oliveira. Learn the fundamentals of React and Next.js.

All Talks

To view all the talks that were part of Next.js Conf 2021, visit the Vercel YouTube page.

This Dot Labs is a development consultancy that is trusted by top industry companies, including Stripe, Xero, Wikimedia, Docusign, and Twilio. This Dot takes a hands-on approach by providing tailored development strategies to help you approach your most pressing challenges with clarity and confidence. Whether it's bridging the gap between business and technology or modernizing legacy systems, you’ll find a breadth of experience and knowledge you need. Check out how This Dot Labs can empower your tech journey.

Steven Spadotto

@stevenspads @stevenspads

Understanding Vue's Reactive Data

Introduction Web development has always been about creating dynamic experiences. One of the biggest challenges developers face is managing how data changes over time and reflecting these changes in the UI promptly and accurately. This is where Vue.js, one of the most popular JavaScript frameworks, excels with its powerful reactive data system. In this article, we dig into the heart of Vue's reactivity system. We unravel how it perfectly syncs your application UI with the underlying data state, allowing for a seamless user experience. Whether new to Vue or looking to deepen your understanding, this guide will provide a clear and concise overview of Vue's reactivity, empowering you to build more efficient and responsive Vue 3 applications. So, let’s kick off and embark on this journey to decode Vue's reactive data system. What is Vue's Reactive Data? What does it mean for data to be ”'reactive”? In essence, when data is reactive, it means that every time the data changes, all parts of the UI that rely on this data automatically update to reflect these changes. This ensures that the user is always looking at the most current state of the application. At its core, Vue's Reactive Data is like a superpower for your application data. Think of it like a mirror - whatever changes you make in your data, the user interface (UI) reflects these changes instantly, like a mirror reflecting your image. This automatic update feature is what we refer to as “reactivity”. To visualize this concept, let's use an example of a simple Vue application displaying a message on the screen: `javascript import { createApp, reactive } from 'vue'; const app = createApp({ setup() { const state = reactive({ message: 'Hello Vue!' }); return { state }; } }); app.mount('#app'); ` In this application, 'message' is a piece of data that says 'Hello Vue!'. Let's say you change this message to 'Goodbye Vue!' later in your code, like when a button is clicked. `javascript state.message = 'Goodbye Vue!'; ` With Vue's reactivity, when you change your data, the UI automatically updates to 'Goodbye Vue!' instead of 'Hello Vue!'. You don't have to write extra code to make this update happen - Vue's Reactive Data system takes care of it. How does it work? Let's keep the mirror example going. Vue's Reactive Data is the mirror that reflects your data changes in the UI. But how does this mirror know when and what to reflect? That's where Vue's underlying mechanism comes into play. Vue has a behind-the-scenes mechanism that helps it stay alerted to any changes in your data. When you create a reactive data object, Vue doesn't just leave it as it is. Instead, it sends this data object through a transformation process and wraps it up in a Proxy. Proxy objects are powerful and can detect when a property is changed, updated, or deleted. Let's use our previous example: `javascript import { createApp, reactive } from 'vue'; const app = createApp({ setup() { const state = reactive({ message: 'Hello Vue!' }); return { state }; } }); app.mount('#app'); ` Consider our “message” data as a book in a library. Vue places this book (our data) within a special book cover (the Proxy). This book cover is unique - it's embedded with a tracking device that notifies Vue every time someone reads the book (accesses the data) or annotates a page (changes the data). In our example, the reactive function creates a Proxy object that wraps around our state object. When you change the 'message': `javascript state.message = 'Goodbye Vue!'; ` The Proxy notices this (like a built-in alarm going off) and alerts Vue that something has changed. Vue then updates the UI to reflect this change. Let’s look deeper into what Vue is doing for us and how it transforms our object into a Proxy object. You don't have to worry about creating or managing the Proxy; Vue handles everything. `javascript const state = reactive({ message: 'Hello Vue!' }); // What vue is doing behind the scenes: function reactive(obj) { return new Proxy(obj, { // target = state and key = message get(target, key) { track(target, key) return target[key] }, set(target, key, value) { target[key] = value // Here Vue will trigger its reactivity system to update the DOM. trigger(target, key) } }) } ` In the example above, we encapsulate our object, in this case, “state”, converting it into a Proxy object. Note that within the second argument of the Proxy, we have two methods: a getter and a setter. The getter method is straightforward: it merely returns the value, which in this instance is “state.message” equating to 'Hello Vue!' Meanwhile, the setter method comes into play when a new value is assigned, as in the case of “state.message = ‘Hey young padawan!’”. Here, “value” becomes our new 'Hey young padawan!', prompting the property to update. This action, in turn, triggers the reactivity system, which subsequently updates the DOM. Venturing Further into the Depths If you have been paying attention to our examples above, you might have noticed that inside the Proxy` method, we call the functions `track` and `trigger` to run our reactivity. Let’s try to understand a bit more about them. You see, Vue 3 reactivity data is more about Proxy objects. Let’s create a new example: `vue import { reactive, watch, computed, effect } from "vue"; const state = reactive({ showSword: false, message: "Hey young padawn!", }); function changeMessage() { state.message = "It's dangerous to go alone! Take this."; } effect(() => { if (state.message === "It's dangerous to go alone! Take this.") { state.showSword = true; } }); {{ state.message }} Click! ` In this example, when you click on the button, the message's value changes. This change triggers the effect function to run, as it's actively listening for any changes in its dependencies__. How does the effect` property know when to be called? Vue 3 has three main functions to run our reactivity: effect`, `track`, and `trigger`. The effect` function is like our supervisor. It steps in and takes action when our data changes – similar to our effect method, we will dive in more later. Next, we have the track` function. It notes down all the important data we need to keep an eye on. In our case, this data would be `state.message`. Lastly, we've got the trigger` function. This one is like our alarm bell. It alerts the `effect` function whenever our important data (the stuff `track` is keeping an eye on) changes. In this way, trigger`, `track`, and `effect` work together to keep our Vue application reacting smoothly to changes in data. Let’s go back to them: `javascript function reactive(obj) { return new Proxy(obj, { get(target, key) { // target = state & key = message track(target, key) // keep an eye for this return target[key] }, set(target, key, value) { target[key] = value trigger(target, key) // trigger the effects! } }) } ` Tracking (Dependency Collection) Tracking is the process of registering dependencies between reactive objects and the effects that depend on them. When a reactive property is read, it's "tracked" as a dependency of the current running effect. When we execute track()`, we essentially store our effects in a Set object. But what exactly is an "effect"? If we revisit our previous example, we see that the effect method must be run whenever any property changes. This action — running the effect method in response to property changes — is what we refer to as an "Effect"! (computed property, watcher, etc.) > Note: We'll outline a basic, high-level overview of what might happen under the hood. Please note that the actual implementation is more complex and optimized, but this should give you an idea of how it works. Let’s see how it works! In our example, we have the following reactive object: `javascript const state = reactive({ showSword: false, message: "Hey young padawn!", }); // which is transformed under the hood to: function reactive(obj) { return new Proxy(obj, { get(target, key) { // target = state | key = message track(target, key) // keep an eye for this return target[key] }, set(target, key, value) { target[key] = value trigger(target, key) // trigger the effects! } }) } ` We need a way to reference the reactive object with its effects. For that, we use a WeakMap. Which type is going to look something like this: `typescript WeakMap>> ` We are using a WeakMap to set our object state as the target (or key). In the Vue code, they call this object `targetMap`. Within this targetMap` object, our value is an object named `depMap` of Map type. Here, the keys represent our properties (in our case, that would be `message` and `showSword`), and the values correspond to their effects – remember, they are stored in a Set that in Vue 3 we refer to as `dep`. Huh… It might seem a bit complex, right? Let's make it more straightforward with a visual example: With the above explained, let’s see what this Track` method kind of looks like and how it uses this `targetMap`. This method essentially is doing something like this: `javascript let activeEffect; // we will see more of this later function track(target, key) { if (activeEffect) { // depsMap` maps targets to their keys and dependent effects let depsMap = targetMap.get(target); // If we don't have a depsMap for this target in our targetMap`, create one. if (!depsMap) { depsMap = new Map(); targetMap.set(target, depsMap); } let dep = depsMap.get(key); if (!dep) { // If we don't have a set of effects for this key in our depsMap`, create one. dep = new Set(); depsMap.set(key, dep); } // Add the current effect as a dependency dep.add(activeEffect); } } ` At this point, you have to be wondering, how does Vue 3 know what activeEffect` should run? Vue 3 keeps track of the currently running effect by using a global variable. When an effect is executed, Vue temporarily stores a reference to it in this global variable, allowing the track` function to access the currently running effect and associate it with the accessed reactive property. This global variable is called inside Vue as `activeEffect`. Vue 3 knows which effect is assigned to this global variable by wrapping the effects functions in a method that invokes the effect whenever a dependency changes. And yes, you guessed, that method is our effect` method. `javascript effect(() => { if (state.message === "It's dangerous to go alone! Take this.") { state.showSword = true; } }); ` This method behind the scenes is doing something similar to this: `javascript function effect(update) { //the function we are passing in const effectMethod = () => { // Assign the effect as our activeEffect` activeEffect = effectMethod // Runs the actual method, also triggering the get` trap inside our proxy update(); // Clean the activeEffect after our Effect has finished activeEffect = null } effectMethod() } ` The handling of activeEffect` within Vue's reactivity system is a dance of careful timing, scoping, and context preservation. Let’s go step by step on how this is working all together. When we run our `Effect` method for the first time, we call the `get` trap of the Proxy. `javascript function effect(update) const effectMethod = () => { // Storing our active effect activeEffect = effectMethod // Running the effect update() ... } ... } effect(() => { // we call the the get` trap when getting our `state.message` if (state.message === "It's dangerous to go alone! Take this.") { state.showSword = true; } }); ` When running the get` trap, we have our `activeEffect` so we can store it as a dependency. `javascript function reactive(obj) { return new Proxy(obj, { // Gets called when our effect runs get(target, key) { track(target, key) // Saves the effect return target[key] }, // ... (other handlers) }) } function track(target, key) { if (activeEffect) { //... rest of the code // Add the current effect as a dependency dep.add(activeEffect); } } ` This coordination ensures that when a reactive property is accessed within an effect, the track function knows which effect is responsible for that access. Trigger Method Our last method makes this Reactive system to be complete. The trigger` method looks up the dependencies for the given target and key and re-runs all dependent effects. `javascript function trigger(target, key) { const depsMap = targetMap.get(target); if (!depsMap) return; // no dependencies, no effects, no need to do anything const dep = depsMap.get(key); if (!dep) return; // no dependencies for this key, no need to do anything // all dependent effects to be re-run dep.forEach(effect => { effect() }); } ` Conclusion Diving into Vue 3's reactivity system has been like unlocking a hidden superpower in my web development toolkit, and honestly, I've had a blast learning about it. From the rudimentary elements of reactive data and instantaneous UI updates to the intricate details involving Proxies, track and trigger functions, and effects, Vue 3's reactivity is an impressively robust framework for building dynamic and responsive applications. In our journey through Vue 3's reactivity, we've uncovered how this framework ensures real-time and precise updates to the UI. We've delved into the use of Proxies to intercept and monitor variable changes and dissected the roles of track and trigger functions, along with the 'effect' method, in facilitating seamless UI updates. Along the way, we've also discovered how Vue ingeniously manages data dependencies through sophisticated data structures like WeakMaps and Sets, offering us a glimpse into its efficient approach to change detection and UI rendering. Whether you're just starting with Vue 3 or an experienced developer looking to level up, understanding this reactivity system is a game-changer. It doesn't just streamline the development process; it enables you to create more interactive, scalable, and maintainable applications. I love Vue 3, and mastering its reactivity system has been enlightening and fun. Thanks for reading, and as always, happy coding!...

Nov 22, 2023

7 mins

VueJavaScriptTypeScriptWeb Development

Testing a Fastify app with the NodeJS test runner

Introduction Node.js has shipped a built-in test runner for a couple of major versions. Since its release I haven’t heard much about it so I decided to try it out on a simple Fastify API server application that I was working on. It turns out, it’s pretty good! It’s also really nice to start testing a node application without dealing with the hassle of installing some additional dependencies and managing more configurations. Since it’s got my stamp of approval, why not write a post about it? In this post, we will hit the highlights of the testing API and write some basic but real-life tests for an API server. This server will be built with Fastify, a plugin-centric API framework. They have some good documentation on testing that should make this pretty easy. We’ll also add a SQL driver for the plugin we will test. Setup Let's set up our simple API server by creating a new project, adding our dependencies, and creating some files. Ensure you’re running node v20 or greater (Test runner is a stable API as of the 20 major releases) Overview `index.js` - node entry that initializes our Fastify app and listens for incoming http requests on port 3001 `app.js` - this file exports a function that creates and returns our Fastify application instance `sql-plugin.js` - a Fastify plugin that sets up and connects to a SQL driver and makes it available on our app instance Application Code A simple first test For our first test we will just test our servers index route. If you recall from the app.js` code above, our index route returns a 501 response for “not implemented”. In this test, we're using the createApp` function to create a new instance of our Fastify app, and then using the `inject` method from the Fastify API to make a request to the `/` route. We import our test utilities directly from the node. Notice we can pass async functions to our test to use async/await. Node’s assert API has been around for a long time, this is what we are using to make our test assertions. To run this test, we can use the following command: By default the Node.js test runner uses the TAP reporter. You can configure it using other reporters or even create your own custom reporters for it to use. Testing our SQL plugin Next, let's take a look at how to test our Fastify Postgres plugin. This one is a bit more involved and gives us an opportunity to use more of the test runner features. In this example, we are using a feature called Subtests. This simply means when nested tests inside of a top-level test. In our top-level test call, we get a test parameter t` that we call methods on in our nested test structure. In this example, we use `t.beforeEach` to create a new Fastify app instance for each test, and call the `test` method to register our nested tests. Along with `beforeEach` the other methods you might expect are also available: `afterEach`, `before`, `after`. Since we don’t want to connect to our Postgres database in our tests, we are using the available Mocking API to mock out the client. This was the API that I was most excited to see included in the Node Test Runner. After the basics, you almost always need to mock some functions, methods, or libraries in your tests. After trying this feature, it works easily and as expected, I was confident that I could get pretty far testing with the new Node.js core API’s. Since my plugin only uses the end method of the Postgres driver, it’s the only method I provide a mock function for. Our second test confirms that it gets called when our Fastify server is shutting down. Additional features A lot of other features that are common in other popular testing frameworks are also available. Test styles and methods Along with our basic test` based tests we used for our Fastify plugins - `test` also includes `skip`, `todo`, and `only` methods. They are for what you would expect based on the names, skipping or only running certain tests, and work-in-progress tests. If you prefer, you also have the option of using the describe` → `it` test syntax. They both come with the same methods as `test` and I think it really comes down to a matter of personal preference. Test coverage This might be the deal breaker for some since this feature is still experimental. As popular as test coverage reporting is, I expect this API to be finalized and become stable in an upcoming version. Since this isn’t something that’s being shipped for the end user though, I say go for it. What’s the worst that could happen really? Other CLI flags —watch` - https://nodejs.org/dist/latest-v20.x/docs/api/cli.html#--watch —test-name-pattern` - https://nodejs.org/dist/latest-v20.x/docs/api/cli.html#--test-name-pattern TypeScript support You can use a loader like you would for a regular node application to execute TypeScript files. Some popular examples are tsx` and `ts-node`. In practice, I found that this currently doesn’t work well since the test runner only looks for JS file types. After digging in I found that they added support to locate your test files via a glob string but it won’t be available until the next major version release. Conclusion The built-in test runner is a lot more comprehensive than I expected it to be. I was able to easily write some real-world tests for my application. If you don’t mind some of the features like coverage reporting being experimental, you can get pretty far without installing any additional dependencies. The biggest deal breaker on many projects at this point, in my opinion, is the lack of straightforward TypeScript support. This is the test command that I ended up with in my application: I’ll be honest, I stole this from a GitHub issue thread and I don’t know exactly how it works (but it does). If TypeScript is a requirement, maybe stick with Jest or Vitest for now 🙂...

Nov 29, 2023

5 mins

NodeJSTypeScriptTesting

Building full-stack React apps with Next.js API routes

Besides Next.js being a great front-end framework for React, it also provides a simple way to build an API for your front-end - all in the same web app! As of version 9, Next.js provides API routes that allows developers to create API endpoints using the Next.js folder structure. We can use API endpoints to build either a RESTful API, or a GraphQL API. This article will focus on a RESTful API for the sake of simplicity. With Next.js API routes, there's no longer a need to set up a back-end Node.js server to build an API. Building out two separate projects for the front-end and back-end of an application introduces its own set of challenges. Next.js simplifies this process by becoming a full-stack web framework with the addition of API routes. Building and deploying a full-stack web app has never been faster and easier! Setting up API routes API routes go in the pages/api` directory of a Next.js project. When a file or folder is added to this pages/api` folder, Next.js will create an API endpoint URL for it. Creating a `pages/api/users.ts` file will create an `/api/users` API endpoint. We can also create an `/api/users` API endpoint by creating a `pages/api/users/index.ts` file. To create a dynamic API route for a specific user, we can create a pages/api/users/[id].ts` file. This dynamic route will match requests such as `/api/users/1`. Just like the pages` folder maps its files and folders to URLs that can be visited in a web browser, the `pages/api` folder maps its files and folders to API endpoint URLs. Creating API routes To begin, let's create a new Next.js project called nextjs-full-stack`. `bash npx create-next-app full-stack-nextjs cd full-stack-nextjs ` If you prefer using TypeScript with Next.js, you can use npx create-next-app --ts` instead. For this article, we'll just use JavaScript. Notice that newly created Next.js project contains a pages/api/hello.js` file. An `/api/hello` API endpoint has already been provided for us. Let's run the project using `npm run dev` to try this API endpoint. Visit http://localhost:3000/api/hello` in a web browser. You should see the following response. `json { "name": "John Doe" } ` Understanding API routes Let's take a look at the code in the pages/api/hello.js` file. `javascript export default function handler(req, res) { res.status(200).json({ name: 'John Doe' }) } ` The default export in files that are found within the api` folder must be a function. Each function is a handler for a particular route. Asynchronous functions are also supported for cases where requests need to be made to external APIs or a database. When running the Next.js project locally, it creates a Node.js server and passes the request` and `response` objects from the server into the handler function of the requested endpoint. A dynamic route Let's create a pages/api/users/[id].js` file to create an API route for a specific user. Let's add the following code within this file. `javascript const users = [ { id: 1, name: 'John Smith' }, { id: 2, name: 'Jane Doe' }, ]; export default (req, res) => { const { query: { id } } = req; res.json({ ...users.find(user => user.id === parseInt(id)), }); } ` For the purposes of creating an example, we mocked up a list of users within the file. More realistic usage might involve querying a database for the requested user. The id` value is retrieved from the request query parameter, and then used to find the corresponding user object in the list of users. Keep in mind that the `id` from the request is a string, so we must parse it to an integer in order to perform a user lookup by id on the users list. Visit http://localhost:3000/api/users/1` in a web browser. You should see the following response. `json { "id": 1, "name": "John Smith" } ` Returning an error We can modify the user endpoint we just created to return an error when the requested user id is not found in a list of users. `javascript const users = [ { id: 1, name: 'John Smith' }, { id: 2, name: 'Jane Doe' }, ]; export default (req, res) => { const { query: { id } } = req; const user = users.find(user => user.id === parseInt(id)); if (!user) { return res.status(404).json({ status: 404, message: 'Not Found' }); } res.json({ ...user }); } ` Visit http://localhost:3000/api/users/3` in a web browser. You should see the following response since no user with an `id` of `3` exists. `json { "status": 404, "message": "Not Found" } ` Handling multiple HTTP verbs Next.js API routes allow us to support multiple HTTP verbs for the same endpoint all in one file. The HTTP verbs that we want to support for a single API endpoint are specified in the request handler function. Let's create a pages/api/users/index.js` file to create an API route for all users. We want this endpoint to support `GET` requests to get all users and `POST` requests to create users. Let's add the following code within this file. `javascript export default (req, res) => { const { method } = req; switch (method) { case 'GET': res.json({ method: 'GET', endpoint: 'Users' }); break; case 'POST': res.json({ method: 'POST', endpoint: 'Users' }); break; default: res.setHeader('Allow', ['GET', 'POST']); res.status(405).end(Method ${method} Not Allowed`); break; } } ` The req.method` value will tell us what HTTP verb was used to make the request. We can use a `switch` statement to support multiple HTTP verbs for the same endpoint. Any HTTP requests that are not `GET` or `POST`, requests will enter the `default` case and return a `405 Method Not Allowed` error. Visit http://localhost:3000/api/users` in a web browser. You should see the following response. `json { "method": "GET", "endpoint": "Users" } ` We can use an API platform like Postman or Insomnia to test POST`, `PUT`, and `DELETE` requests to this API endpoint. Testing the POST` request will return the following response. `json { "method": "POST", "endpoint": "Users" } ` Testing PUT` and `DELETE` requests will return `Method Not Allowed` errors with a `405 Method Not Allowed` response code. Using API routes from the front-end Let's create a users/[id].js` page to retrieve a specific user when the page loads, and then mimic a save profile operation when the form on the page is submitted. We will use client-side rendering within Next.js for this page. Client-side rendering is when the client makes requests for API data. The approach used in this example can also apply for pages that use server-side Rendering (SSR). `javascript import { useEffect, useState } from 'react'; import { useRouter } from 'next/router'; export default function User() { const router = useRouter(); const { id } = router.query; const [name, setName] = useState(); // GET request to get a user useEffect(() => { // wait for the useRouter hook to asynchronously get the query id if (!id) { return; } const fetchUser = async () => { const response = await fetch(/api/users/${id}`, { method: "GET", headers: { "Content-Type": "application/json" }, }); if (!response.ok) { throw new Error(Error: ${response.status}`); } const user = await response.json(); setName(user?.name); } fetchUser(); }, [id]); // POST request to mimic the saving of a user const onSubmit = async (e) => { e.preventDefault(); const response = await fetch("/api/users", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({}), }); if (!response.ok) { throw new Error(Error: ${response.status}`); } const data = await response.json(); console.log('POST: ', data); }; return ( User Form Name setName(e.target.value)} /> Submit ); } ` To retrieve a user by id` when the page loads, we can use the React `useEffect` hook with the `id` as a dependency. The browser-supported Fetch API is used to make a `GET` request to `/api/users/[id]`. Async/await is used to wait for this asynchronous request to complete. Once it is completed, the user's name is saved to the component state using `setName`, and displayed within the input text box. When the form is submitted, a POST` request is made to the `/api/users` API route that we created earlier. To keep things simple, the response of the request is then logged to the console. Conlusion Next.js makes it fast and easy to build an API for your next project. A very good use case to get started with Next.js API routes is for the implementation of CRUD operations to handle form input. API endpoints are created as Node.js serverless functions. You can build out your entire application's API with Next.js API routes. Go ahead and build something awesome with them!...

Dec 17, 2021

5 mins

NextJS

Angular 17: Continuing the Renaissance

Angular 17: A New Era November 8th marked a significant milestone in the world of Angular with the release of Angular 17. This wasn't just any ordinary update; it was a leap forward, signifying a new chapter for the popular framework. But what made this release truly stand out was the unveiling of Angular's revamped website, complete with a fresh brand identity and a new logo. This significant transformation represents the evolving nature of Angular, aligning with the modern demands of web development. To commemorate this launch, we also hosted a release afterparty, where we went deep into its new features with Minko Gechev from the Angular core team, and Google Developer Experts (GDEs) Brandon Roberts, Deborah Kurata, and Enea Jahollari. But what exactly are these notable new features in the latest version? Let's dive in and explore. The Angular Renaissance Angular has been undergoing a significant revival, often referred to as Angular's renaissance, a term coined by Sarah Drasner, the Director of Engineering at Google, earlier this year. This revival has been particularly evident in its recent versions. The Angular team has worked hard to introduce many new improvements, focusing on signal-based reactivity, hydration, server-side rendering, standalone components, and migrating to esbuild and Vite for a better and faster developer experience. This latest release, in particular, marks many of these features as production-ready. Standalone Components About a year ago, Angular began a journey toward modernity with the introduction of standalone components. This move significantly enhanced the developer experience, making Angular more contemporary and user-friendly. In Angular's context, a standalone component is a self-sufficient, reusable code unit that combines logic, data, and user interface elements. What sets these components apart is their independence from Angular's NgModule system, meaning they do not rely on it for configuration or dependencies. By setting a standalone: true` flag, you no longer need to embed your component in an NgModule and you can bootstrap directly off that component: `typescript // ./app/app.component.ts @Component({ selector: 'app', template: 'hello', standalone: true }) export class AppComponent {} // ./main.ts import { bootstrapApplication } from '@angular/platform-browser'; import { AppComponent } from './app/app.component'; bootstrapApplication(AppComponent).catch(e => console.error(e)); ` Compared to the NgModules way of adding components, as shown below, you can immediately see how standalone components make things much simpler. `ts // ./app/app.component.ts import { Component } from '@angular/core'; @Component({ selector: 'app-root', templateUrl: './app.component.html', styleUrls: ['./app.component.css'], }) export class AppComponent { title = 'CodeSandbox'; } // ./app/app.module.ts import { NgModule } from '@angular/core'; import { BrowserModule } from '@angular/platform-browser'; import { AppComponent } from './app.component'; @NgModule({ declarations: [ AppComponent ], imports: [ BrowserModule ], providers: [], bootstrap: [AppComponent] }) export class AppModule { } // .main.ts import { platformBrowserDynamic } from '@angular/platform-browser-dynamic'; import { AppModule } from './app/app.module'; platformBrowserDynamic() .bootstrapModule(AppModule) .catch((err) => console.error(err)); ` In this latest release, the Angular CLI now defaults to generating standalone components, directives, and pipes. This default setting underscores the shift towards a standalone-centric development approach in Angular. New Syntax for Enhanced Control Flow Angular 17 introduces a new syntax for control flow, replacing traditional structural directives like ngIf` or `ngFor`, which have been part of Angular since version 2. This new syntax is designed for fine-grained change detection and eventual zone-less operation when Angular completely migrates to signals. It's more streamlined and performance-efficient, making handling conditional or list content in templates easier. The @if` block replaces `*ngIf` for expressing conditional parts of the UI. `ts @if (a > b) { {{a}} is greater than {{b}} } @else if (b > a) { {{a}} is less than {{b}} } @else { {{a}} is equal to {{b}} } ` The @switch` block replaces `ngSwitch`, offering benefits such as not requiring a container element to hold the condition expression or each conditional template. It also supports template type-checking, including type narrowing within each branch. ```ts @switch (condition) { @case (caseA) { Case A. } @case (caseB) { Case B. } @default { Default case. } } ``` The @for` block replaces `*ngFor` for iteration and presents several differences compared to its structural directive predecessor, `ngFor`. For example, the tracking expression (calculating keys corresponding to object identities) is mandatory but offers better ergonomics. Additionally, it supports `@empty` blocks. `ts @for (item of items; track item.id) { {{ item.name }} } ` Defer Block for Lazy Loading Angular 17 introduces the @defer` block, a dramatically improving lazy loading of content within Angular applications. Within the `@defer` block framework, several sub-blocks are designed to elegantly manage different phases of the deferred loading process. The main content within the `@defer` block is the segment designated for lazy loading. Initially, this content is not rendered, becoming visible only when specific triggers are activated or conditions are met, and after the required dependencies have been loaded. By default, the trigger for a `@defer` block is the browser reaching an idle state. For instance, take the following block: it delays the loading of the calendar-imp` component until it comes into the viewport. Until that happens, a placeholder is shown. This placeholder displays a loading message when the `calendar-imp` component begins to load, and an error message if, for some reason, the component fails to load. `ts @defer (on viewport) { } @placeholder { Calendar placeholder } @loading { Loading calendar } @error { Error loading calendar } ` The on` keyword supports a wide a variety of other conditions, such as: - idle` (when the browser has reached an idle state) - interaction` (when the user interacts with a specified element) - hover` (when the mouse has hovered over a trigger area) - timer(x)` (triggers after a specified duration) - immediate` (triggers the deferred load immediately) The second option of configuring when deferring happens is by using the when` keyword. For example: `ts @defer (when isVisible) { } ` Server-Side Rendering (SSR) Angular 17 has made server-side rendering (SSR) much more straightforward. Now, a --ssr` option is included in the `ng new` command, removing the need for additional setup or configurations. When creating a new project with the `ng new` command, the CLI inquires if SSR should be enabled. As of version 17, the default response is set to 'No'. However, for version 18 and beyond, the plan is to enable SSR by default in newly generated applications. If you prefer to start with SSR right away, you can do so by initializing your project with the `--ssr` flag: `shell ng new --ssr ` For adding SSR to an already existing project, utilize the ng add` command of the Angular CLI: `shell ng add @angular/ssr ` Hydration In Angular 17, the process of hydration, which is essential for reviving a server-side rendered application on the client-side, has reached a stable, production-ready status. Hydration involves reusing the DOM structures rendered on the server, preserving the application's state, and transferring data retrieved from the server, among other crucial tasks. This functionality is automatically activated when server-side rendering (SSR) is used. It offers a more efficient approach than the previous method, where the server-rendered tree was completely replaced, often causing visible UI flickers. Such re-rendering can adversely affect Core Web Vitals, including Largest Contentful Paint (LCP), leading to layout shifts. By enabling hydration, Angular 17 allows for the reuse of the existing DOM, effectively preventing these flickers. Support for View Transitions The new View Transitions API, supported by some browsers, is now integrated into the Angular router. This feature, which must be activated using the withViewTransitions` function, allows for CSS-based animations during route transitions, adding a layer of visual appeal to applications. To use it, first you need to import withViewTransitions`: `ts import { provideRouter, withViewTransitions } from '@angular/router'; ` Then, you need to add it to the provideRouter` configuration: `ts bootstrapApplication(AppComponent, { providers: [ provideRouter(routes, withViewTransitions()) ] }) ` Other Notable Changes - Angular 17 has stabilized signals, initially introduced in Angular 16, providing a new method for state management in Angular apps. - Angular 17 no longer supports Node 16. The minimal Node version required is now 18.13. - TypeScript version 5.2 is the least supported version starting from this release of Angular. - The @Component` decorator now supports a `styleUrl` attribute. This allows for specifying a single stylesheet path as a string, simplifying the process of linking a component to a specific style sheet. Previously, even for a single stylesheet, an array was required under `styleUrls`. Conclusion With the launch of Angular 17, the Angular Renaissance is now in full swing. This release has garnered such positive feedback that developers are showing renewed interest in the framework and are looking forward to leveraging it in upcoming projects. However, it's important to note that it might take some time for IDEs to adapt to the new templating syntax fully. While this transition is underway, rest assured that you can still write perfectly valid code using the old templating syntax, as all the changes in Angular 17 are backward compatible. Looking ahead, the future of Angular appears brighter than ever, and we can't wait to see what the next release has in store!...

Nov 20, 2023

6 mins

AngularAngular NewTypeScriptJavaScript