Javascript

How to Build a Blog with Next.js, Tailwind CSS and MDX

Published Mar 1, 2022

Updated Feb 13, 2023

5 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Intro

Today, we will build a blog website with Next.js, Tailwind, and MDX without using a CMS at all!

What is MDX?

MDX is a combination of Markdown and JavaScript. MDX allows you to use JSX in your markdown content. You can import components, such as interactive charts or alerts, and embed them within your content. This makes writing long-form content with components a blast.

Why will we use MDX?

We will use MDX because it’s so powerful, and you can write more interactive articles with it! Also, you will not need to pay any money for a CMS!

Let’s Start

Here is the project that we will build using Next.js, Tailwind CSS and MDX Blog.

First, let’s create a new Next.js project:

npx create-next-app next-blog

After it’s done, go to the project directory:

cd next-blog

Then, run the dev server:

npm run dev

Install Tailwind CSS

Installing Tailwind CSS with Next.js is simple.

First, we need to add some dev dependencies.

npm install -D tailwindcss postcss autoprefixer

Then, Initialize Tailwind CSS.

npx tailwindcss init -p

You will find that there are two new files that have been added to the project

tailwind.config.js
postcss.config.js

Now, we need to tell Tailwind CSS where to find the classes. Go to tailwind.config.js, and add these lines under content.

content: [
    "./pages/**/*.{js,ts,jsx,tsx}",
    "./components/**/*.{js,ts,jsx,tsx}",
],

Go to the styles/globals.css and add these three lines:

@tailwind base;
@tailwind components;
@tailwind utilities;

And restart the dev server. You will find that the design has been changed like that:

That means it has been installed successfully 🎉

Build the Layout

We will create a very simple layout. Just add the main content in between a header and a footer.

Let's create a new folder called components, and add three new components inside it.

Layout.js
Header.js
Footer.js

I'll leave the Header.js and Footer.js to you. Let's start from Layout.js:

import Header from "./Header";
import Footer from "./Footer";

function Layout({ children }) {
  return (
    <div className="container mx-auto max-w-5xl flex flex-col min-h-screen px-4">
      <Header />
      <main className="flex-1">{children}</main>
      <Footer />
    </div>
  );
}

export default Layout;

Important Tip: For some accessibility each page should have one <header></header>, one <main></main>, and one <footer></footer>.

Next Step, we need to wrap the whole application with our Layout.js but how?

This is possible in Next.js since the pages/_app.js is a wrapper for the whole app.

function MyApp({ Component, pageProps }) {
  return (
    <Layout>
      <Component {...pageProps} />
    </Layout>
  );
}

export default MyApp;

Finally let's go to pages/index.js and delete everything with this code.

export default function Home() {
  return (
    <div>
      <h1>Hello world</h1>
    </div>
  );
}

`getPosts` function

We have the layout now! Let's work on the functionality.

Create a new folder in the root directory and call it posts. Then, add some articles.

Then, create another folder called helpers where we will add most used functions.

Create a new file helpers/getPosts.js. After it, we will need to install a package called gray-matter. It's necessary to parse the mdx file content.

npm i gray-matter

And we will use this package to separate between the frontmatters, and the actual content of each post.

We need only three important items in each post: title, date and description. For example:

And this is how gray-matter works:

import matter from "gray-matter";

const { data, content } = matter(fileContent)

where data is an object with the frontmatters data and content is the actual post.

Second, we need to get a list of all the files inside the posts folder.

import fs from "fs";
import path from "path";

const files = fs.readdirSync(path.join("posts"));

files should return an array with the file names.

[
  "hello-world.mdx",
  "markdown-guide.mdx"
]

Then, we need to loop through to get each one's data one by one.

const allPostsData = files.map((fileName) => {
    const slug = fileName.replace(".mdx", "");
    const fileContents = fs.readFileSync(
      path.join(`posts/${slug}.mdx`),
      "utf8"
    );
    const { data } = matter(fileContents);
    return {
      slug,
      data,
    };
  });

And return allPostsData from the getPosts function.

`getPost` function

It's a simpler version from getPosts function, we will pass the slug, and it should return the post data and content.

const getPost = (slug) => {
  const fileContents = fs.readFileSync(path.join(`posts/${slug}.mdx`), "utf8");
  const { data, content } = matter(fileContents);
  return {
    data,
    content,
  };
};

First, we need to create getStaticProps function on the home page.

export const getStaticProps = () => {
  const posts = getPosts();

  return {
    props: {
      posts,
    },
  };
};

Then, let's get the posts in the page component.

export default function Home({ posts }) {
  return (
    <div>
      <h1 className="mt-24 mb-12 font-bold text-3xl">Latest Posts</h1>
      {posts.map((post) => (
        <PostCard
          key={post.slug}
          title={post.data.title}
          date={post.data.date}
          description={post.data.description}
          slug={post.slug}
        />
      ))}
    </div>
  );
}

The post page

This is the final step in the project when we will display the posts. In Next.js, to add a page with parameter in its path, you should name it between brackets. In our example, we will add [slug].js in the pages directory.

We need to handle things in this page:

`getStaticPaths`:

We need this function in Next.js to tell it how many pages should be build in the build time from this page.

export const getStaticPaths = async () => {
  const posts = await getPosts();
  const paths = posts.map((post) => ({ params: { slug: post.slug } }));
  return {
    paths,
    fallback: false,
  };
};

Install `next-mdx-remote`

It allows us to compile the MDX to HTML.

npm i next-mdx--remote

`getStaticProps`:

import { serialize } from "next-mdx-remote/serialize";

export const getStaticProps = async ({ params }) => {
  const post = await getPost(params.slug);
  const mdxSource = await serialize(post.content);
  return {
    props: {
      data: post.data,
      content: mdxSource,
    },
  };
};

use `MDXRemote` to display the post:

import { MDXRemote } from "next-mdx-remote";

function Post({ data, content }) {
  return (
    <div>
      <h1 className="font-bold text-7xl mt-24 mb-12">{data.title}</h1>
      <time className="text-gray-500 italic">{data.date}</time>
      <p className="mt-12">
        <MDXRemote {...content} />
      </p>
    </div>
  );
}

Style the post content

After applying all of the above, you will find the post page like this.

So we have to style it, install @tailwindcss/typography plugin.

npm i @tailwindcss/typography

Then, add it to plugins in tailwind.config.js.

plugins: [
  require("@tailwindcss/typography")
]

Finally, add the prose class to the MDXRemote container.

Final result:

Here, you can find the code for the complete project: Next.js, Tailwind CSS and MDX Blog

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Mark Shenouda
@MarkSShenouda @markshenouda

Communication Between Client Components in Next.js

Communication Between Client Components in Next.js In recent years, Next.js has become one of the most popular React frameworks for building server-rendered applications. With the introduction of the App Router in Next.js 13, the framework has taken a major leap forward by embracing a new approach to building web applications: the concept of server components and client components. This separation of concerns allows developers to strategically decide which parts of their application should be rendered on the server and which are then hydrated in the browser for interactivity. The Challenge: Communicating Between Client Components While server components offer numerous benefits, they also introduce a new challenge: how can client components within different boundaries communicate with each other? For instance, let's consider a scenario where you have a button (a client component) and a separate client component that displays the number of times the button has been clicked. In a regular React application, this would typically be accomplished by lifting the state to a common ancestor component, allowing the button to update the state, which is then passed down to the counter display component. However, the traditional approach may not be as straightforward in a Next.js application that heavily relies on server components, with client components scattered across the page. This blog post will explore three ways to facilitate communication between client components in Next.js, depending on where you want to store the state. Lifting State to a Common Client Component One approach to communicating between client components is to lift the state to a common client component. This could be a React context provider, a state management system like Zustand, or any other solution that allows you to share state across components. The key aspect is that this wrapper component should be higher up in the tree (perhaps even in the layout) and accept server components as children. Next.js allows you to interleave client and server components as much as you want, as long as server components are passed to client components as props or as component children. Here's how this approach might look in practice. First of all, we'd create a wrapper client component that holds the state: ` This wrapper component can be included in the layout: ` Any server components can be rendered within the layout, potentially nesting them several levels deep. Finally, we'd create two client components, one for the button and one for the counter display: ` ` The entire client and server component tree is rendered on the server, and the client components are then hydrated in the browser and initialized. From then on, the communication between the client components works just like in any regular React application. Check out the page using this pattern in the embedded Stackblitz window below: Using Query Params for State Management Another approach is to use query params instead of a wrapper client component and store the state in the URL. In this scenario, you have two client components: the button and the counter display. The counter value (the state) is stored in a query param, such as counterValue. The client components can read the current counter value using the useSearchParams hook. Once read, the useRouter hook can update the query param, effectively updating the counter value. However, there's one gotcha to this approach. If a route is statically rendered, calling useSearchParams will cause the client component tree up to the closest Suspense boundary to be client-side rendered. Next.js recommends wrapping the client component that uses useSearchParams in a boundary. Here's an example of how this approach might look. The button reads the current counter value and updates it on click by using the router's replace function: ` The counter display component is relatively simple, only reading the counter value: ` And here is the page that is a server component, hosting both of the above client components: ` Feel free to check out the above page in the embedded Stackblitz below: Storing State on the Server The third approach is to store the state on the server. In this case, the counter display component accepts the counter value as a prop, where the counter value is passed by a parent server component that reads the counter value from the database. The button component, when clicked, calls a server action that updates the counter value and calls revalidatePath() so that the counter value is refreshed, and consequently, the counter display component is re-rendered. It's worth noting that in this approach, unless you need some interactivity in the counter display component, it doesn't need to be a client component – it can be purely server-rendered. However, if both components need to be client components, here's an example of how this approach might look. First, we'll implement a server action that updates the counter value. We won't get into the mechanics of updating it, which in a real app would require a call to the database or an external API - so we're only commenting that part. After that, we revalidate the path so that the Next.js caches are purged, and the counter value is retrieved again in server components that read it. ` The button is a simple client component that calls the above server action when clicked. ` The counter display component reads the counter value from the parent: ` While the parent is a server component that reads the counter value from the database or an external API. ` This pattern can be seen in the embedded Stackblitz below: Conclusion Next.js is a powerful framework that offers various choices for implementing communication patterns between client components. Whether you lift state to a common client component, use query params for state management, or store the state on the server, Next.js provides all the tools you need to add a communication path between two separate client component boundaries. We hope this blog post has been useful in demonstrating how to facilitate communication between client components in Next.js. Check out other Next.js blog posts we've written for more insights and best practices. You can also view the entire codebase for the above snippets on StackBlitz....

Jun 21, 2024

5 mins

NextJSReact

The CSS / Utility hybrid approach with Tailwind v4

Just recently, the progress on the next major version of Tailwind CSS was open-sourced, along with a preview post. This is very exciting news to me, and I love the direction they’ve taken with this release. Tailwind can be a pretty polarizing topic among developers, but I believe that we can find some common ground and live in harmony. In this post, we’ll look at how the CSS + Tailwind hybrid approach is getting an upgrade in v4 and some of the patterns that we can take advantage of to provide a stellar styling experience on our websites. The hybrid approach It doesn’t matter what your personal take on Tailwind is, the fact is utility classes are an incredibly useful pattern for styling websites with CSS. I’m not sold on the hard-line, all-or-nothing approach that Tailwind has always recommended. Having a class string that extends way off the screen on an ultra-wide monitor is not pretty. Combining traditional CSS classes with utility classes helps cut down on the styling noise in your markup and provides some advantages when applied correctly. This post will cover some useful patterns and best practices for using CSS and Tailwind in harmony Tailwind going “CSS-native” In the v4 introduction post, they state A major goal of Tailwind CSS v4.0 is making the framework feel CSS-native, and less like a JavaScript library. I love that they are heading in this direction, and I’m imagining Tailwind as the toolkit for styling websites with CSS. It is going to replace the plethora of tools from the past and provide support for all the modern niceties like: * Importing CSS files with @import * Vendor prefixing _(no more autoprefixr)_ * Improved browser support for modern features like CSS nesting and media query ranges. This means less worry for us as developers. We can write our code and build our sites using the modern features that the platform provides without sweating all the other details and edge cases. The talented folks at Tailwind and the open-source community have our backs. Tailwind v4 CSS configuration The biggest step in the “CSS-native” direction and the feature that I’m most excited about is the CSS configuration. This is great for embracing CSS and Tailwind as one instead of two factions at battle. If you’ve been using Tailwind exclusively for a long time like I have, you might be out of touch with all the great features and tools that CSS provides out of the box now. This is a great opportunity to get back to learning and using the platform. In Tailwind v4 we do our configuration and theming with CSS variables. To get an idea of what this looks like check out the default theme on GitHub. In our configuration we can override any values from the default theme or extend it with new values. ` All the values from the theme are exposed as CSS variables. We can reference them in our CSS files or directly in our utility classes. ` ` Best practices for combining CSS with utility classes I can understand why Tailwind recommends using strictly utility classes. It’s easy to shoot yourself in the foot and run into the issues that utility classes set out to solve in the first place. I believe if you follow some general guidelines you can safely have the best of both worlds. Create focused/specialized classes CSS tends to get messy when we use classes that are overly specific with styles that apply to just one or a small number of use cases. Take a calendar where the days are custom checkboxes. You might have some pretty specialized styles for this bit of UI. ` Notice that we just add some specific styles that apply to this use case. This gives us the flexibility to keep composing our styles with utility classes. Some things are better left to utilities The best way to avoid wandering too far off the path of enlightenment is to stick with utility classes for certain (most?) things. Spacing and layouting are examples of things that are probably best left to utility classes. These typically vary all across a page, and encoding them in a class will make it a lot less flexible. A code smell to look out for: If you have abstracted something to a class and you end up overriding certain aspects of its styles in different places. Those styles should probably be utility classes. Classes as components Tailwind has always recommended using a component system for your UI components so that your utility classes are all defined in a single place. You don’t want to have to edit 50 different files to make a change to the style of your buttons across your website. I’ve found that defining things that might be simple “components” like buttons, badges, links, etc as classes works just as well in most cases. You can use Tailwind CSS with the @apply directive or traditional class definitions for this: ` You can even bring the BEM naming convention back to compose variants on top of base component styles. (or name them however you’d like!) ` Now we can easily define badges in our markup: ` Modern CSS and other interesting utility hybrid patterns I think a lot of us are realizing that modern CSS is pretty great. There are a ton of awesome new features gaining support across major browsers, like CSS nesting, container queries, and more! More and more people are also coming around to the utility of utility classes. If you want to dive deeper and see other interesting approaches and patterns when combining modern CSS with utility classes, check out the post: Modern CSS patterns in Campfire. Summary I’m looking forward to the Tailwind CSS configuration and other awesome updates coming in v4. Using Tailwind doesn’t have to be a one-size-fits-all approach. If you want to write some CSS, I say go for it! Hopefully, some of the points in this post will lead to success if you decide to do so....

May 10, 2024

4 mins

Tailwind CSSCSS

Export Your Data from Universal Analytics before you lose it

Introduction In 2023, Google announced the retirement of Universal Analytics and told everyone to migrate to Google Analytics 4, commonly known as GA4. Google Analytics has long been a staple for businesses and website owners seeking insights into their audience and performance metrics. However, with the introduction of Google Analytics 4, there comes a pivotal moment for users of the older Universal Analytics (UA) platform. Difference between UA and GA4 What data will you lose? You will lose ALL of the historical data! By July 1, 2024, Google will delete all UA data, and you will no longer have access to it after that. Also, Universal Analytics will no longer track new conversions, affecting ad campaign performance that relies on these conversions for Smart Bidding. Audience lists from Universal Analytics will also disappear, potentially impacting media activation and performance. API requests tied to Universal Analytics properties will fail, preventing data deletion requests and causing Looker Studio to stop displaying Universal Analytics data. Additionally, Attribution Projects (beta) in Google Analytics will be deleted. How to Export Your Data There are multiple ways to export your data from Google Analytics, such as using the Google Analytics add-on for Google Sheets or using BigQuery integration to export historical data from your Universal Analytics 360 property. This article will discuss the easiest way to export your data using the Google Analytics add-on from Google Workspace Marketplace. From “Extensions” > “Google Analytics” > “Create new report” The Google Analytics extension will display a Wizard that requires the following steps: * Set a name for your report * Then, you select the Google Analytics account * Then, the property you want to export * Also, there are some optional configuration that helps you filter the data you want to export Then click on “Create Report,” and it will export the report for you Here is an example of the template https://docs.google.com/spreadsheets/d/1zXEBEQQk6TPeGb7-Wm2J0uM0q0XnTdJqrfikCTmYs8c/copy Running the Report After setting up the report template with the necessary configurations, users can run the report to extract their UA data into Google Sheets. Depending on the size of the dataset, the report may take some time to generate, especially for larger datasets spanning multiple years. In such cases, splitting the data into smaller chunks may be necessary to ensure efficient processing. Conclusion As Google transitions from Universal Analytics to Google Analytics 4, businesses and website owners must proactively preserve their valuable historical data. With the impending deletion of all Universal Analytics data by July 1, 2024, failing to export your data in time could result in significant data loss, affecting ad campaign performance and analytics capabilities. By following the outlined methods to export data using tools like the Google Analytics add-on for Google Sheets, you can ensure that your historical data is safely archived and accessible for future analysis....

May 23, 2024

3 mins

ToolingTips

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Building a Stripe App: A Step-by-Step Guide to QR Code Generation Why Build a Stripe App? I recently participated in an audio space with the Stripe team, and something they said really stuck with me: the Stripe app store is a growing area that isn't overly saturated yet. There's a lot of potential for new apps, and companies can use this opportunity to grow. I work at a company called This Dot Labs, and we've created several Stripe apps and even own one. After looking at the data, I can confirm that the Stripe team was right! Creating a QR Code Generator App For this tutorial, we'll build a QR code app that can take a URL and generate a code for it. This is a good use case to help you understand the ins and outs of Stripe's developer tools. Why QR Codes? QR codes are useful tools that have become common in e-commerce, restaurants, and other industries. While Stripe already has a QR code tool, we'll make our own to familiarize ourselves with their syntax and problem-solving approaches. Project Structure Before we dive into the implementation, let's look at the structure of our Stripe App QR Code project: * .vscode: Contains settings for Visual Studio Code * source/views: Holds the main application views * .gitignore: Specifies files to ignore in version control * stripe-app.json: Defines the Stripe app configuration * ui-extensions.d.ts: TypeScript declaration file for UI extensions * .build: this is where the built Stripe app gets placed. Step-by-Step Implementation 1\. Install Stripe Locally First, you need to install Stripe on your local machine. The documentation provides great instructions for this: * For Mac users: Use Brew to install * For Windows users: Download the package and add it to your environment variables You can find the details here in the stripe docs to install the Stripe CLI https://docs.stripe.com/stripe-cli When using Windows, you must do stripe login from Powershell, NOT from Git bash or any other tool. After the server is up, then you can continue using git bash for everything else. After stripe login, you need to enter stripe apps start. Once you do that, the server is up and running and you can go back to using git bash or any other tool. 2\. Install Dependencies We'll be using an extra package for QR code generation. Install it using npm: ` 3\. Set Up the Main Component Let's look at the home.tsx file, where we'll use Stripe's UI components: ` These components are similar to other UI libraries like Bootstrap or Tailwind CSS. 4\. Create the UI Structure Our app will have: * An input field for the URL * Validation using a regex pattern * Error handling for invalid URLs * QR code generation and display Here is the Home.tsx file that is located in the src/views folder ` * ContextView` is at the top level of the app where we see the Title and the link to the Stripe Docs that we placed in our Context View. * Box is how you use Divs. * Banners can be used to show notification errors or any other item you wish to display. * Textfields are input fields. * Everything else is pretty self-explanatory. 5\. Handle Content Security Policy One problem I personally ran into was when I tried to redirect users, the Stripe policies would block it since I did not express that I knew what it was doing. I had to go into the stripe-app.json file and mention the specific security policies. For this particular exercise, I kept these as null. This is my stripe-app.json file. ` 6\. Configure App Views As you can see here, the stripe-app.json file shows the views for each file I have. The Home.tsx file and the Invoice.tsx are also included This is our way of saying that for each view we have, show the app functionality on that page. Our stripe-app.json file will show it but also, the manifest.js file in our .build folder will also show the same. Any view that doesn't have a file will not show the application's functionality. So, if I were to go to transactions, the app would not show the same logic as the home or invoices page. By following these steps, you'll have a fully functional QR code generator app for Stripe. This is just a simple example, but the potential for Stripe apps is massive, especially for businesses serving e-commerce customers. If you need help or get stuck, don't hesitate to reach out, danny.thompson@thisdot.co. The Stripe team is also very active in answering questions, so leverage them as a resource. Happy coding!...

Dec 18, 2024

4 mins

stripe

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

How to Build a Blog with Next.js, Tailwind CSS and MDX

Intro

What is MDX?

Why will we use MDX?

Let’s Start

Install Tailwind CSS

Build the Layout

`getPosts` function

`getPost` function

Display the posts menu on the home page

The post page

`getStaticPaths`:

Install `next-mdx-remote`

`getStaticProps`:

use `MDXRemote` to display the post:

Style the post content

Mark Shenouda

You might also like

Communication Between Client Components in Next.js

The CSS / Utility hybrid approach with Tailwind v4

Export Your Data from Universal Analytics before you lose it

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Let's innovate together!

You might also like

Communication Between Client Components in Next.js

The CSS / Utility hybrid approach with Tailwind v4

Export Your Data from Universal Analytics before you lose it

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Intro

What is MDX?

Why will we use MDX?

Let’s Start

Install Tailwind CSS

Build the Layout

getPosts function

getPost function

Display the posts menu on the home page

The post page

getStaticPaths:

Install next-mdx-remote

getStaticProps:

use MDXRemote to display the post:

Style the post content

Mark Shenouda

Communication Between Client Components in Next.js

The CSS / Utility hybrid approach with Tailwind v4

Export Your Data from Universal Analytics before you lose it

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Let's innovate together!

Communication Between Client Components in Next.js

The CSS / Utility hybrid approach with Tailwind v4

Export Your Data from Universal Analytics before you lose it

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

`getPosts` function

`getPost` function

`getStaticPaths`:

Install `next-mdx-remote`

`getStaticProps`:

use `MDXRemote` to display the post: