Forem: ZHANGYU

I wrote a new blog using Next.js App router

ZHANGYU — Thu, 16 May 2024 16:11:07 +0000

Before I dive into the development journey of my new blog, you might want to check it out first at my blog.

Back in 2020, React introduced Server Components. I was amazed by the possibility of writing asynchronous components.

Writing async components isn't groundbreaking per se; there was a short-lived framework before that used JSX syntax and allowed async components even on the client side.

What was novel, however, was React's support for async components, even though they could only run on the server. At that time, there wasn't a stable framework to leverage this feature. By coincidence, a new project last year required using Next.js. On my recommendation, we adopted the official App Router, seamlessly integrating React Server Components.

To master React Server Components, I decided to rewrite my blog using the App Router. Previously, my blog was built with Astro. Here’s a preview of the old blog.

My requirements for the new blog were:

Fully utilize the App Router and Server Components to optimize performance.
Adopt the latest and cutting-edge technologies.
No backend services.
Make it as visually appealing as possible.

Regarding the first point, Server Components performed admirably.

For the second point, I am currently using:

TailwindCSS — Needs no introduction.
React Aria Components — Not shadcn/ui, nor radix-ui.
@tabler/icons-react — Over 5k icons, simply astonishing.
shiki — Updated, more powerful syntax highlighting.
MDX — Write React code within Markdown.

The highlights are MDX and shiki. I aim to include as many code examples as possible in my posts, allowing readers to interact with them. shiki supports numerous plugins like diff, focus, highlight, and the best one is twoslash, which makes code blocks more user-friendly.

MDX and shiki are a match made in heaven. All these effects can run server-side without bundling any js.

For the third point, I employed a novel approach:

Using GitHub Discussions as the Blog Backend

I haven’t seen anyone else using this method. I find it more blog-friendly than using GitHub Issues. It has several distinct advantages:

Permissions Management — Only the author can post content; others can only comment (unlike GitHub Issues).
Categories — GitHub Discussions allows multiple categories (again, unlike GitHub Issues).
Tags — Customizable tags for posts with adjustable colors.
Image Uploads — Pasting an image in the Discussions input box uploads it to GitHub automatically.
Comments — Complete commenting system from GitHub, including likes, replies, and mentions (with slight differences between Discussions and Issues).

Moreover, GitHub provides a robust GraphQL API, enabling blog development with any front-end technology, even a console app.

For the fourth point:

I studied Bento design on Dribbble, drawing inspiration from various Bento-style blogs.

Current missing features in my blog:

RSS feed
Animations
More interesting Bento sections
shiki and twoslash styles

If you previewed my blog and found it appealing, you can visit my GitHub repository. It supports one-click deployment and includes a simple forking tutorial.

The Principles Behind Front-end Routing

ZHANGYU — Tue, 17 Oct 2023 07:05:51 +0000

Read on my blog.

Libraries like react-router fundamentally depend on a package called history.

history is essentially a wrapper for the native window.history API.

window.history API

window.history provides five methods:

go: Navigate to a specific page; the parameter is a number. go(1) goes forward one page, go(-1) goes back one page.
back: Equivalent to go(-1).
forward: Equivalent to go(1).
pushState: Adds a new history record.
replaceState: Replaces the current history record.

We mainly use pushState and replaceState.

pushState

The pushState method takes three arguments.

The first argument is the state object.
The second argument is the title, which is currently unused by the browser. To future-proof your code, it's advisable to pass an empty string here.
The third argument is url, which is displayed in the browser's address bar in real-time.

The state object can be accessed via window.history.state and defaults to null.

To demonstrate, open the browser's console on the current page and type window.history.pushState({state:0},"","/page"). You'll notice the browser address changes to /page.

Run window.history.state in the console; you'll see {state: 0}.

Run window.history.back() to go back a page.

replaceState

The key difference between replaceState and pushState is that replaceState replaces the current history record.

Open your console and type window.history.replaceState({state:1},"","/replace"). You'll notice the browser address changes to /replace.

Type window.history.state in the console to retrieve the current {state: 1}.

Type window.history.back() to navigate to the previous page because the last one was replaced by us.

Tracking History Changes

The browser provides a popstate event to listen to history changes. However, this cannot track changes made by pushState or replaceState, nor can it determine the direction of navigation (forward or backward). It tracks only changes via go, back, forward, and browser navigation buttons.

window.addEventListener("popstate", event => {
    console.log(event)
})

A Brief Dive into history's Source Code

The history library solves the limitations of native listeners. It unifies these various APIs into a single history object and independently implements listener functionality. When calling push or replace, it triggers the associated event callback functions and passes in the direction of navigation.

// createBrowserHistory

let globalHistory = window.history;

// Call it own listeners in the native popstate event
function handlePop() {
   let nextAction = Action.Pop;
   let [nextIndex, nextLocation] = getIndexAndLocation();
   // Call it own listeners
   applyTx(nextAction);
}

window.addEventListener('popstate', handlePop);

let action = Action.Pop;
let [index, location] = getIndexAndLocation();
let listeners = createEvents<Listener>();

// Call it own listeners
function applyTx(nextAction: Action, nextLocation: Location) {
   action = nextAction;
   location = nextLocation;
   listeners.call({ action, location });
}

function push(to: To, state?: any) {
   let nextAction = Action.Push;
   let nextLocation = getNextLocation(to, state);

   let [historyState, url] = getHistoryStateAndUrl(nextLocation, index + 1);
   globalHistory.pushState(historyState, '', url);
   // Call listeners when push
   applyTx(nextAction);
}

You'll notice that it merely creates its own listeners array and manually invokes them during push and replace, thereby addressing the issues of native APIs not triggering these events.

createHashHistory is almost identical to createBrowserHistory, but it additionally listens for hashchange events.

Implementing React Router from Scratch

Based on these principles, we can already write a simple router.

Below is a straightforward 20-line implementation example.

import React, { useLayoutEffect, useState } from "react";
import { createBrowserHistory } from "history";

const historyRef = React.createRef();

const Router = (props) => {
  const { children } = props;
  if (!historyRef.current) {
    historyRef.current = createBrowserHistory();
  }

  const [state, setState] = useState({
    action: historyRef.current.action,
    location: historyRef.current.location,
  });

  useLayoutEffect(() => historyRef.current.listen(setState), []);

  const {
    location: { pathname },
  } = state;

  const routes = React.Children.toArray(children);
  return routes.find((route) => route.props.path === pathname) ?? null;
};

const Route = (props) => props.children;

function App() {
  return (
    <Router>
      <Route path="/">
        <div onClick={() => historyRef.current.push("/page1")}>index</div>
      </Route>
      <Route path="/page1">
        <div onClick={() => historyRef.current.back()}>page1</div>
      </Route>
    </Router>
  );
}

In essence, different pathname are used to display different elements. However, react-router includes more complex conditions and logic. A more detailed analysis of its source code will be published soon.

This post was originally published on December 22, 2021, and was written in Chinese. As I'm currently improving my English skills, I decided to translate one of my shorter posts. You can expect more content in English from me in the future.

Thanks for reading!