React.js

What is Pair Programming?

Two Minds, One Goal: The Power of Pair Programming

Pair programming is an agile software development technique in which two developers work together on the same computer to write code. One developer, called the driver, is responsible for typing the code while the other, called the observer, review the code and makes suggestions. The two developers then switch roles, with the observer becoming the driver and the driver becoming the observer.

The story of pair programming originates from a software development company called Chrysler. In the late 1990s, Chrysler was tasked with developing a new software system for its payroll operations. The project was behind schedule and the team was struggling to make progress. In desperation, the lead programmer, Xitij Kothi, suggested an unconventional solution: pair programming. He proposed that two programmers work together on each task, with one writing code while the other reviews and offers suggestions.

The strategy worked. The project was completed on time and the quality of the software was far superior to what had been expected. Since then, pair programming has become a widely accepted practice in software development.

Pair programming can reduce the time it takes to complete a task by allowing two developers to work together more effectively. By having two developers work side-by-side, they can quickly identify and resolve problems as they occur. The navigator can also provide insights into potential issues before they become problems, helping to reduce the amount of debugging and testing that needs to be done. Additionally, pair programming enables developers to learn from each other, which can help reduce the amount of time it takes to complete a task.

Pair programming also helps to spread knowledge and skills among the team members, as each programmer learns from the other. This can be especially useful in distributed software projects, where team members may be geographically dispersed.

Story Time

John and Jane had been classmates for the past couple of months, but never really got to know each other very well. They had been assigned a project in their programming class and had decided to work together. 

John was very knowledgeable in the subject and had a good understanding of what was expected. Jane, on the other hand, had little to no experience with programming but was eager to learn. Together, they decided to use the pair programming technique.

John and Jane sat down together and discussed their project. John explained the concept of pair programming, how it works, and what their roles would be. Jane was very willing to learn and was excited to get started. 

John and Jane began writing the code for their project. John took the lead and wrote most of the code while Jane watched and asked questions. Whenever Jane found a mistake or had an idea, she would suggest it to John, who would then incorporate it into the code. 

In this way, John and Jane worked together to complete their project. By the end of it, both of them had gained a better understanding of programming and had come to know each other better. 

“Pair programming had become a regular part of John and Jane’s programming class ever since.”

Issues we can face during Pair Programming and its Solutions

One type of problem that programmers can face during pair programming is communication breakdown. This is when two programmers are unable to effectively communicate with each other due to a lack of understanding or different working styles. To overcome this issue, it is important to ensure that both programmers are on the same page before starting to program. This can be done by discussing the problem, breaking it down into small manageable parts, and discussing how to approach it. It is also important to ensure that there is an equal amount of speaking and listening between the two programmers. It is also important to be aware of any language or cultural differences that may be present and to adjust your communication accordingly.

Different abilities can be a problem during pair programming because one programmer may be more knowledgeable or experienced in a certain area than the other. This can lead to the more experienced programmer taking on a larger share of the work, leaving the less experienced programmer feeling frustrated or left out. 

To overcome this, the two partners should agree on a division of tasks based on their respective strengths. For example, if one partner is more experienced with databases, they can take the lead on designing and setting up the database structure, while the other partner focuses on developing the business logic. Both partners should aim to challenge each other and provide feedback and support to ensure that the project is completed to the highest standard. Additionally, the partners should regularly rotate tasks so that both have the opportunity to learn from each other and gain a more comprehensive understanding of the project.

Task division can be a problem during pair programming if one person takes on more responsibility than the other, leaving the other feeling like they’re not contributing as much to the project. This can lead to frustration and resentment, and can ultimately undermine the collaborative nature of pair programming. To overcome this, the two people should agree on how they will divide the tasks before they begin. 

For example, they can decide that one person will take the lead on the coding while the other focuses on debugging and testing, or that each person will take turns writing sections of code. They should also make sure to have regular check-ins to discuss progress, address any issues, and ensure that both parties are on the same page. This will help ensure that both parties feel like they’re contributing equally to the project.

Distractions can be a major problem during pair programming, as they can prevent the pair from focusing on their task and completing it in a timely manner. Distractions could include anything from phones, emails, instant messages, or conversations with other people in the same room. To overcome distractions during pair programming, both partners should agree to have their phones on silent and out of sight. If possible, they should also try to find a quiet space where they can work without interruption. Additionally, they should set aside specific times to check emails and other messages and then get back to their task. They should also set specific goals and deadlines for the task ahead of time to help keep them on track.

one person may be more accustomed to writing code with fewer lines and using terse abbreviations, while the other person may prefer longer and more descriptive lines of code. This can lead to a lot of back and forth, which can slow down the programming process. To overcome this problem, it is important to have open communication and be respectful of each other’s coding styles. The pair should discuss their preferences and try to come to an agreement on which style they should use. They should also discuss the types of coding conventions they want to follow and agree on a coding style guide. Additionally, they should take time to explain their code to each other, as this can help them better understand each other’s coding styles. Finally, they should be open to feedback and criticism and be willing to compromise.

Conclusion

The importance of pair programming lies in its ability to improve the quality of code while also reducing the time it takes to develop software.

New Features in Next.js 13

Next.js 13 has landed in a somewhat confusing way. Many remarkable things have been added; however, a good part is still Beta. Nevertheless, the Beta features give us important signals on how the future of Next.js will be shaped, so there are good reasons to keep a close eye on them, even if you’re going to wait to adopt them.

This article is part of a series of experiences about the Beta features. Let’s play with Server Components today.

Making server components the default option is arguably the boldest change made in Next.js 13. The goal of server component is to reduce the size of JS shipped to the client by keeping component code only on the server side. I.e., the rendering happens and only happens on the server side, even if the loading of the component is triggered on the client side (via client-side routing). It’s quite a big paradigm shift.

It feels quite “reasearch-y” by then, so it was shocking when seeing that Next.js is already betting its future on it now. Time flies and the fantastic engineers from React must have done some really great work.

npx create-next-app@latest --experimental-app --ts --eslint next13-server-components

Let’s have some fun playing with the project.

Server Component

The first difference noticed is that a new app folder now sits along with old friend page. They’ll save the routing changes to another article, but what’s worth mentioning for now is that every component under the app folder is, by default, a server component, meaning that it’s rendered on the server side, and its code stays on the server side.

Let’s create our very first server component now:

// app/server/page.tsx

export default function Server() {
    console.log('Server page rendering: this should only be printed on the server');
    return (
        <div>
            <h1>Server Page</h1>
            <p>My secret key: {process.env.MY_SECRET_ENV}</p>
        </div>
    );
}

If you access the /server route, whether by a fresh browser load or client-side routing, you’ll only see the line of log printed in your server console but never in the browser console. The environment variable value is fetched from the server side as well.

Looking at network traffic in the browser, you’ll see the content of the Server component is loaded via a remote call which returns an octet stream of JSON data of the render result:

Pic courtesy: medium.com

{
    ...
    "childProp": {
        "current": [
            [
                "$",
                "div",
                null,
                {
                    "children": [
                        ["$", "h1", null, { "children": "Server Page" }],
                        [
                            "$",
                            "p",
                            null,
                            {
                                "children": ["My secret key: ", "abc123"]
                            }
                        ]
                    ]
                }
            ]
        ]
    }
}

Rendering a server component is literally an API call to get serialized virtual DOM and then materialize it in the browser.

The most important thing to remember is that server components are for rendering non-interactive content, so there are no event handlers, no React hooks, and no browser-only APIs.

The most significant benefit is you can freely access any backend resource and secrets in server components. It’s safer (data don’t leak) and faster (code doesn’t leak).

Client Component

To make a client component, you’ll need to mark it so explicitly with use client:

// app/client/page.tsx

'use client';

import { useEffect } from 'react';

export default function Client() {
    console.log(
        'Client page rendering: this should only be printed on the server during ssr, and client when routing'
    );

    useEffect(() => {
        console.log('Client component rendered');
    });

    return (
        <div>
            <h1>Client Page</h1>
            {/* Uncommenting this will result in an error complaining about inconsistent
            rendering between client and server, which is very true */}
            {/* <p>My secret env: {process.env.MY_SECRET_ENV}</p> */}
        </div>
    );
}

As you may already anticipate, this gives you a similar behavior to the previous Next.js versions.

When the page is first loaded, it’s rendered by SSR, so you should see the first log in the server console; during client-side routing, both log messages will appear in the browser console.

Mix and Match

One of the biggest differences between Server Component and SSR is that SSR is at page level, while Server Component, as its name says, is at component level. This means you can mix and match server and client components in a render tree as you wish.

// A server page containing client component and nested server component

// app/mixmatch/page.tsx
import Client from './client';
import NestedServer from './nested-server';

export default function MixMatchPage() {
    console.log('MixMatchPage rendering');
    return (
        <div>
            <h1>Server Page</h1>
            <div className="box">
                <Client message="A message from server">
                    <NestedServer />
                </Client>
            </div>
        </div>
    );
}

// app/mixmatch/client.tsx
'use client';

import { useEffect } from 'react';

export default function Client({
    message,
    children,
}: {
    message: string;
    children: React.ReactNode;
}) {
    console.log('Client component rendering');

    return (
        <div>
            <h2>Client Child</h2>
            <p>Message from parent: {message}</p>
            <div className="box-red">{children}</div>
        </div>
    );
}

// app/mixmatch/nested-server.tsx

export default function NestedServer() {
    console.log('Nested server component rendering');
    return (
        <div>
            <h3>Nested Server</h3>
            <p>Nested server content</p>
        </div>
    );
}

Pic courtesy: medium.com

In a mixed scenario like this, server and client components get rendered independently, and the results are assembled by React runtime. Props passed from server components to client ones are serialized across the network (and need to be serializable).

Server Components Can Degenerate

One caution you need to take is that if a server component is directly imported into a client one, it silently degenerates into a client component.

Let’s revise the previous example slightly to observe it:

// app/degenerate/page.tsx

import Client from './client';

export default function DegeneratePage() {
    console.log('Degenerated page rendering');
    return (
        <div>
            <h1>Degenerated Page</h1>
            <div className="box-blue">
                <Client message="A message from server" />
            </div>
        </div>
    );
}

// app/degenerate/client.tsx

'use client';

import NestedServer from './nested-server';

export default function Client({ message }: { message: string }) {
    console.log('Client component rendering');

    return (
        <div>
            <h2>Client Child</h2>
            <p>Message from parent: {message}</p>
            <div className="box-blue">
                <NestedServer />
            </div>
        </div>
    );
}

// app/degenerated/nested-server.tsx

export default function NestedServer() {
    console.log('Nested server component rendering');
    return (
        <div>
            <h3>Degenerated Server</h3>
            <p>Degenerated server content</p>
        </div>
    );
}

If you check out the log, you’ll see NestedServer has “degenerated” and is now rendered by the browser.

For more information and to develop web applications using React JS, Hire React Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.

To develop custom web apps using React JS, please visit our technology page.

Content Source:

1. medium.com

What’s new in TypeScript 4.9

If you’re not familiar with TypeScript, it’s a language that builds on JavaScript by adding types and type-checking. Types can describe things like the shapes of our objects, how functions can be called, and whether a property can be null or undefined. TypeScript can check these types to make sure you’re not making mistakes in your programs so you can code with confidence. It can also power other tooling like auto-completion, go-to-definition, and refactorings in the editor. In fact, if you’ve used an editor like Visual Studio or VS Code for JavaScript, that same experience is already powered by TypeScript!

To get started with TypeScript 4.9, you can get it through NuGet, or use npm with the following command:

npm install -D typescript

You can also get editor support by

• Downloading for Visual Studio 2022/2019
• Following directions for Visual Studio Code

Here’s a quick list of what’s new in TypeScript 4.9!

• The satisfies Operator
• Unlisted Property Narrowing with the in Operator
• Auto-Accessors in Classes
• Checks For Equality on NaN
• File-Watching Now Uses File System Events
• “Remove Unused Imports” and “Sort Imports” Commands for Editors
• Go-to-Definition on return Keywords
• Performance Improvements
• Correctness Fixes and Breaking Changes

What’s New Since the Beta and RC?

Since the Release Candidate, no changes have been made to TypeScript 4.9.

TypeScript 4.9 beta originally included auto-accessors in classes, along with the performance improvements described below; however, these did not get documented in the 4.9 beta blog post.

Not originally shipped in the 4.9 beta were the new “Remove Unused Imports” and “Sort Imports” commands for editors, and new go-to-definition functionality on return keywords.

The satisfies Operator

TypeScript developers are often faced with a dilemma: they want to ensure that some expression matches some type, but also want to keep the most specific type of that expression for inference purposes.

For example:

// Each property can be a string or an RGB tuple.
const palette = {
red: [255, 0, 0],
green: "#00ff00",
bleu: [0, 0, 255]
//  ^^^^ sacrebleu - we've made a typo!
};

// We want to be able to use array methods on 'red'...
const redComponent = palette.red.at(0);

// or string methods on 'green'...
const greenNormalized = palette.green.toUpperCase();

Notice that they’ve written bleu, whereas they probably should have written blue. They could try to catch that bleu typo by using a type annotation on palette, but they’d lose the information about each property.

type Colors = "red" | "green" | "blue";

type RGB = [red: number, green: number, blue: number];

const palette: Record<Colors, string | RGB> = {
    red: [255, 0, 0],
    green: "#00ff00",
    bleu: [0, 0, 255]
//  ~~~~ The typo is now correctly detected
};

// But we now have an undesirable error here - 'palette.red' "could" be a string.
const redComponent = palette.red.at(0);

The new satisfies operator lets us validate that the type of an expression matches some type, without changing the resulting type of that expression. As an example, you could use satisfies to validate that all the properties of palette are compatible with string | number[]:

type Colors = "red" | "green" | "blue";

type RGB = [red: number, green: number, blue: number];

const palette = {
    red: [255, 0, 0],
    green: "#00ff00",
    bleu: [0, 0, 255]
//  ~~~~ The typo is now caught!
} satisfies Record<Colors, string | RGB>;

// Both of these methods are still accessible!
const redComponent = palette.red.at(0);
const greenNormalized = palette.green.toUpperCase();

satisfies can be used to catch lots of possible errors. For example, they could ensure that an object has all the keys of some type, but no more:

type Colors = "red" | "green" | "blue";

// Ensure that we have exactly the keys from 'Colors'.
const favoriteColors = {
"red": "yes",
"green": false,
"blue": "kinda",
"platypus": false
// ~~~~~~~~~~ error - "platypus" was never listed in 'Colors'.
} satisfies Record<Colors, unknown>;

// All the information about the 'red', 'green', and 'blue' properties are retained.
const g: boolean = favoriteColors.green;

Maybe they don’t care about if the property names match up somehow, but they do care about the types of each property. In that case, they can also ensure that all of an object’s property values conform to some type.

type RGB = [red: number, green: number, blue: number];

const palette = {
    red: [255, 0, 0],
    green: "#00ff00",
    blue: [0, 0]
    //    ~~~~~~ error!
} satisfies Record<string, string | RGB>;

// Information about each property is still maintained.
const redComponent = palette.red.at(0);
const greenNormalized = palette.green.toUpperCase();

Unlisted Property Narrowing with the in Operator

As developers, they often need to deal with values that aren’t fully known at runtime. In fact, they often don’t know if properties exist, whether they’re getting a response from a server or reading a configuration file. JavaScript’s in operator can check whether a property exists on an object.

Previously, TypeScript allowed us to narrow away any types that don’t explicitly list a property.

interface RGB {
red: number;
green: number;
blue: number;
}

interface HSV {
hue: number;
saturation: number;
value: number;
}

function setColor(color: RGB | HSV) {
if ("hue" in color) {
// 'color' now has the type HSV
}
// ...
}

Here, the type RGB didn’t list the hue and got narrowed away, and leaving us with the type HSV.

But what about examples where no type listed a given property? In those cases, the language didn’t help us much. Let’s take the following example in JavaScript:

function tryGetPackageName(context) {
    const packageJSON = context.packageJSON;
    // Check to see if we have an object.
    if (packageJSON && typeof packageJSON === "object") {
        // Check to see if it has a string name property.
        if ("name" in packageJSON && typeof packageJSON.name === "string") {
            return packageJSON.name;
        }
    }

    return undefined;
}

Rewriting this to canonical TypeScript would just be a matter of defining and using a type for context; however, picking a safe type like unknown for the packageJSON property would cause issues in older versions of TypeScript.

interface Context {
    packageJSON: unknown;
}

function tryGetPackageName(context: Context) {
    const packageJSON = context.packageJSON;
    // Check to see if we have an object.
    if (packageJSON && typeof packageJSON === "object") {
        // Check to see if it has a string name property.
        if ("name" in packageJSON && typeof packageJSON.name === "string") {
        //                                              ~~~~
        // error! Property 'name' does not exist on type 'object.
            return packageJSON.name;
        //                     ~~~~
        // error! Property 'name' does not exist on type 'object.
        }
    }

    return undefined;
}

This is because while the type of packageJSON was narrowed from unknown to object, the in operator strictly narrowed to types that actually defined the property being checked. As a result, the type of packageJSON remained object.

TypeScript 4.9 makes the in operator a little bit more powerful when narrowing types that don’t list the property at all. Instead of leaving them as-is, the language will intersect their types with Record<“property-key-being-checked”, unknown>.

So in our example, packageJSON will have its type narrowed from unknown to object to object & Record<“name”, unknown> That allows us to access packageJSON.name directly and narrow that independently.

interface Context {
    packageJSON: unknown;
}

function tryGetPackageName(context: Context): string | undefined {
    const packageJSON = context.packageJSON;
    // Check to see if we have an object.
    if (packageJSON && typeof packageJSON === "object") {
        // Check to see if it has a string name property.
        if ("name" in packageJSON && typeof packageJSON.name === "string") {
            // Just works!
            return packageJSON.name;
        }
    }

    return undefined;
}

TypeScript 4.9 also tightens up a few checks around how in is used, ensuring that the left side is assignable to the type string | number | symbol, and the right side is assignable to object. This helps check that we’re using valid property keys, and not accidentally checking primitives.

Auto-Accessors in Classes

TypeScript 4.9 supports an upcoming feature in ECMAScript called auto-accessors. Auto-accessors are declared just like properties on classes, except that they’re declared with the accessor keyword.

class Person {
accessor name: string;

constructor(name: string) {
this.name = name;
}
}

Under the covers, these auto-accessors “de-sugar” to a get and set accessor with an unreachable private property.

class Person {
#__name: string;

get name() {
return this.#__name;
}
set name(value: string) {
this.#__name = name;
}

constructor(name: string) {
this.name = name;
}
}

Checks For Equality on NaN

A major gotcha for JavaScript developers is checking against the value NaN using the built-in equality operators.

For some background, NaN is a special numeric value that stands for “Not a Number”. Nothing is ever equal to NaN – even NaN!

console.log(NaN == 0) // false
console.log(NaN === 0) // false

console.log(NaN == NaN) // false
console.log(NaN === NaN) // false

But at least symmetrically everything is always not-equal to NaN.

console.log(NaN != 0) // true
console.log(NaN !== 0) // true

console.log(NaN != NaN) // true
console.log(NaN !== NaN) // true

This technically isn’t a JavaScript-specific problem, since any language that contains IEEE-754 floats has the same behavior; but JavaScript’s primary numeric type is a floating point number, and number parsing in JavaScript can often result in NaN. In turn, checking against NaN ends up being fairly common, and the correct way to do so is to use Number.isNaN – but as we mentioned, lots of people accidentally end up checking with someValue === NaN instead.

TypeScript now errors on direct comparisons against NaN, and will suggest using some variation of Number.isNaN instead.

function validate(someValue: number) {
return someValue !== NaN;
// ~~~~~~~~~~~~~~~~~
// error: This condition will always return 'true'.
// Did you mean '!Number.isNaN(someValue)'?
}

They believe that this change should strictly help catch beginner errors, similar to how TypeScript currently issues errors on comparisons against object and array literals.

File-Watching Now Uses File System Events

In earlier versions, TypeScript leaned heavily on polling for watching individual files. Using a polling strategy meant checking the state of a file periodically for updates. On Node.js, fs.watchFile is the built-in way to get a polling file-watcher. While polling tends to be more predictable across platforms and file systems, it means that your CPU has to periodically get interrupted and check for updates to the file, even when nothing’s changed. For a few dozen files, this might not be noticeable; but on a bigger project with lots of files – or lots of files in node_modules – this can become a resource hog.

Generally speaking, a better approach is to use file system events. Instead of polling, they can announce that they’re interested in updates of specific files and provide a callback for when those files actually do change. Most modern platforms in use provide facilities and APIs like CreateIoCompletionPort, kqueue, epoll, and inotify. Node.js mostly abstracts these away by providing fs.watch. File system events usually work great, but there are lots of caveats to using them, and in turn, to using the fs.watch API. A watcher needs to be careful to consider inode watching, unavailability on certain file systems (e.g.networked file systems), whether recursive file watching is available, whether directory renames trigger events, and even file watcher exhaustion! In other words, it’s not quite a free lunch, especially if you’re looking for something cross-platform.

As a result, their default was to pick the lowest common denominator: polling. Not always, but most of the time.

Over time, they’ve provided the means to choose other file-watching strategies. This allowed us to get feedback and harden our file-watching implementation against most of these platform-specific gotchas. As TypeScript has needed to scale to larger codebases, and has improved in this area, we felt swapping to file system events as the default would be a worthwhile investment.

In TypeScript 4.9, file watching is powered by file system events by default, only falling back to polling if we fail to set up event-based watchers. For most developers, this should provide a much less resource-intensive experience when running in –watch mode, or running with a TypeScript-powered editor like Visual Studio or VS Code.

The way file-watching works can still be configured through environment variables and watchOptions – and some editors like VS Code can support watchOptions independently. Developers using more exotic set-ups where source code resides on a networked file systems (like NFS and SMB) may need to opt back into the older behavior; though if a server has reasonable processing power, it might just be better to enable SSH and run TypeScript remotely so that it has direct local file access. VS Code has plenty of remote extensions to make this easier.

“Remove Unused Imports” and “Sort Imports” Commands for Editors

Previously, TypeScript only supported two editor commands to manage imports. For our examples, take the following code:

import { Zebra, Moose, HoneyBadger } from "./zoo";
import { foo, bar } from "./helper";

let x: Moose | HoneyBadger = foo();

The first was called “Organize Imports” which would remove unused imports, and then sort the remaining ones. It would rewrite that file to look like this one:

import { foo } from "./helper";
import { HoneyBadger, Moose } from "./zoo";

let x: Moose | HoneyBadger = foo();

In TypeScript 4.3, they introduced a command called “Sort Imports” which would only sort imports in the file, but not remove them – and would rewrite the file like this.

import { bar, foo } from "./helper";
import { HoneyBadger, Moose, Zebra } from "./zoo";

let x: Moose | HoneyBadger = foo();

The caveat with “Sort Imports” was that in Visual Studio Code, this feature was only available as an on-save command – not as a manually triggerable command.

TypeScript 4.9 adds the other half, and now provides “Remove Unused Imports”. TypeScript will now remove unused import names and statements, but will otherwise leave the relative ordering alone.

import { Moose, HoneyBadger } from "./zoo";
import { foo } from "./helper";

let x: Moose | HoneyBadger = foo();

This feature is available to all editors that wish to use either command; but notably, Visual Studio Code (1.73 and later) will have support built in and will surface these commands via its Command Palette. Users who prefer to use the more granular “Remove Unused Imports” or “Sort Imports” commands should be able to reassign the “Organize Imports” key combination to them if desired.

Go-to-Definition on return Keywords

In the editor, when running a go-to-definition on the return keyword, TypeScript will now jump you to the top of the corresponding function. This can be helpful to get a quick sense of which function a return belongs to.

They expect TypeScript will expand this functionality to more keywords such as await and yield or switch, case, and default.

For more information and to develop web applications using TypeScript, Hire TypeScript Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.

To develop custom web apps using TypeScript, please visit our technology page.

Content Source:

1. devblogs.microsoft.com

What’s new in Next.js 13

npm i next@latest react@latest react-dom@latest eslint-config-next@latest

// app/page.js

// This file maps to the index route (/)

export default function Page() {

return <h1>Hello, Next.js!</h1>;

}

// app/blog/layout.js

export default function BlogLayout({ children }) {

return <section>{children}</section>;

}

// app/page.js

async function getData() {

const res = await fetch(‘https://api.example.com/…’);

// The return value is *not* serialized

// You can return Date, Map, Set, etc.

return res.json();

}

// This is an async Server Component

export default async function Page() {

const data = await getData();

return <main>{/* … */}</main>;

}

// This request should be cached until manually invalidated.

// Similar to `getStaticProps`.

// `force-cache` is the default and can be omitted.

fetch(URL, { cache: ‘force-cache’ });

 

// This request should be refetched on every request.

// Similar to `getServerSideProps`.

fetch(URL, { cache: ‘no-store’ });

 

// This request should be cached with a lifetime of 10 seconds.

// Similar to `getStaticProps` with the `revalidate` option.

fetch(URL, { next: { revalidate: 10 } });

Note: Turbopack in Next.js currently only supports next dev. View the supported features. We are also working to add support for next build through Turbopack.

import Image from ‘next/image’;

import avatar from ‘./lee.png’;

 

function Home() {

// “alt” is now required for improved accessibility

// optional: image files can be colocated inside the app/ directory

return <Image alt=”leeerob” src={avatar} placeholder=”blur” />;

}

npx @next/codemod next-image-to-legacy-image ./pages

import { Inter } from ‘@next/font/google’;

const inter = Inter();

<html className={inter.className}>

import localFont from ‘@next/font/local’;

const myFont = localFont({ src: ‘./my-font.woff2’ });

<html className={myFont.className}>

import Link from ‘next/link’

// Next.js 12: `<a>` has to be nested otherwise it’s excluded

<Link href=”/about”>

<a>About</a>

</Link>

&nbsp;

// Next.js 13: `<Link>` always renders `<a>`

<Link href=”/about”>

About

</Link>

npx @next/codemod new-link ./pages

// pages/api/og.jsx

import { ImageResponse } from ‘@vercel/og’;

export const config = {

runtime: ‘experimental-edge’,

};

export default function () {

return new ImageResponse(

(

<div

style={{

display: ‘flex’,

fontSize: 128,

background: ‘white’,

width: ‘100%’,

height: ‘100%’,

}}

&nbsp;

Hello, World!

</div>

),

);

}

// middleware.ts

import { NextResponse } from ‘next/server’;

import type { NextRequest } from ‘next/server’;

 

export function middleware(request: NextRequest) {

// Clone the request headers and set a new header `x-version`

const requestHeaders = new Headers(request.headers);

requestHeaders.set(‘x-version’, ’13’);

// You can also set request headers in NextResponse.rewrite

const response = NextResponse.next({

request: {

// New request headers

headers: requestHeaders,

},

});

// Set a new response header `x-version`

response.headers.set(‘x-version’, ’13’);

return response;

}

// middleware.ts

import { NextRequest, NextResponse } from ‘next/server’;

import { isAuthenticated } from ‘@lib/auth’; //

 

Limit the middleware to paths starting with `/api/`

export const config = {

matcher: ‘/api/:function*’,

};

 

export function middleware(request: NextRequest) {

// Call our authentication function to check the request

if (!isAuthenticated(request)) {

// Respond with JSON indicating an error message

return NextResponse.json(

{

success: false,

message: ‘Auth failed’,

},

{

status: 401,

},

);

}

}

How To Speed Up Data-Heavy React Components

Performance is very critical when building data-heavy applications. Every state change renders components. Managing states and rendering updates poorly may lead to slow applications and a bad user experience.

Simple Technique To Boost Performance

Every time state is updated, the component is rendered. By default, React thinks every component render is equal. It simply means that React tries to perform UI updates as quickly as possible. When working on data-heavy applications, every UI updates are not equal. Some updates can be de-prioritize to boost performance. React provides a simple technique called transitioning, which allows us to mark some UI updates as low-priority.

Example Code: heavy update as non urgent code

The above example has two UI components: the search box and the employee name list. The searched name is highlighted in the list whenever you type anything in the search box. An important thing to note here is that the query entered in the search box is not being displayed immediately. It is because React thinks all UI updates as of the same priority whenever the search query is updated. Since the name list is very long, it takes some time to render. The same reason is making the search box slow as well. Here the UI updates in the search box should be of high priority because whenever the user types something in the search box, it should be displayed immediately. The name list updates can be de-prioritized.

Let’s see how to do that in 3 quick steps.

Prioritizing UI Updates For Performance

By default, all updates in React are considered urgent. That could create a problem when heavy updates slow down quick updates.

Pic courtesy: medium.com

Before getting into the concept, it is important to remember that this feature is available in React 18 with concurrent mode enabled. To enable the concurrent mode in React, you need to update react and react-dom. Then replace from ReactDOM.render to ReactDOM.createRoot.

Pic courtesy: medium.com

React provides a useTransition hook which allows you to mark a UI update and low priority update so that other important UI updates and be performed quickly. Such as: In the above example UI update inside the search box is urgent, whereas the UI update for the name list can be marked as low priority update.

Pic courtesy: medium.com

const [isPending, startTransition] = useTransitionHook();

• isPending:indicates that the transition is pending
• startTransition(callback):allows you to mark any UI updates inside callback as transitions.

Pic courtesy: medium.com

Example Code: heavy update as non urgent code

In the above example, the search box UI update is urgent. It is done immediately, whereas the name list UI update is marked as a low-priority update. Whatever UI update is done inside startTransition is marked as a low priority update. This simple technique can boost up UI experience in data-heavy applications.

Build apps with reusable components like Lego

Pic courtesy: medium.com

Bit’s open-source tool help 250,000+ devs to build apps with components.

Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.

Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:

• Micro-Frontends
• Design System
• Code-Sharing and reuse
• Monorepo

For more information and to develop web application using React JS, Hire React Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.

To develop custom web apps using React JS, please visit our technology page.

Content Source:

1. medium.com

Creating a Progressive Web Application using Next JS

In this article, you will learn about the progressive web app, and why PWA is gaining popularity, and also you can create a simple PWA app using NextJs.

Overview

• Progressive Web App
• Project setup with NextJs
• PWA implementation

Progressive Web App ( PWA )

PWA = web + experience of a native application

What is PWA?

The progressive web app is a simple web application that runs on a web browser similar to that of a website and provides an installable feature on a mobile device. PWA gives you a rich mobile experience via native-like functionalities such as the ability to work offline, push notifications, device hardware accessibility, and many more. Web applications can reach anyone, anywhere, on any device with a single codebase as a result PWA is more special. PWA offers the same experience as the native app and you need not download it from an app store or play store. PWA loads runs and functions in a web browser.

The Native app is known for rich and reliable with its own standalone user experience, the web app are best for reachability. Progressive Web Apps combine the best features of both native and web apps, including native-like functionality, dependability across all platforms with a single codebase, installability, and accessibility to anyone, anywhere. They are designed, developed, and enhanced using cutting-edge and modern APIs.

Why PWA?

Some people may wonder why we need PWA if we can have a separate version of apps like android, IOS, and web. The PWA is gaining popularity because of the following features:

1. Installable: Installable on a mobile device and available via the device’s home screen. A PWA feels like a native app on the device with an immersive user experience.
2. Offline support: PWA offers the same services as on the web. If you try to load a website without internet connectivity, you will get a message saying you are offline. On the other hand, Progressive Web page enables you to connect to the website, even when you are offline that being said you must visit the PWA at least once before, in an online mode.
3. Platform independence: As you know native mobile apps are platform-specific, and can only be accessed from their respective OS like Android or iOS whereas PWA’s are platform independent and can run independently of any OS since they are browser-based.
4. Background synchronization: In the mobile application, you have to frequently re-install or update the apps when the new or additional features in the app are integrated. But in the case of PWA, the content is updated in the progressive web apps in the background, and new features are automatically integrated within the website, with a simple page refresh.
5. Cost-effective: PWA is quicker to develop with a lesser developmental cost making it cost-effective.
6. Enhance Loading Speed: As compared to normal websites, PWA has an instant loading time. As it is based on the method of intelligent caching, the first load, as well as the subsequent loads, are faster. Due to this, the bounce rate for PWA is lower compared to mobile websites.

Project Setup with NextJs

You will use NEXTJS to implement the PWA which is a react framework for developing feature-rich frontend web applications. Now, Let’s create the project executing any commands mentioned below in your terminal based on the package management tool that you have.

npx create-next-app@latest --ts
# or
yarn create next-app --typescript
# or
pnpm create next-app --ts

After executing the command you will have a pre-configured NextJs project.

PWA Implementation

Now you will work on the implementation of PWA in the project that you just configured. For PWA implementation you will make use of next-pwa which is a zero-config PWA Plugin for NextJs. Let’s install the plugin in the project using the command below:

yarn add next-pwa

npm install next-pwa

Step 1: withPWA

Now, update or create next.config.js

/** @type {import('next').NextConfig} */
const runtimeCaching = require("next-pwa/cache");
const withPWA = require("next-pwa")({
disable: process.env.NODE_ENV === "development",
dest: "public",
register: true,
skipWaiting: false,
runtimeCaching,
});
const nextConfig = withPWA({});

module.exports = nextConfig;

After running next build, this will generate two files in your public: workbox-*.js and sw.js, which will automatically be served statically.

Step 2: Create a custom server ( optional )

This step is optional. So if you want to use a custom server then you can proceed with this step. To create a custom server using express the root of the project with the file name server.js in order to load the service work. For creating the express server, you need to add express into the project

yarn add express

npm install express

const express = require("express");
const next = require("next");
const port = parseInt(process.env.PORT, 10) || 3000;
const dev = process.env.NODE_ENV !== "production";
const app = next({
dev,
});

const handle = app.getRequestHandler();
app.prepare().then(() => {
const server = express();
server.get("/service-worker.js", (req, res) => {
app.serveStatic(req, res, "./.next/service-worker.js");
});

server.get("*", (req, res) => {
return handle(req, res);
});
server.listen(port, (err) => {
if (err) throw err;
});
});

Step 3: Creating and adding Manifest File

You have to generate the manifest file inside the public folder in the project. For this, you can use any online tool for generating the manifest file.

Pic courtesy: medium.com

Fill in all the information and generate the manifest file. After that copy the content into the public directory and rename the file as manifest.json

Pic courtesy: medium.com

So now lets _document.tsx page and include the manifest.json link inside the Head tag as below:

import Document, { Html, Head, Main, NextScript } from "next/document";

class MyDocument extends Document {
render() {
return (
<Html>
<Head>
<link rel="manifest" href="/manifest.json" />
<link rel="apple-touch-icon" href="/logo.png"></link>
<meta name="theme-color" content="#fff" />
</Head>
<body>
<Main />
<NextScript />
</body>
</Html>
);
}
}

export default MyDocument;

You have successfully configured your project with PWA up to this point. Now run the following command and build the project.

yarn build

npm build

After build completion starts the build app using the following command:

yarn start

npm start

Pic courtesy: medium.com

When the app is started, you can see an install icon at the top of the browser like in the above image. Now you can install and use the app.

For more information and to develop web application using React JS, Hire React Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.

To develop custom web apps using React JS, please visit our technology page.

Content Source:

1. medium.com

What’s new in Next.Js

This RFC outlines the biggest update to Next.js since it was introduced in 2016:

• Nested Layouts: Build complex applications with nested routes.
• Designed for Server Components: Optimized for subtree navigation.
• Improved Data Fetching: Fetch in layouts while avoiding waterfalls.
• Using React 18 Features: Streaming, Transitions, and Suspense.
• Client and Server Routing: Server-centric routing with SPA-like behavior.
• 100% incrementally adoptable: No breaking changes so you can adapt gradually.
• Advanced Routing Conventions: Offscreen stashing, instant transitions, and more.

The new Next.js router will be built on top of the recently released React 18 features.

Terminology

This RFC introduces new routing conventions and syntax. The terminology is based on React and standard web platform terms. Throughout the RFC, you’ll see these terms linked back to their definitions below.

• Tree: A convention for visualizing a hierarchical structure. For example, a component tree with parent and children components, a folder structure, etc.
• Subtree Part of the tree, starting at the root (first) and ending at the leaves (last).

Pic courtesy: nextjs.org

URL Path: Part of the URL that comes after the domain.
URL Segment: Part of the URL path is delimited by slashes.

Pic courtesy: nextjs.org

Introducing the App Folder

Pic courtesy: nextjs.org

To ensure these new improvements can be incrementally adopted and avoid breaking changes, there is a proposed new directory called app.

The app directory will work alongside the page directory. You can incrementally move parts of your application to the new app directory to take advantage of the new features. For backward compatibility, the behavior of the page directory will remain the same and continue to be supported.

Defining Routes

Pic courtesy: nextjs.org

You can use the folder hierarchy inside the app to define routes. A route is a single path of nested folders, following the hierarchy from the root folder down to a final leaf folder.

For example, you can add a new /dashboard/settings route by nesting two new folders in the app directory.

Note:

With this system, you'll use folders to define routes, and files to define UI (with new file conventions such as layout.js, page.js, and in the second part of the RFC loading.js).
This allows you to colocate your own project files (UI components, test files, stories, etc) inside the app directory. Currently this is only possible with the pageExtensions config.

Route Segments

Each folder in the subtree represents a route segment. Each route segment is mapped to a corresponding segment in a URL path.

Pic courtesy: nextjs.org

For example, the /dashboard/settings route is composed of 3 segments:

The / root segment
The dashboard segment
The settings segment

Note: The name route segment was chosen to match the existing terminology around URL paths.

Layouts

New file convention: layout.js

So far, the folders are used to define the routes of our application. But empty folders do not do anything by themselves.

A layout is UI that is shared between route segments in a subtree. Layouts do not affect URL paths and do not re-render (React state is preserved) when a user navigates between sibling segments.

A layout can be defined by default exporting a React component from a layout.js file. The component should accept a children prop which will be populated with the segments the layout is wrapping.

There are 2 types of layouts:

Root layout: Applies to all routes
Regular layout: Applies to specific routes

You can nest two or more layouts together to form nested layouts.

Root layout

Pic courtesy: nextjs.org

You can create a root layout that will apply to all routes of your application by adding a layout.js file inside the app folder.

Note:

The root layout replaces the need for a custom App (_app.js) and custom Document (_document.js) since it applies to all routes.
You'll be able to use the root layout to customize the initial document shell (e.g. <html> and <body> tags).
You'll be able to use data fetching methods inside the root layout (and other layouts).

Regular layouts

Pic courtesy: nextjs.org

You can also create a layout that only applies to a part of your application by adding a layout.js file inside a specific folder.

For example, you can create a layout.js file inside the dashboard folder which will only apply to the route segments inside dashboard.

Nesting layouts

Pic courtesy: nextjs.org

Layouts are nested by default.

Pic courtesy: nextjs.org

For example, if it were to combine the two layouts above. The root layout (app/layout.js) would be applied to the dashboard layout, which would also apply to all route segments inside dashboard/*.

Pages

New file convention: page.js

Pic courtesy: nextjs.org

A page is UI that is unique to a route segment. You can create a page by adding a page.js file inside a folder.

Pic courtesy: nextjs.org

For example, to create pages for the /dashboard/* routes, you can add a page.js file inside each folder. When a user visits /dashboard/settings, Next.js will render the page.js file for the settings folder wrapped in any layouts that exist further up the subtree.

Pic courtesy: nextjs.org

You can create a page.js file directly inside the dashboard folder to match the /dashboard route. The dashboard layout will also apply to this page:

This route is composed of 2 segments:

• The / root segment
• The dashboard segment

Note:

For a route to be valid, it needs to have a page in its leaf segment. If it doesn't, the route will throw an error.

Layout and Page Behavior

• The file extensions js|jsx|ts|tsx can be used for Pages and Layouts.
• Page Components are the default export of page.js.
• Layout Components are the default export of layout.js.
• Layout Components must accept a children prop.

When a layout component is rendered, the children prop will be populated with a child layout (if it exists further down the subtree) or a page.

It may be easier to visualize it as a layout tree where the parent layout will pick the nearest child layout until it reaches a page.

For more information and to develop web application using React JS, Hire React Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.

To develop custom web apps using React JS, please visit our technology page.

Content Source:

1. nextjs.org

The most useful Frontend coding tips and Database concepts

Frontend development is very important these days. There are a lot of tasks that a frontend developer has to do on a daily basis.

As front-end developers, we write a lot of HTML, CSS, and JavaScript code all the time. Knowing some coding tips could be very beneficial for us. That’s why in this article, I decided to share with you some frontend coding tips that you probably don’t know.

Hiding an HTML element

Do you know that you can hide an HTML element without using JavaScript?

By using the attribute hidden, you can easily hide an HTML element natively. As a result, that element won’t be displayed on the web page.

Here is the code example:

<p hidden>This paragraph won't show up. It's hidden by HTML.</p>

Use the inset shorthand in CSS

It’s always a good practice to use shorthands in order to make your CSS code smaller. The property inset in CSS is a useful shorthand for the four properties top , left , right , and bottom .

If these four properties have the same value, you can just use the property inset instead and your code will look much cleaner.

Here is an example:

Bad practice:

div{
  position: absolute;
  top: 0;
  left: 0;
  bottom: 0;
  right: 0;
}

Good practice:

div{
  position: absolute;
  inset: 0;
}

Detect internet speed

You can easily detect internet speed in JavaScript by using the navigator object. It’s very simple.

Here is an example:

navigator.connection.downlink;

Pic courtesy: blog.devgenius.io

As you can see above, it gives me 5.65 since my internet speed is not good at all.

Vibrate your phone

Again, you can easily use the method vibrate()in the navigator object to vibrate your phone.

Here is an example:

//vibrating the device for 500 milliseconds

window.navigator.vibrate(500);

So as you can see, the device in this situation will vibrate for 500 milliseconds.

Disable pull to refresh

By using only CSS, you can disable pull to refresh on mobile. The property overscroll-behavior-y allows us to do that. Just give it the value contain .

Here is the example:

body{
 overscroll-behavior-y: contain;
}

Prevent the user from pasting text

There will be situations where you will need to prevent the user from pasting text into inputs.

Well, you can easily do that in JavaScript using a paste event listener.

Here is an example:

<input type="text"></input>
<script>
//selecting the input.
  const input = document.querySelector('input');
  
//prevent the user to paste text by using the paste eventListener.
  input.addEventListener("paste", function(e){
    e.preventDefault()
  })
  
</script>

As a result, now users can’t paste the copied text into the input field.

Database Concepts

Databases are the backbone of our applications, and the more you learn about how they work, the better you will be at using them, writing applications against them, and troubleshooting problems when things inevitably go wrong.
So let’s dive into seven things you should (probably) know about databases.

Choosing the Right Database Is Hard

We’ve seen a lot of dogmatic fist-banging about “the best” or “the worst” database, but the truth is the best database is the one that works best for your application. There’s no one-size-fits-all sort of database just like there’s no one-size-fits-all programming language or operating system.

When starting a new project, choosing the right database can be one of the most crucial decisions that you’ll make. So how should you choose which DB to use? We put together a list of five things to consider in our article on databases for developers, but let us also quickly go through them here.

What kind of data will be stored in the database?

Are you storing log files or user accounts?

How complex is the data that will be stored?

Can the data be normalized easily?

How uniform is the data?

Does your data roughly follow the same schema or is it disparate or heavily nested?

How often will it need to be read or written?

Is your application read- or write-heavy, or both?

Are there environmental or business considerations?

Do we have existing agreements with vendors? Do I need vendor support?

By answering these questions, you can help narrow down your choices to a few candidates. Once there, testing should tell you which one is the best for your application.

Moving to the Right Database Is Harder

Sometimes you don’t have a choice and the database is already chosen for you. Whether you came to the project after it was started or political winds forced you a certain way, using the wrong database for the job can be frustrating.

But equally, if not more, frustrating is the progress of migrating databases should you get the opportunity. Once you start down one path, it’s not easy to simply change paths in the middle of things. Not only do you have to figure out a way to replicate your data from one database to another and learn a whole new system, but depending on how tightly coupled your database code is with the rest of your application, you might also be looking at extensive rewrites as well. Changing databases is not a task that should be undertaken lightly and without a lot of consideration, debate, testing, and planning. There are so many ways that things can go horribly wrong. This is why #2 is so important: Once you choose, it’s hard to undo that choice.

NoSQL Doesn’t Replace SQL, It Complements It

The debate about using a SQL or NoSQL database will go on forever. We get that. But often missed in this argument is the fact that NoSQL databases don’t replace SQL databases. They complement them.

There are some things that NoSQL databases do very well and there are some things that SQL databases do very well. Prometheus is very good at storing time-series data like metrics, but you wouldn’t want to use MySQL for that. Is it technically possible? Yes, but it’s not designed for that and you’re not going to get the best performance or developer experience out of it. On the flip side, you wouldn’t want to use Redis to store highly relational data like user accounts or financial transactions for the same reasons. Sure, you could make it work in the code, but why add that complexity and headache when you could just use the right tool for the job?

There is going to be some inevitable overlap in some areas. There are some excellent databases that are technically NoSQL that do a good job of storing relational data (see: Couchbase), but there are other outside factors that go into using one over the other. Factors like client language support, operational tooling, cloud support, and others are all things to take into account when choosing a database.

For more information and to develop web applications using modern front-end technology, Hire Front-End Developer from us as we give you a high-quality solution by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft“.

To develop your custom web app using JavaScript, please visit our technology page.

Content Source:

1. blog.devgenius.io
2. betterprogramming.pub

What is new in React 18

React 17 was focused on improving the fundamentals but there are few important things that got added in React 18. The React Team revealed new features that would be coming to React in React 18 and in this blog, we will explore these features and how they can help you in the near future!

Strict Mode

Strict Mode has a few additions such as a new behaviour called “strict effects”. This allows us to double-invoke effects like mount and unmount. It creates an environment to correct behaviour with Fast Refresh during development, not only looking for more resilient components. There is also an ‘offscreen API’ which is currently being built.

An offscreen API will enable better performance by hiding components instead of unmounting them, keeping the state, and still calling the mount/unmount effects.

Automatic Batching

There is now major improvements with automatic batching. We will first look at performance.

React already batched, in other words grouped, multiple state updates into one to minimise unnecessary re-renders. However, elements like Promises, timeouts, or other handlers didn’t take advantage of it as it was only limited to DOM event handlers.

This all changes with React 18 which will batch state updates without limits, as long as it’s safe to do. The result, you ask?…This would create better performance without any additional involvement.

There are huge improvements to automatic batching. In the earlier versions of React, it uses to batch multiple state updates into one to reduce unnecessary re-renders. The problem was it was done only in DOM event handlers and not in promises, timeouts, or other handlers.

Let’s look at the below code on how batching occurs with earlier versions of React.

export default function App() {
    const [count, setCount] = useState(0);
    const [color, setColor] = useState(undefined);
    
    const handleClick = () => {
        setCount(count + 1); //No re-render
        setColor(count % 2 === 0 ? "Green" : "Red"); //No re-render
        // Now re-renders once at the end (this is batching)
    } 
    return (
        <>
            <button onClick={handleClick}>Next</button>
            <span style={{
                color: count % 2 === 0 ? "red" : "green",
            }}>
                {color}
            </span>
        </>
    );
}

With React 18, promises, timeouts, or other handlers will also take advantage of that. It will batch state updates no matter where they happen. This will result in better performance.

Let’s look at the below code where batching occurs. In the below code batching works fine with React 18 but earlier versions of React will not batch it.

export default function App() {
    const [count, setCount] = useState(0);
    const [color, setColor] = useState(undefined);    const handleClick = () => {
        Promise.resolve().then(() => {
            setCount(count + 1); //Re-render
            setColor(count % 2 === 0 ? "Green" : "Red"); //Re-render
        });
    }    return (
        <>
            <button onClick={handleClick}>Next</button>
            <span style={{
                color: count % 2 === 0 ? "red" : "green",
            }}>
                {color}
            </span>
        </>
    );
}

However, if there is a need where we don’t want our component to be batched, we can opt-out that component using ReactDOM.flushSync().

Concurrent Rendering

Concurrent rendering is definitely one to look for as it is by far the biggest update with React 18.

Prior to this name, it was called ‘concurrent mode’. The change in name signifies the enabling of gradual adoption of concurrent features. This allows us to adopt concurrent features without rewriting code and do so at your own pace.

New APIs

With React 18, we get several new APIs which come in many forms.

startTransition

Its purpose is to spot state updates as transitions, making handling them non-urgent.

useDeferredValue

This hook will give you a deferred element of the passed value, which will follow the original one, up to provided timeout.

The ‘useDeferredValue’ is a hook that will return a deferred version of the passed value. It takes in the state value and a timeout in milliseconds. It will return a deferred version of the value that may “lag behind” it for most timeouts.

import { useDeferredValue } from "react";
const [text, setText] = useState("react js");
const deferredText = useDeferredValue(text, { timeoutMs: 2000 });

This is commonly used to keep the UI responsive when we have something that renders immediately based on user input and something that needs to wait for a data fetch.

Suspense

In the previous version of react, the below code would result in ReadyComponent being immediately mounted and its effects called. Like its name, Suspense suspends something until it’s ready to be rendered.

<Suspense fallback={<Loading />}>
    <ComponentWaitingForData />
    <ReadyComponent />
</Suspense>

This has been taken care of in React 18.

Referring to the above code, Now it won’t mount the ReadyComponent, instead will waiting for ComponentWaitingForData to resolve first.

SuspenseList

A SuspenseList excepts a two prop. ‘revealOrder’ and ‘tail’.

‘revealOrder’ is one of SuspenseList configuration options. It can be undefined, together, forwards, and backwards.

• undefined (default): reveal children as suspenders resolve.
• together: reveal children together, once all suspenders are resolved.
• forwards: render children from top to bottom, indifferent to suspender. resolution order
• backwards: render children from bottom to top, indifferent to suspender resolution order

‘tail’ props dictates how the unloaded items in a SuspenseList are shown. Its value can either be collapsed or hidden.

<SuspenseList revealOrder="forwards" >
    <Suspense fallback={<p>Loading attendance...</p>}>
        <Attendance id={facultyID}/>
    </Suspense>
    <Suspense fallback={<p>Loading homework...</p>}>
        <Homework id={facultyID}/>
    </Suspense>
</SuspenseList>

The above code with SuspenseList demonstrates that we can set the revealOrder to force the attendance to appear first and then the homework section.

<SuspenseList revealOrder="forwards" tail="collapsed">
    <Suspense fallback={<p>Loading attendance...</p>}>
        <Attendance id={facultyID}/>
    </Suspense>
    <Suspense fallback={<p>Loading homework...</p>}>
        <Homework id={facultyID}/>
    </Suspense>
</SuspenseList>

The above code demonstrates that only one fallback is shown at a time. i.e first the fallback for the attendance and then the fallback for the homework.

Root API

createRoot will replace the render function. The new API is the gateway to accessing new React 18 features. It’s meant to encourage gradual adoption and ease-out potential performance comparisons.

For more information and to develop web application using React JS, Hire React Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”. To develop custom web apps using React JS, please visit our technology page.

Content Source:

1. medium.com
2. javascript.plainenglish.io

Amazing new features in React Router v6

We love React!! We have been using the latest stuff from React in our latest project and found a lot of important and cool differences from the previous versions.

The following APIs will not only help you increase your productivity but also improve your code structure.

• Outlet
• forwardRef
• useRoutes
• useLocation

Any developer who is looking forward to learn React or even the ones who have been using React for a while should be able to use and enjoy the stuff in this article!!

Outlet

import { BrowserRouter, Routes, Route, Link } from 'react-router-dom';

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="users/*" element={<Users />} />
      </Routes>
    </BrowserRouter>
  );
}

function Users() {
  /* All <Route path> and <Link to> values in this
     component will automatically be "mounted" at the
     /users URL prefix since the <Users> element is only
     ever rendered when the URL matches /users/*
  */
  return (
    <div>
      <nav>
        <Link to="me">My Profile</Link>
      </nav>

      <Routes>
        <Route path="/" element={<UsersIndex />} />
        <Route path=":id" element={<UserProfile />} />
        <Route path="me" element={<OwnUserProfile />} />
      </Routes>
    </div>
  );
}

The above is standard code that is used to created routes for navigation in React projects.

Now let’s check React router v6 code:

import {
  BrowserRouter,
  Routes,
  Route,
  Link,
  Outlet
} from 'react-router-dom';

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="users" element={<Users />}>
          <Route path="/" element={<UsersIndex />} />
          <Route path=":id" element={<UserProfile />} />
          <Route path="me" element={<OwnUserProfile />} />
        </Route>
      </Routes>
    </BrowserRouter>
  );
}

function Users() {
  return (
    <div>
      <nav>
        <Link to="me">My Profile</Link>
      </nav>

      <Outlet />
    </div>
  );
}

The <Outlet> element is used as a placeholder. In this case an <Outlet>enables the Users component to render its child routes. Thus the<Outlet> element will render either a <UserProfile> or <OwnUserProfile> element depending on the current location.

Thus the best way this element can be used is in layouts. You can simply create multiple layouts, for e.g.- the Dashboard Layout(for the profile and members page) or the Main Layout(for login and logout, basically when the user is not signed in). Finally, you can simply inject whichever component one needs depending on its route rather than wrapping each route component in a parent layout component like:

<Route path="/" element={<DashboardLayout />}>
          <Route path="/" element={<HomePage />} />
          <Route path=":id" element={<UserProfile />} />
          <Route path="me" element={<OwnUserProfile />} />
</Route>

useRoutes

import {
  BrowserRouter,
  Link,
  Outlet,
  useRoutes
} from 'react-router-dom';

function App() {
  // The <BrowserRouter> element is removed from App because the
  // useRoutes hook needs to be in the context of a <BrowserRouter>
  // element. This is a common pattern with React Router apps that
  // are rendered in different environments. To render an <App>,
  // you'll need to wrap it in your own <BrowserRouter> element.
  let element = useRoutes([
    // A route object has the same properties as a <Route>
    // element. The `children` is just an array of child routes.
    { path: '/', element: <Home /> },
    {
      path: 'users',
      element: <Users />,
      children: [
        { path: '/', element: <UsersIndex /> },
        { path: ':id', element: <UserProfile /> },
        { path: 'me', element: <OwnUserProfile /> },
      ]
    }
  ]);

  return element;
}

function Users() {
  return (
    <div>
      <nav>
        <Link to="me">My Profile</Link>
      </nav>

      <Outlet />
    </div>
  );
}

React Router v6 ships with an awesome API for routing that uses plain JavaScript objects to declare your routes. In fact, if you look at the source of <Routes>, you’ll see that it’s really just a tiny wrapper around a hook that is at the heart of the router’s matching algorithm: useRoutes.

The useRoutes hook is a first-class API for routing that lets you declare and compose your routes using JavaScript objects instead of React elements. Continuing with the example above, let’s see what it looks like with useRoutes.

The useRoutes hook accepts a (possibly nested) array of JavaScript objects that represent the available routes in your app. Each route has a path, element, and (optionally) children, which is just another array of routes.

This nested array of Javascript objects keeps the code DRY and improves the readability of the code.

The object-based route configuration may look familiar if you were using the react-router-config package in v5. In v6, this configuration format has been promoted to a first-class API in core and the react-router-config package will be deprecated.

Moreover, the layout example in the Outlet section can be simplified as follows:

let element = useRoutes([
    {
      path: '/',
      element: <DashboardLayout/>,
      children: [
        { path: '/', element: <HomePage/> },
        { path: ':id', element: <UserProfile /> },
        { path: 'me', element: <OwnUserProfile /> },
      ]
    }
  ]);

forwardRef

Ref forwarding is a cool technique for automatically passing a ref through a component to one of its children. It gives the child component a reference to a DOM element created by its parent component. This then allows the child to read and modify that element anywhere it is being used.

Before We show you how to ‘forward’ refs lets first learn what they are and how to create them.

Creating refs

To create a ref, use the React function called React.createRef(). These refs can then be attached to React elements via the ref attribute. Refs are somewhat similar to state. On assigning refs to instance properties of that component we can ensure that they can be referenced anywhere in the component. Check the example below:

class MyComponent extends React.Component {
  constructor(props) {
    super(props);
    this.newRef = React.createRef(); //newRef is now available for use throughout our component
  }
 ...
}
class MyComponent extends React.Component {
 ...
  render() {
    return <div ref={this.myRef} />;
  }
}

Here We created a ref called newRef and and attached it to the div element in the MyComponent component. As a result, We now have the ability to update the div without changing state.

This is the significance of using refs as you can update and modify elements without using state variables that result in the re-rendering of components.

A few points of significance directly from the documentation:

• When the ref attribute is used on an HTML element, the ref created in the constructor with React.createRef() receives the underlying DOM element as its current property
• When the ref attribute is used on a custom class component, the ref object receives the mounted instance of the component as its current i.e the components props, state, and methods
• As seen in the official React documentation, there are a few good use cases for refs:

Managing focus, text selection, or media playback

Let’s imagine you have an input component. In some parts of your application, you may want the cursor focused on it when a user clicks a button. It makes more sense to modify only that particular instance of the input component without changing the state (via refs), rather than changing the state (via props) which will cause the component to re-render every-time. Similarly, you can use refs to control the state of music or video players (pause, play, stop) without them re-rendering anytime you click a button (change the state).

Incrementing values

Think about a Medium clap button. A quick way to implement a similar feature would be to increment the count value stored in the state every time a user clicks a clap. However, this may not be very efficient. Every time a user clicks the clap button it will re-render, and if you are sending a network request to store the value in a server it will get sent as many times as the button is clicked. With refs, you can target that particular node and increment it every time a user clicks the button without causing a re-render and finally, you can send one request to our server with the final value.

Triggering imperative animations

You can use refs to trigger animation between elements that rely on themselves for their next state but exist in different components (this concept is called ref forwarding). Refs can also be used to simplify integration with third-party DOM libraries and managing multistep form value states etc.

Now let’s move to the technique of ref forwarding:

Ref forwarding is a technique that automatically passes a ref through a component to one of its children. Ref forwarding is very useful when building reusable component libraries. forwardRef is the function used to pass the ref to a child component. Let’s check out an example below:

function SampleButton(props) {
  return (
    <button className="button">
      {props.children}
    </button>
  );
}

The SampleButton() component is a modified button that will be used throughout the application in a similar manner as a regular DOM button, therefore accessing its DOM node may be unavoidable for managing focus, selection, or animations related to it.

In the example below, SampleComponent() uses React.forwardRef to obtain the ref passed to it, and then forward it to the DOM button that it renders:

const SampleButton = React.forwardRef((props, ref) => (
  <button ref={ref} className="button">
    {props.children}
  </button>
));
const ref = React.createRef();
<SampleButton ref={ref}>Click me!</SampleButton>;

Now that We’ve wrapped the SampleButton component with the forwardRef method, components using it can get a ref to the underlying button DOM node and access it if necessary – just like if they used a DOM button directly.

Here’s a clarification for the code above:

• A ref is defined in the component that needs the ref and pass it to the button component
• React will pass the ref through and forward it down to <button ref={ref}> by specifying it as a JSX attribute
• When the ref is attached, ref.current will point to the <button> DOM node.

We have just covered the basics of these very extensive topics. Hope you try them out in your coming React projects.

For more information and to develop web application using React JS, Hire React Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”. To develop custom web apps using React JS, please visit our technology page.

Content Source:

1. medium.com