That is one reason why I chose to develop my own Dev.to analytics dashboard to display historical data such as view, reaction and follower increase over the last 24 hours, 7 days and 30 days.

You can view the live dashboard here: https://devto-analytics.wallis.dev. You'll notice that it's styled to look like Dev.to.

Incredibly, Dev.to has recently added their own analytics page as well as having an "analytics" option on each post (next to edit, manage). There are some differences between the built-in dashboard and mine.

Why build an analytics dashboard?

I really enjoy posting on Dev.to. I recently rewrote my whole website to use Dev.to as a CMS to enable myself to continue posting here while using my own site as the canonical URL.

I wanted, however, to see more in-depth information about each post such as view, reaction and follower increases over a given period of time. By default, I didn't have access to any data that would allow me to calculate any increases.

As a result, I ended up building my own analytics dashboard using Next.js, Tailwind CSS, Recharts, the Dev.to API and Azure Functions & Cosmos DB.

You can view the code on GitHub.

How I source the historical data

If you've used the Dev.to API before, you'll have noticed that, for the moment, you're unable to access any historical data. This makes it difficult to know how popular a post is over a given period of time (before the built-in analytics).

To record my historical data I created an Azure Function that saves my latest article and follower data, gathered using the Dev.to API, to a Azure Cosmos Database. The functions that save my article and follower data run every hour.

In addition, I created a couple of HTTP Azure Functions so that I can access the data.

If you're wondering, I'm entirely within the free tier on Azure - so it isn't costing me anything to record my historic data.

You can view the Azure Functions implementation on GitHub.

The dashboard

The dashboard consists of three pages:

1. Home/overview page - basically an overview of my current stats and periodical view/reaction/comment/follower increases
2. Breakdown graphs page - Charts that break down stats from the overview page so that I can easily see information such as what articles have been most read this week.
3. Summary graphs page - Charts that display the increase of views/reactions/followers from hour-to-hour and day-to-day

You can view the dashboard implementation on GitHub.

Home/overview page

The dashboard's UI is based heavily on Dev.to's styling. I wanted it to appear as an extension to Dev.to's current implementation. The home page is styled to look like an advanced version of the Dev.to dashboard page that contains your general stat overview (total page views, reactions, comments) and a list of any draft and published articles.

Moreover, it was a lot of fun essentially cloning Dev.to to try to make the dashboard look as alike as possible. Try switching between the dashboard home page and your Dev.to dashboard in different tabs!

On my dashboard, I've added follower and last posted date to the overview stats - as I care about them more than "Listing's created" and "Credits available". Most overview stats also contain two pieces of historical data. For page views, for example, I'm displaying the total page view increase for the past 24 hours and the past 7 days.

Looking further down the page, you'll see a sortable list of my published posts containing the usual stats for each (views, reactions and comments). I've also added the 24 hours, 7 days and 30 day increase for each stat, for every post.

Breakdown graphs page

This page displays graphs that break down increases for views, reactions and comments. Its purpose is to show me what posts have been most popular over a given period of time.

While its styling is based on Dev.to, unlike the home page I haven't copied a specific Dev.to page.

Summary graphs page

The final page contains graphs that details how views, reactions and comments have increased over a period of time. Using this page I can interpret such information as if my follower increases have stagnated or are increasing at a good level.

Difference between my dashboard and the built-in analytics page

If you've read this far you're likely wondering what the difference between my dashboard and the built-in Dev.to analytics dashboard. The following is my opinion, let me know in the comments if you disagree.

What Dev.to built-in analytics does better:

1. Dev.to has access to a lot more historical data so they can report your page views way back

   I'm bias, let me know if you think there are more than this.

What my dashboard does better:

1. Integrates increases/historical data into the main dashboard screen better. I'd love it if my Dev.to dashboard displayed my daily, weekly and monthly increases for each post.
2. Displays follower and last posted date in the overview stats - I don't care about listings or credits. Moreover, I'd love to display my current posting streak instead of the time since I last posted. This would help me ensure I'm on track for my 16-week badge.
3. The breakdown page makes it easy to see why my view count has risen.

Technical details

• Next.js - powers the dashboard.
  • The built-in data fetching method getStaticProps is used to preload the article and follower data at build time. Incremental Static Regeneration rebuilds the page to minimise how out of date the initially served page is.
  • useSWR fetches the current article and follower data once the page has loaded.
  • Combining getStaticProps and useSWR means that the dashboard loads fast, but will always displays the most up-to-date data.
• Azure Functions and Azure Cosmos DB
  • Saves historical data gathered using the Dev.to API.
  • Serves the data via a HTTP route for the UI to consume.
• Tailwind CSS - styling
• React-icons - various icons such as the question mark and GitHub icon on the navigation bar.
• Recharts - the chart library used on the graph pages
• TypeScript project references
  • Enable the sharing of TypeScript interfaces, and other code, between the dashboard and the Azure Functions codebases.
  • View in the common directory of the GitHub repository.
  • For more information on TypeScript project references, read my post on them.

Future improvements

There are few features that I want to add to the dashboard:

• Calculate and display my posting streak (by week) in the stat overview - should help with the 16-week streak badge.
• Average stats - such as average page views or followers gained per day.
• Predicted stats - days until I hit 100,000 page views for example.

Summary

In this post, I've introduced my Dev.to analytics dashboard that helps me understand how my stats are changing over time and identify popular posts.

Would you like to make your own dashboard like this? Have any thoughts on the dashboard? Let me know in the comments!

If you are looking to fork/clone my GitHub repository then I'll need to make the documentation a little better 😅 - it's pretty straightforward to do once your Azure Functions/Cosmos DB is set up.

P.S. Why isn't it password protected?

I'm aware that by posting this blog I'm allowing access to my private post data to anyone who stumbles across it. I'm OK with this because:

1. I want to show the dashboard off as a portfolio piece
2. I want others to be able to copy/clone it so that they can see their own historical Dev.to data
3. I couldn't come up with a reason to hide it. I understand why it is private by default but in my case, I'm happy with others seeing it.

Let me know what you think of my Dev.to analytics dashboard!

Thanks for reading!

I'm currently developing a project consisting of two separate TypeScript applications, one being a React.js dashboard and the other an Azure Function app written in Node.js. As part of the project, the dashboard calls an API in the Azure Function app. This got me thinking, as I'm in control of both the data source and the application that uses the data, is there a way that I can share certain interfaces between the two projects?

The answer is yes, since version 3 of TypeScript you can use Project References to share code between TypeScript projects. When using Project References in my project, however, I couldn't find any official examples on how to use them - hence this post!

While the implementation below is what has worked for me, if you have any improvements, let me know in the comments.

What are Project References?

Project references allow you to structure your TypeScript programs into smaller pieces. By doing this, you can greatly improve build times, enforce logical separation between components, and organize your code in new and better ways.

How to use

Take a project that consists of a frontend and a backend written in TypeScript. Both contain an interface called IData which is exactly the same. Currently, each time I make a change, I have to duplicate it in the other file (which is extremely annoying).

The directory of the project is:

myproject
- frontend
  - app.ts
  - interfaces
    - IData.ts
  - tsconfig.json
- backend
  - server.ts
  - interfaces
    - IData.ts
  - tsconfig.json

In order to use a single IData.ts file between both projects, we can use Project References.

Adding the common TypeScript project

We will start by creating a third TypeScript project called common, adding an empty tsconfig.json file and copying the IData.ts interface over. We can also remove it from the frontend and backend apps. So the directory structure will be:

myproject
- frontend
  - app.ts
  - tsconfig.json
- backend
  - server.ts
  - tsconfig.json
- common
  - interfaces
    - IData.ts
  - tsconfig.json

This isn't enough though. In the common app's tsconfig.json we need to add the following:

{
    "compilerOptions": {
        "target": "es5", // Or whatever you want
        "module": "es2015", // Or whatever you want
        "declaration": true,
        "declarationMap": true,
        "outDir": "./dist",
        "composite": true
    }
}

The key parts are:

• declaration: Generates a declaration file that the frontend and backend apps can use to reference items in the common app.
• composite: Ensures TypeScript can quickly determine where to find the outputs of the referenced project
• declarationMap: Enables editor features like “Go to Definition” and Rename to transparently navigate and edit code across project boundaries in supported editors

Referencing the common project in frontend/backend

To reference the common IData interface in the frontend and backend apps we need to make a simple change to both of their tsconfig.json files. Add the references property to your existing tsconfig.json.

{
    "compilerOptions": {
        // The usual
    },
    "references": [
        { "path": "../common" }
    ]
}

Building the frontend/backend apps

Now that we've added the reference to the common app in order to access its interfaces we need to compile both the frontend and backend apps.

When doing so, ensure you use the --build option so that TypeScript automatically builds all referenced projects.

tsc --build .

Note: If you're using Next.js with TypeScript, I didn't need to do this. Both next dev and next build kept working just the same.

Importing the common interface into frontend/backend

This is easier than you might first think, just import IData using its relative path. TypeScript will do the magic when you compile it.

import IData from '../common/interfaces/IData'

Summary

In this post, I've demonstrated how to use TypeScript Project References to use a common project for shared interfaces, functions, types and more!

Feedback on my approach is appreciated! As I said above, I couldn't find an official example to guide me on how to use Project References so any feedback in the comments will help me improve this tutorial and my own TypeScript projects!

Thanks for reading!

The error that appeared was:

Property 'slug' does not exist on type 'ParsedUrlQuery | undefined'

After doing some research and finding a discussion on the Next.js GitHub regarding this issue, I recognised it was a gap in their documentation. It explains how to add the type to getStaticProps when used on its own but it doesn't demonstrate how to access the property you've declared in getStaticPaths.

Background

getStaticProps and getStaticPaths are two methods that can be used for data fetching in Next.js. Briefly speaking getStaticProps lets you fetch data at build time and getStaticPaths enables you to specify dynamic routes to pre-render pages based on data.

For more information on these functions, read my post on different ways to fetch data in Next.js.

The error

Using the example code below I will demonstrate the TypeScript error and advise you on how to fix it. I'm using the variable name slug to create the dynamic routes, but you could use anything - another common name is id.

import { GetStaticPaths, GetStaticProps } from 'next'
import { ParsedUrlQuery } from 'querystring'

export const getStaticPaths: GetStaticPaths = async () => {
    const arr: string[] = ['slug1', 'slug2']
    const paths = arr.map((slug) => {
        return {
            params: { slug },
        }
    })
    return { paths }
}

export const getStaticProps: GetStaticProps = async (context) => {
    // This is where the error occurs
    const { slug } = context.params // Property 'slug' does not exist on type 'ParsedUrlQuery | undefined'
    const props = fetch(`/api/${slug}`)
    return { props }
}

Note the first line of the getStaticProps. Here we are attempting to access the slug variable that was created in getStaticPaths and returned inside the params object. This is the line that causes the error as context.params has the type ParsedUrlQuery | undefined and slug does not exist in ParsedUrlQuery.

const { slug } = context.params

The fix

Fortunately, fixing the issue is as simple as creating an interface that extends ParsedUrlQuery and contains a slug property.

interface IParams extends ParsedUrlQuery {
    slug: string
}

Once we've added that to the file, we need to assert that context.params is of type IParams. This is done like so:

const { slug } = context.params as IParams

It's as simple as that! Just adding the IParams interface makes the TypeScript error disappear.

Updated example code:

import { GetStaticPaths, GetStaticProps } from 'next'
import { ParsedUrlQuery } from 'querystring'

interface IParams extends ParsedUrlQuery {
    slug: string
}

export const getStaticPaths: GetStaticPaths = async () => {
    const arr: string[] = ['slug1', 'slug2']
    const paths = arr.map((slug) => {
        return {
            params: { slug },
        }
    })
    return { paths }
}

export const getStaticProps: GetStaticProps = async (context) => {
    const { slug } = context.params as IParams // no longer causes error
    const props = fetch(`/api/${slug}`)
    return { props }
}

Round up

If this post has helped you use Next.js together with TypeScript, react or let me know in the comments!

Thanks for reading!

Sources:

• Data fetching in Next.js (getStaticProps and getStaticPaths)
• GitHub discussion on the type for context.params.slug

The problem

Ever use inspect element to download images that you're unable to right-click and either save or open? You'll likely have noticed that with SVGs it's not easy to download them from a website. - or at least I did when I was attempting to "clone" a webpage for my latest project.

Take the Dev.to logo that is visible on every page on Dev.to, for example. Right-clicking on that doesn't give you the option to open it in a new tab or save it. Moreover, using inspect element only gives you the potentially huge SVG tags, leaving you to work out where the SVG begins and ends in the page's HTML.

The solution

Enter SVG Export, by Stephen Delaney is a browser extension for Google Chrome and Mozilla Firefox.

After installing the extension, clicking the extension icon will trigger SVG Export to extract all available SVGs on your current webpage, ensuring their inline styles are kept. A new tab will be opened displaying all SVGs. From there, locate the SVGs you're after and either download the SVG as a file, copy it as code or paste it into your favourite design tools like Sketch, Figma or Framer.

To download the Dev.to icon mentioned above, I simply opened any page on Dev.to, clicked the SVG Export icon to start the extract, and finally located it in the newly opened tab.

Round up

In this post, I demonstrated how I was able to easily extract an SVG from a webpage using SVG Export.

Do you have another, perhaps better, method of downloading SVGs from websites? If you do, let me know in the comments 👇

If this article has helped, drop a reaction!

Thanks for reading!

Why?

I decided to redesign and rewrite my website for several reasons:

• I wanted to move from JavaScript to TypeScript.
• The website was styled using styled-jsx, which can be a pain to maintain and IMO is a bit messy. At the moment I'm using Tailwind CSS and so far loving it and its utility-style nature; I wanted my personal website to reflect this.
• I no longer liked the design and wanted it to be cleaner and simpler.
• I wanted my blog and portfolio to be loaded dynamically from a CMS rather than having to copy+paste a new page for each entry - See the Originally published at wallis.dev at the top of this article.

Technologies used

• TypeScript - Since being introduced to TypeScript at work, I've started to understand the benefits over plain JavaScript.
• Next.js - I don't try to hide the fact that I love Next.js, it's so simple to use and to date most of my articles contain Next.js in some way.
• Tailwind CSS - Lately I've been using Tailwind CSS heavily. To quote their homepage, it enables me to "rapidly build modern websites without ever leaving [my React component]". Tailwind CSS also made it incredibly easy to add a dark mode. Also Tailwind Typography.
• Dev.to API to dynamically build the blog and portfolio pages ⬅️ My favourite feature.

Using Dev.to as a CMS

My favourite part of my website is the use of Dev.to as a Content Management System for the blog and portfolio pages. I've seen the Dev.to API utilised before to display a user's articles on their website but, AFAIK, not quite in the same way as I've applied it.

The benefits of using Dev.to as a CMS are:

1. Dev.to stores the articles and any images that are uploaded and used.
2. I can use Dev.to's editor and the ability to draft an article and publish it later.
3. Has a built-in RSS feed that I can use to share my articles to other sites such as CodeNewbie and Medium.
4. Although Dev.to has the article first, the use of a canonical URL ensures that Google and other sites see my personal website as the source site for the articles.
5. Converts the article into HTML for me. I ended up rendering the HTML from the article markdown myself, as it required fewer requests to the Dev.to API.

Disclaimer

Before I continue I want to stress that I intend to use Dev.to purely for my blog and portfolio (past projects / showdev). I won't be using Dev.to to create pages which are not articles and would cause Dev.to to become cluttered with spam if others follow suit. For example, the about section on the home page is hardcoded into the website and if I created a page for my education history, I'd keep that purely for the website and wouldn't post it to Dev.to - I'd probably use Markdown for these.

How it works

View the code on GitHub

Built using Next.js, the website uses two dynamic routing functions (getStaticPaths and getStaticProps) to generate the blog and portfolio pages.

Before an article is displayed on my website, it must meet the two following requirements:

1. Must be published (obviously)
2. Must have a canonical URL directing to my website. This enables me to pick which articles are displayed, what the article's path will be on my website (not the post ID). Moreover, an article with a canonical URL pointing to https://wallis.dev/blog/... will be built as part of my blog whereas, if its canonical URL is https://wallis.dev/portfolio/... it will be a portfolio piece.

For every article that meets the requirements, the subsequent build process is followed:

1. At build time, Next.js calls the getStaticPaths function which

   1. Fetches a list of my published articles using the Dev.to API (/api/articles/me).
   2. Converts the article's markdown to HTML.
   3. Saves the articles to a cache file for use in the next step.
   4. A dynamic page is created within the Next.js context for each article - the page slug will be the canonical URL path.

2. For each page, Next.js calls getStaticProps which fetches the page's article from the cache. The article contains the name, description and HTML.

   • I also attempted making another API request to the Dev.to API (/api/articles/{id}) to fetch the page's article, so I could use the HTML rendered by Dev.to. However, this caused build failures as I was making too many API requests at once - so now I render the markdown using remark-html.
3. Finally, the page is rendered. I use custom elements to display the article name and description and then display the HTML I rendered earlier in getStaticPaths using remark-html. For styling, I use the Tailwind Typography plugin.

To ensure that the website is always in sync with my articles on Dev.to, I use a Vercel Deploy hook which is triggered each time I create or update an article using a Dev.to webhook. I use a Deploy Hook rather than Incremental Static Regeneration so that the blog is only rebuilt when something has changed rather than at random intervals.

Note: I use Dev.to APIs that require authorisation as they seem to have a higher request limit compared to the public routes. When using public APIs and fetching each article via the article API, I found that my builds were failing with a 429 error which is Dev.to rate-limiting requests. - I probably could switch to using public APIs now that I'm using a cache to read the articles from.

I'm currently writing a detailed article which describes in greater detail how my website utilises Dev.to as a CMS, stay tuned (and follow on Dev.to to be notified when I release it)!

How it looks

Visit wallis.dev

Future improvements

1. Add syntax highlighting to code blocks like on Dev.to. Completed using highlight.js and remark-highlight.js.
2. Add a contact form using EmailJS.
3. Only rebuild the website if the content of an article has changed or one is created - reduces the website being needlessly redeployed.

Summary

In this article, I discussed rewriting my personal website from the ground up using Dev.to as a Content Management System for the blog and portfolio pages.

Like the idea of using Dev.to as a CMS for your blog? React! Found something I could improve or that you would have done differently? Let me know in the comments.

Thanks for reading!

By the way, you can view this article live on my website here.

Recently I've been using Next.js both at work and on after-work projects. Next.js is React framework that enables functionality such as server-side rendering and generating static websites. It has become my go-to technology when I'm building a frontend application, overtaking plain old React.

With Next.js you get many things out of the box such as built-in routing, automatic code splitting and it will even decide whether your app can be statically rendered or needs to be rendered server-side on every request - all of this without any configuration. In fact, when creating a new React application I default to using create-next-app as opposed to create-react-app.

During my time developing with Next.js I discovered a few features which are easy to miss when you're just getting started. Some of these features helped me solve some problems I was having with my application.

Features you should check out 🤩

1. Export your Next.js application into static HTML using next export.

   • Giving you the ability to run it without a running Node.js server while still being able to make data-fetching requests at build time using getStaticProps. This feature bridges the gap between Next.js and its longtime alternative Gatsby which is exclusively a static site generator.
   • I've used next export to host a Next.js site on GitHub Pages (although with issues that were solved with the subsequent feature).

2. The next.config.js assetPrefix and basePath options.

   • On its own assetPrefix allows you to prefix all URLs to assets, like images, so that you can use assets hosted on a CDN. While basePath provides the ability to host the app on the subpath of a domain such as https://domain.com/app-on-this-subpath.
   • In the past I've utilised next export, assetPrefix and basePath together to host a Next.js app on GitHub Pages - without assetPrefix and basePath you are unable to host a Next.js project on GitHub pages (without a custom domain) as it puts them on a subpath.

3. Incremental Static Regeneration.

   • A feature of getStaticProps which allows you to regenerate a static page while your app is running. It works by triggering a page rebuild in the background, which fetches updated page data, and replaces the existing HTML page with the newly generated one once the build has completed.
   • I haven't tried this feature but will in the future as it is a better alternative to completely rebuilding a static Next.js application each time data that it relies on changes.

4. Internationalized (i18n) routing.

   • If you're building a website that will be available in different countries, this feature is a game-changer. It makes supporting multiple languages simpler by enabling you to provide a list of supported locales which Next.js can read and automatically set up routing to ensure that users see the correct locale for their country. You can assign a default locale that will be used when no matching locale is detected for a user. Next.js supports both domain routing (example.com, example.fr) and subpath routing (example.com/en, example.com/fr) meaning it doesn't restrict how you plan to host your application.
   • If I ever decide to make my website multi-lingual or work on a global project, this is a feature I will definitely be using.

5. Measuring Performance - reportWebVitals.

   • Next.js contains a built-in relayer allowing you to analyse and measure the performance of your application. To activate this you use the built-in function reportWebVitals. Next.js calls reportWebVitals with a single metrics parameter, an object containing various properties such as an id, the startTime of a metric and a value which can be the duration of a metric. This function will be called when running on the client-side. In development, you can simply log out the values to easily measure the performance of your application. In production, however, you can use this function to send the metrics to your own analytical service. They supply an example of this for use with Google Analytics.
   • I haven't used reportWebVitals but in the future I'll add it to my Google Analytics article. I use reportWebVitals on my personal website.
   • Using the following function should provide more accurate metrics than plain Google Analytics usage:

     export function reportWebVitals({ id, name, label, value }) {
     // Use `window.gtag` if you initialized Google Analytics as this example:
     // https://github.com/vercel/next.js/blob/canary/examples/with-google-analytics/pages/_document.js
     window.gtag('event', name, {
     event_category:
     label === 'web-vital' ? 'Web Vitals' : 'Next.js custom metric',
     value: Math.round(name === 'CLS' ? value * 1000 : value), // values must be integers
     event_label: id, // id unique to current page load
     non_interaction: true, // avoids affecting bounce rate.
     })
     }
     

Bonus

• The incredible amount of examples available in the Next.js GitHub repository.

  • If you haven't already stumbled onto them, the Next.js GitHub repository contains an examples directory that is full of examples. These show you how to use technologies such as Tailwind CSS, TypeScript and various CMSs such as Contentful with Next.js. You can use create-next-app to download an example.

  • When I am incorporating new technology into an existing Next.js application, the example directory is the first place I check for guidance on how to integrate it.

Final words

These are just a few of the features that Next.js includes that can automatically improve your application without having to install any external dependencies.

If you liked this article, hit the like button. Something I can do better? Leave a comment!

Thanks for reading!

It's easy to add to your site and in minutes you'll go from having no clue how people are using your website to being able to record and analyse every detail on every interaction a user has with your website.

I'll split this post up into 3 parts:

1. What we're doing
2. How to add Google Analytics to Next.js
3. FAQs - A lot of the Google Analytics tutorials don't explain why you should do things a certain way. For example, why are we using this Next.js _document.js file and what does it do? or how to I get a GA_MEASUREMENT_ID?

Key takeaway if you're glancing at this article:

Adding Google Analytics to a Next.js project is easy and you can copy and paste the code below. I wouldn't use an external NPM module as you're just adding another dependency that can become outdated in the future.

Why add Google Analytics

Google Analytics is a web analytics service offered by Google that tracks and reports website traffic.

I've recently begun adding Google Analytics to every website that I've developed including wallisconsultancy.co.uk which I recently developed alongside a series of tutorial blog posts. Google Analytics is great at tracking website usage and more, although I currently use it purely to monitor user count, most popular pages and page performance which is all reported on the Google Analytics dashboard.

A Google Analytics dashboard

In addition to the above, it's free and takes minutes to set up with a Next.js project (if you follow this post 😉).

Adding Google Analytics to a Next.js project

Prerequisites

1. A Next.js project hosted on a domain that can be used with Google Analytics preferably with at least one page. - Vercel (creators of Next.js) is the easiest place to host your website.
2. A Google Analytics account with a created property and the ID (known as a GA_MEASUREMENT_ID) that is given to you and is used to identify your website with Google. Keep the GA_MEASUREMENT_ID handy, you'll need it. - I've covered this in the FAQs if you haven't used Google Analytics before.

Add/modify the _document.js file in your Next.js project

Create a custom _document.js file in your pages directory and add the following code: If you're using TypeScript, check out this custom _document.tsx on GitHub instead.

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

class MyDocument extends Document {
  static async getInitialProps(ctx) {
    const initialProps = await Document.getInitialProps(ctx);
    return { ...initialProps };
  }

  render() {
    const GA_MEASUREMENT_ID = 'GA_MEASUREMENT_ID'; // Paste your GTAG here
    return (
      <Html lang="en">
        <Head>
          <script
            async
            src={`https://www.googletagmanager.com/gtag/js?id=${GA_MEASUREMENT_ID}`}
          />
          <script
            // eslint-disable-next-line react/no-danger
            dangerouslySetInnerHTML={{
              __html: `
                window.dataLayer = window.dataLayer || [];
                function gtag(){dataLayer.push(arguments);}
                gtag('js', new Date());
                gtag('config', '${GA_MEASUREMENT_ID}', {
                  page_path: window.location.pathname,
                });
              `,
            }}
          />
        </Head>
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    );
  }
}

export default MyDocument;

If you've already got a custom _document.js then the key parts are within the Head component (remember to add the GA_MEASUREMENT_ID variable):

<Head>
  <script
    async
    src={`https://www.googletagmanager.com/gtag/js?id=${GA_MEASUREMENT_ID}`}
  />
  <script
    // eslint-disable-next-line react/no-danger
    dangerouslySetInnerHTML={{
      __html: `
        window.dataLayer = window.dataLayer || [];
        function gtag(){dataLayer.push(arguments);}
        gtag('js', new Date());
        gtag('config', '${GA_MEASUREMENT_ID}', {
          page_path: window.location.pathname,
        });
      `,
    }}
  />
</Head>

Explanation:

• In the first script tag the Google Analytics JavaScript file is loaded into the browser.
• In the second script tag the Google Analytics code is initialised and tracking is started on the current page.

Once you've added your GA_MEASUREMENT_ID and pushed your changes into a live environment such as Vercel, you should see data appearing on your Google Analytics dashboard - if you don't, try visiting your website!

And that is all it takes to add Google Analytics to your Next.js application - told you it was easy!

FAQs

What does the code above load onto my website?

The gtag.js is a script which allows you to send event data to Google, in this case it's used for Google Analytics. Read more about it and the GA_MEASUREMENT_ID at Google Developers - gtag.js.

What is a GA_MEASUREMENT_ID and how do I get one?

The GA_MEASUREMENT_ID is the ID of the Google Analytics property that you want to collect data for. To get a GA_MEASUREMENT_ID you need to create a new property on Google Analytics - you can follow this Google Support article to learn how to sign up to Google Analytics and create a property.

What are the _document.js and _app.js files in a Next.js project?

The Next.js specific _document.js and _app.js are two special files that live in the pages directory but are not rendered as pages by Next.js (you can't reach /_document in your browser).

Note: The Head component used in _document.js's Head different to next/head and should be used for common code on every page.

_document.js is rendered server-side only and controls the <html> and <body> tags of HTML. It can be used to add custom elements into your <html> tag that will be the same on every page such as the Google Analytics code or a favicon.

_app.js is rendered client-side, potentially on every page change. It's essentially a wrapper around each Next.js page that you have. It can be used to maintain a consistent layout on each page, add a custom CSS stylesheet or persist state on a page change.

You can read more about these on the Next.js website:

• Custom _document.js
• Custom _app.js

Why use the _document.js file over _app.js?

The Head component (from next/document) that is used in _document.js is rendered serverside whereas the Head component (from next/head) in _app.js will update on each page change meaning that the Google Analytics script may be reloaded which could slow down the site.

Round up

If anything I've said has helped you add Google Analytics to your site, give me a reaction.

Any more questions? Let me know in the comments!

Thanks for reading the article!

The finished website: https://wallisconsultancy.co.uk The source code: https://github.com/james-wallis/wallisconsultancy

Motivation

Wallisconsultancy.co.uk is a website that I developed in 2016, just after I finished my first year at the University of Portsmouth. One of my modules was a Web Fundamentals course which explained the basics of HTML & CSS with a sprinkling of JavaScript at the end. I wanted a summer project with the aim that I would be a much better HTML and CSS developer next year when I was asked to build a web-based dashboard as a part of the Web Programming coursework.

The original Wallis Consultancy website

The original website was written using in 2011 in HTML and CSS using a PHP backend. As of 2016 the design was outdated and was not responsive rendering it unusable for anyone on a device with a small screen. Over the summer I rewrote the site using HTML, CSS and the Bootstrap framework and gave it a PHP backend so that I could reuse certain aspects of the page and make a general layout. Given that it was my first professional website, I was pretty happy with the result. In 2018 I moved it from a GoDaddy server to a Docker container to make it cheaper to run and easier for me to maintain.

The current Wallis Consultancy website

It’s now 2020 and I have been requested to make changes to the website. While it can be said that it’s working perfectly in its current condition, adding new pages and subtle features are difficult due to its reliance on HTML. Additionally, my skillset has improved know that this site will benefit from my experience using Next.js, a React.js framework that specialises in building server rendered, SEO friendly sites. In addition, as uses a Bootstrap Template, it came with a lot of CSS and JavaScript that is unused and in no way optimised. Next.js does a nice job of minifying the JavaScript and Tailwind CSS, a CSS framework, will help to reduce the amount of CSS I need to create and remove anything that is unused.

Why Next.js

When a website is built using React.js the clients browser is required to run JavaScript and construct the page itself, this is bad for two reasons.

1. There might be a few seconds before the website can be used by the client. - Bad user experience.
2. For SEO - although search engines are being improved to handle JavaScript applications there is no guarantee that the search bot will render the application correctly. For this reason it is still preferred to send static HTML to the client.

Next.js solves these problems by statically generating and server-rendering a React application meaning we can send rendered HTML to the client as opposed to large JavaScript files.

Next.js has other noteworthy features such as:

• Automatic Code Splitting - Rendered pages only contain the JavaScript they need, rather than a single JavaScript file for all pages.
• Built in Routing - To create a new page, just add a file in the pages folder
• Prefetching - Using the Link component we can tell Next what pages the user is able to visit, Next responds by pre-fetching the content required for the page in the background so there is no load times between pages.
• A Next app can be exported to static HTML - This is a huge feature that was released in Next.js 9.3 websites to be run through Github pages.

Next.js

Why Tailwind CSS

Tailwind CSS describes itself as a utility-first CSS framework for rapidly building custom designs. It works by having an existing library of CSS classes that you can add to a React.js component using the className prop. To add a height of 100% you add the class h-full to the component, this is an improvement to giving a component a classname and then opening a CSS file to define what you want the class to do - it makes styling a component a fast process.

For responsive sites, there exists the intuitive {screen}: prefix which makes it easy to control responsive classes, for a desktop all that is the lg prefix next to the styling e.g. lg:h-full .

The default configuration can be overridden using a tailwind.config.js file and additional classes can be added to the framework so that there is never a need to use the style attribute.

Finally, TailwindCSS.com has a search utility that makes finding a class name extremely easy. If you need to know how to use a border radius, you can search it on the website and within seconds make the change to your code. This means that there is nothing to learn when picking up Tailwind CSS for the first time as its so easy to find on their website.

Tailwind CSS - A Utility-First CSS Framework for Rapidly Building Custom Designs

The Plan

In the next few posts, I will rewrite wallisconsultancy.co.uk using Next.js and TailwindCSS in order to achieve the following goals:

• Make it easier to maintain
• Enhance the SEO using Next.js third-party libraries such as next-seo and next-image-optimizer
• Host on Github pages to save money
• Add a Recaptcha to reduce the amount of email spam received And I’ll do all this while ensuring that the look of the page stays the same - with a few subtle tweaks.

Round up

In this blog I introduced wallisconsultancy.co.uk and explained that over the next few blogs I am going to rebuild it using Next.js and Tailwind CSS.