DEV Community: A.S.M. Habibullah Sadique

All about NextJS routing

A.S.M. Habibullah Sadique — Mon, 25 Apr 2022 02:34:17 +0000

Intro

It has a file-system based routing mechanism
When a file is added to the pages folder in a project, it automatically becomes available as a route
By mixing and matching file names with a nested folder structure, it is possible to pretty much define the most common routing patterns
Routing variations are:
- Route with pages
- Nested routes
- Dynamic routes
- Catch-all routes
- Navigate from the UI
- Programmatically navigate between pages

Routing with pages

It has a file-system-based routing mechanism.

Scenario 01: index.js file within the pages folder will map to the root (https://localhost:3000) of your domain.
Scenario 02: Pages are associated with routes based on their names. In the pages folder, about.js maps to https://localhost:3000/about and profile.js maps to https://localhost:3000/profile in the address bar.

Nested routes

Scenario 01: pages->blog->index.js maps to https://localhost:3000/blog
Scenario 02: pages->blog->first.js maps to https://localhost:3000/blog/first
Scenario 03: pages->blog->second.js maps to https://localhost:3000/blog/second

Dynamic routes

To implement dynamic routes, you need to name a component by wrapping it with square brackets like [componentName].js and componentName will correspond to the dynamic value in the url
pages->product->[productId].js maps to https://localhost:3000/product/1, https://localhost:3000/product/2 or even https://localhost:3000/product/100. The number/string after the /product/ in the url will dynamically correspond and map to [productId].js component and the number/string after /product/ can be found inside [productId].js component using the useRouter hook like this -

 const router = useRouter();
    const productId = router.query.productId; 
    // productId is the dynamic component’s name

But if a number/string after /product/ in the url is matched with the name of a component already existing inside the product page, that component with the matched name will get priority over [productId].js and be rendered rather than [productId].js being rendered.

Nested dynamic routes

To implement nested dynamic routes like https://localhost:3000/product/7/review/2, you need a folder structure like pages/product/[productId]/review/[reviewId].js. Note that this time [productId] is a folder, not a .js file.
- So, pages/product/[productId]/review/[reviewId].js maps to https://localhost:3000/product/7/review/2
In this mechanism, to achieve the functionality of https://localhost:3000/product/1, (only dynamic, not nested dynamic) you need a folder structure like pages/product/[productId]/index.js. You will find productId in the url dynamically in the index.js file.
Thus you can implement dynamic nested routes by having dynamic segments in the folder name as well as file name.
Speaking of dynamic multiple path segments, Next JS does offer another feature to handle the same. To know more about the feature, read the next topic.

Catch all routes

This feature applies to scenario where the url contains multiple route segments like https://localhost:3000/docs/feature1/concept1
The folder structure for https://localhost:3000/docs/feature1/concept1 should be pages/docs/[...params].js and inside [...params].js you can use useRouter to get both feature/ and concept/ or even more to it like below -

    const router = useRouter();
    const { params = [] } = router.query; 
    // assigned an empty array because initially it is undefined 
    // and may give an error in production
    console.log(params); // [ "features1", "concept1" ]

After getting your dynamic route segments, You can then conditionally render your components or JSX elements like this -

const Doc = () => {
    const router = useRouter();
    const { params = [] } = router.query; 
    // assigned an empty array because initially it is undefined 
    // and may give an error in production
    console.log(params); // [ "features1", "concept1" ]

    if (params.length === 2) {
        return (
            <h2>Viewing docs for feature {params[0]} and concept {params[1]}</h2>
        )} else if (params.length === 1) {
        return (
            <h2>Viewing docs for feature {params[0]}</h2>
        )}
    return (
        <div>Docs home page</div>
    )};

export default Doc;

But the folder structure pages/docs/[...params].js will give a 404 while trying to access https://localhost:3000/docs. To have a quick fix, you can put another pair of square brackets around [params].js, so the new folder structure is pages/docs/[[...params]].js and https://localhost:3000/docs does not give a 404 and works as expected.

Link component navigation

You can navigate in the UI using Link component offered by Next.js like this -

<Link href="product/2" replace >
     <a>Go to Product 2</a>
</Link>

Navigating programmatically

You can navigate programmatically using useRouter. All other routing variations are valid in this mechanism.

const Home = () => {
    const router = useRouter();
    const handleOrder = () => {
        console.log('Placing the order...');
        router.push('/product');
    };
    return (
        <div>
            <button onClick={handleOrder}>Place order</button>
        </div>
    );
};

Custom 404 page

To provide your custom 404 page, create a 404.js file in the pages folder.

Conclusion

So, that is all about routing in NextJS. Hope you liked it. Thanks for reading.

Next.js features I'm excited about

A.S.M. Habibullah Sadique — Fri, 15 Apr 2022 15:43:53 +0000

Stable Incremental Static Regeneration

Simply speaking, this feature allows you to generate static content dynamically. Let's see a quick example:

Say you have a blog website with a lot of articles. When somebody visits /news/link, you want to serve them the static page as fast as you can.

But it is possible that you don't want to create all static pages at build time because it would take you a lot of time. In a few cases, this isn't possible at all at build time.

Also, sometimes your content might change, like a quick blog edit - so you don't really want a completely static page forever either. So what's the solution?

Using Next.js 9.5+, now you can generate static pages dynamically to the dynamic path and refresh them.

This means that once Next fetches that particular URL, it'll save it as a static page and serve it statically whenever somebody visits the path. At the same time, it'll be open to accepting new paths dynamically.

Not only can you do this, with a revalidate parameter, you can also actually specify that Next.js should update your static pages once every X seconds in the background if there's any change!

getServerSideProps

getServerSideProps, as the name suggests, allows you to inject props in your Next.js page from the server itself. And getStaticProps allows Next.js to still create static outputs at build time.

getStaticProps combined with incremental static regeneration is a killer feature in my opinion. You get the many benefits of a dynamic backend without having a dynamic backend.

Persistent Caching for Page Bundles

Next.js also supports persistent caches for pages that are not changed. Before, when you shipped a new Next.js app, Next.js would throw out the whole app and the user had to download all the CSS/JS again, even if those bundles were unchanged.

In the latest version of Next.js released last week, Vercel introduced persistent caching which is again an absolutely great thing to have performance-wise.

JWT

A.S.M. Habibullah Sadique — Wed, 09 Feb 2022 15:58:51 +0000

JWT

JSON Web Token structure:
In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

Header
Payload
Signature

So, a JWT typically looks like the following: xxxxxx.yyyyyy.zzzzzz

*Header: *

The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.

For example:

{
    “alg”: “HS256, 
    “typ”: “JWT”
}

Then this JSON IS Base64Url encoded to form the first part of the JWT.

*Payload: *

The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.

Registered claims: These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims. Some of them are: iss (issuer), exp (expiration time), sub (subject), aud (audience), and others.

Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.

Private claims: These are the custom claims created to share information between parties that agree on using them and are neither registered or public claims.

An example payload could be:

{
    “sub”: “131242134”,
    “name”: “Sadique Habibullah”,
    “admin”: true
}

The payload is then Base64Url encoded to form the second part of the JSON Web Token.

*Signature: *

To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

For example if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

The signature is used to verify the message wasn't changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.

*Putting it altogether: *

The output is three Base64-URL strings separated by dots that can be easily passed in HTML and HTTP environments, while being more compact when compared to XML-based standards such as SAML.

Finally it becomes something like this:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTY0NDQxNzA1NCwiZXhwIjoxNjQ0NDIwNjU0fQ.GiJsRD3463h80YlAYG92UupWcot7jWRHNhnNpnBV2bQ

React.useCallback()

A.S.M. Habibullah Sadique — Wed, 09 Feb 2022 13:32:41 +0000

Before diving into useCallback() usage, let's distinguish the problem useCallback() solves — the functions equality check.

Functions in JavaScript are first-class citizens, meaning that a function is a regular object. The function object can be returned by other functions, be compared, etc.: anything you can do with an object.

Let's write a function factory() that returns functions that sum numbers:

function factory() {
  return (a, b) => a + b;
}
const sum1 = factory();
const sum2 = factory();
sum1(1, 2); // => 3
sum2(1, 2); // => 3
sum1 === sum2; // => false
sum1 === sum1; // => true`

sum1 and sum2 are functions that sum two numbers. They've been created by the factory() function.

The functions sum1 and sum2 share the same code source but they are different function objects. Comparing them sum1 === sum2evaluates to false.

The purpose of `useCallback()`

Different function objects sharing the same code are often created inside React components:

function MyComponent() {
  // handleClick is re-created on each render
  const handleClick = () => {
    console.log('Clicked!');
  };
  // ...
}

handleClick is a different function object on every rendering of MyComponent.

Because inline functions are cheap, the re-creation of functions on each rendering is not a problem. A few inline functions per component are acceptable.

But in some cases you need to maintain a single function instance between renderings:

A functional component wrapped inside React.memo() accepts a function object prop
When the function object is a dependency to other hooks, e.g. useEffect(..., [callback])
When the function has some internal state, e.g. when the function is debounced or throttled.

That's when useCallback(callbackFun, deps) is helpful: given the same dependency values deps, the hook returns the same function instance between renderings (aka memoization):

import { useCallback } from 'react';
function MyComponent() {
  // handleClick is the same function object
  const handleClick = useCallback(() => {
    console.log('Clicked!');
  }, []);
  // ...
}

handleClick variable has always the same callback function object between renderings of MyComponent.