DEV Community: Nicolas Santos

Why is ngrok returning HTML?

Nicolas Santos — Wed, 07 Sep 2022 02:22:54 +0000

Using ngrok for creating a proxy of your local backend is in every development journey, mostly when you want to expose a local service using an environment variable.

I found a problem that entertained me the whole afternoon while trying to deploy a Gmail Addon using Google App Script.
I couldn't make a request since the response returns HTML.
ngrok tries to ensure that if someone shares this URL with another part, this part knows that this URL is a tunnel to another endpoint.

The solution is straightforward. We should set ngrok-skip-browser-warning in the headers of the response with any value, e.g

// Only for local development
headers['ngrok-skip-browser-warning'] = 'skip-browser-warning';

Validating repository content with GitHub GraphQL API

Nicolas Santos — Wed, 08 Jun 2022 02:06:04 +0000

Let's start by seeing what the query is, and after that, explain by parts which are the meaning behind each expression and how we can handle the information.

query($owner: String!, $repositoryName: String!) {
  repository(owner: $owner, name: $repositoryName) {
    packageJson: object(expression: "HEAD:package.json") {
      ... on Blob {
        byteSize,
        text
      }
    }
  }
}

Very simple, isn't it?

This query takes as query variables owner, which is the owner of the repository, and repositoryName.

First of all, we need to access the repository information, once we invoke the query for obtaining the infomration, we can get object , this field allows an expression in which we're gonna specify the path of the file that we have to validate, in this case, HEAD:package.json, but it can be wherever you want (the format is the following ${branch}:${pathFile}).

After that, you have to obtain the Blob of this object, which includes byteSize (aka the file size, or null if it doesn't exist) and text(aka the content file).

And that's all!

With this query we can obtain something like

{
  "data": {
    "repository": {
      "packageJson": {
        "byteSize": 719,
        "text": "{\n  \"name\": \"test-repo\",\n  \"version\": \"1.0.0\",\n  \"author\": \"\",\n  \"copyright\": \"\",\n  \"scripts\": {\n    \"dev\": \"zuplo dev\",\n    \"build\": \"zuplo build\",\n    \"test\": \"zuplo test\",\n    \"postinstall\": \"husky install\"\n  },\n  \"dependencies\": {\n    \"devDependencies\": {\n    \"husky\": \"^7.0.4\"\n  },\n  \"packageManager\": \"yarn@3.1.0\"\n  }\n}"
      }
    }
  }
}

or if the file doesn't exist

{
  "data": {
    "repository": {
      "packageJson": null
    }
  }
}

Sitemap: What is and how to generate it for a Next.js App

Nicolas Santos — Sat, 27 Mar 2021 17:36:55 +0000

Trying to improve my personal site SEO I end up with the need to generate dynamically a sitemap, but first of all...

What is a Sitemap?

A sitemap is a blueprint of your website that help search engines find, crawl and index all of your website's content. Yep, I saved you a google search 😉

The sitemap is located on /sitemap.xml and looks like

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://santosnicolas.com/404</loc>
  </url>
  <url>
      <loc>https://santosnicolas.com/blog</loc>
  </url>
  <url>
    <loc>https://santosnicolas.com</loc>
  </url>
  <url>
    <loc>https://santosnicolas.com/notes</loc>
  </url>
  <url>
    <loc>https://santosnicolas.com/notes/whatever-post-title</loc>
  </url>
</urlset>

How I generate the sitemap on Next.js

We basically need to add

<url>
    <loc>${routePage}</loc>
</url>

For every page that we had on our application.

Because of this, we need to get all our page routes or at least the ones that are public. This is an easy task with globby, this lib allows us to get the name of the files based on regex URL on our folder structure.

const globby = require("globby")

;(async () => {
  // Take all the pages except for _app.tsx and _document.tsx
  const pagesPaths = await globby(["pages/*.tsx", "!pages/_*.tsx"])

  console.log(pagesPaths)
  //=> ['index.tsx', 'blog.tsx', 'notes.tsx']
})()

With fs and prettier we can format and write our generated file(sitemap.xml) to located in the public folder.

// generateSitemap.js
const fs = require("fs")
const globby = require("globby")
const prettier = require("prettier")

;(async () => {
  console.info("Generating Sitemap 🗺")
  const prettierConfig = await prettier.resolveConfig("./.prettierrc.js")
  const pages = await globby(["pages/*.tsx", "!pages/_*.tsx"])

  const sitemap = `
        <?xml version="1.0" encoding="UTF-8"?>
        <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
            ${pages
              .map((page) => {
                const path = page
                  .replace("pages/", "/")
                  .replace("public/", "/")
                  .replace(".tsx", "")
                  .replace("/index.xml", "")
                const route = path === "/index" ? "" : path
                return `
                        <url>
                            <loc>${`${siteMetadata.siteUrl}${route}`}</loc>
                        </url>
                    `
              })
              .join("")}
        </urlset>
    `

  const formatted = prettier.format(sitemap, {
    ...prettierConfig,
    parser: "html",
  })

  // eslint-disable-next-line no-sync
  fs.writeFileSync("public/sitemap.xml", formatted)
  console.info("Success generation of sitemap 🎉")
})()

Finally, we need to run this script every time that Next.js builds the application

// next.config.js
module.exports = {
  webpack(config, { dev, isServer }) {
    // Other next.js configuration...

    if (isServer) {
      require("./scriptsPath/generateSitemap")
    }

    return config
  },
}

And voila 🎉 our sitemap is generated every time we build our application.

Final Notes

This example doesn't consider the case in which our paths are generated dynamically, like for example if we have pages/blog/[slug].tsx, but I think it will be easy to add that part based on the initial script.

I'm gonna leave in this Github gist in case you need a boost 😉

Preact: Optimize your Next.js build with 5 lines of code

Nicolas Santos — Fri, 26 Mar 2021 22:02:50 +0000

Hey hey👋 let's get started on this quickly, in this note you can find a way to optimize your build size by 38% with just a lib install and 5 lines of code.

What is Preact?

According to his website, Preact is a Fast 3kB alternative to React with the same modern API. Basically overrides a lot of the methods that use React, like render for example, and optimize it at build-time.

Optimize Next.js build with Preact

Install Preact
yarn add preact or npm i preact
Create a next.config.js if you don't already have one in the root of your project
touch next.config.js
Add the next code or adapt your previous config

   module.exports = {
     webpack(config, { dev, isServer }) {
       // ${previousConfig...}

       // Replace React with Preact only in client production build
       if (!dev && !isServer) {
         Object.assign(config.resolve.alias, {
           react: "preact/compat",
           "react-dom/test-utils": "preact/test-utils",
           "react-dom": "preact/compat",
         })
       }

       return config
     },
   }

Ready 🎉

React Query and management of server state

Nicolas Santos — Wed, 24 Jun 2020 17:42:54 +0000

Some days ago the React Summit Remote Edition gathered tons of people behind the screen with the promise of putting together popular speakers around the React Community like Kent C. Dodds and Guillermo Rauch among others, but one talk especially caught my attention, React Query: It’s Time to Break up with your "Global State”! by Tanner Linsley. In it, Tanner talked about two pain points that I had frequently with React, which were how to handle asynchronous information in the global state and how to restructure my code to be less repetitive and not force async data to follow synchronous flow.
In this article, I'll explain in more detail which is the problem with the global state and how React Query solves it in an efficient-scalable way.

The problem with global state

Libraries like Redux, MobX and even Context API provided by React are based in the Global State pattern, which means that to avoid prop drilling and sharing data between the components in different hierarchy levels, and have one single point to read and write from the components(making it easy to store data used across the app), the entire application exposes a global variable called global state.

This pattern has many advantages, but the problem lies in the different types of data that potentially has the global state in our applications. These data can be internal information about our application, like for example if the navbar is open or not, or information that has ownership with another source, for instance, the user information like his name, age, etc, that is provided by backend and can be modified in the frontend. The two types of data mentioned above can be classified as a client state and server state.

The main difference between each is the server state has two sources of truth, the backend, and the frontend. This causes the server state to synchronize all the time to prevent that its information is not out of date. As we know, this is not performant at all and it wouldn't be a good practice to request information all the time(image putting a spinner every time you do a request), for that reason we need some way to show the old information and at the same time update it with the new information on the background every so often. This is a very difficult task if we try to do with Redux or the other tools that I mentioned before because we have to find a way to resolve cache management, background update and other cases that require a little bit more of implementation when merging old and new data such as pagination or infinite scroll.

What is React Query and how it solves these problems?

React Query is a library that with 2 hooks and 1 utility (only 5kb!) provides an easy and scalable way to fetching, caching, and updating asynchronous data in React.

Before jumping off to the code and seeing some examples I'd like to introduce how React Query models the server state.

In the image above, we can see the different states for the server state information, let's explain what is the meaning of each state:

Fetching: This is the initial state and occurs when the data is fetching from an outsource, typically the backend.
Fresh: On this state, the information is the same on both sides, this is the desired state of our application because it implies that we don't need to re-fetch the information. On the other hand, this state lasts a short time because in most cases when you're fetching information, this information immediately is potentially out of date.
Stale: Represents the out of date data that the app is currently using. This happens because the frontend has old information and needs to re-fetch it from the backend, or the backend is not updated because the frontend didn't send the new information to the backend yet. This state is particularly important as long as we want to be in the fresh state again.
Inactive: React Query has a garbage collector for managing cache on the browser, this state in some manner indicates to React query that if the data is not being used in the application, it will potentially be deleted after a while. This is a great feature of React Query, because we want to persist the recent information to not fetching data all the time and improve the speed/UX of our interfaces.
Deleted: This happens when the data was inactive for a certain period of time and it's deleted from the cache. This timeout can be configurable locally for each query or globally.

With this approach, React Query handles the asynchronous information of our application clearly, allowing us to scale and maintain our code in a better way.

Introduction to React query API

Although React Query has only two hooks, it is highly configurable in all aspects, from the retry delay time of the queries to the set maximum time of inactive data in the cache.
But let's start with the most basic API that is well documented in their repository

This hook provided us the status of the fetch (loading, error, or success), and data and error if they are defined. Up to this point is a pretty normal hook for fetching information, but as we see the query is related to a key (in this case movies), this is a unique-global key that is used for associate the query information between the components, in this way we can re-use this hook to use the same information in anywhere of the DOM tree. If you follow the classic redux action-reducer cycle for fetching data, these hooks will save up a lot of repetitive code.

Among other things, React Query also allows us to filter the information with a simple system.

And also, to contemplate the case that the client-side alter the server state React Query introduces the concept of mutations(well known for GraphQL developers), let's make a quick example.

With onSave function we're re-fetching the information on the background while immediately change the specific information(in this case the new movie) in the user interface.

Manage cached data

Saving data that we fetched and how we save it is an important aspect of our application, it improves the sensation of speed in our interfaces, and avoids hitting the backend all the time.
One of the more important aspects of React Query that sets it apart from other libraries like SWR is the strategy and mechanism to manage the cache.
For managing cache, there are a lot of alternatives and strategies we can adopt, and in most cases, it depends a lot on the problem we need to resolve. For general cases, and more particularly for frontend cases, like pagination, infinite scroll, or just showing information, stale-while-revalidate strategy is an excellent choice.
This strategy consists of, as the name says, revalidating the information (fetching) while the old data is shown to the user. Let's put an example to make it clearer

Back to the movies example, let's say I have a video streaming platform with home, explore and user settings pages, in the image above we can see a classic flow of requests in this kind of application, when:

The user enters on the platform at the home page, all the movies are requested (Loading spinner is shown to the user)
The user goes to explore page to see the catalog of movies divided by genre, then the movies that we requested before are showed while React Query revalidates on the background (Any loading spinner is shown to the user and the response is immediate)
The user goes to the settings page, then React Query detects movie data are not used in the application so pass to the "inactive" state
After 5 minutes (or the time that you configure on the query), React Query removes the information from the cache

Final thoughts

React Query is an excellent tool with an incredible API that opens the conversation around how and why we use synchronous patterns for asynchronous data and how this impacts the way we build our applications today.