Took a walk on Theresienwiese on Sunday afternoon. The sun was just right, warm and comfortable. We played and laughed. Moments like this might not come around again.

Looking back, I was still very new to photography and took a lot of bad shots. I spent the whole morning going through them and picking out some decent ones to add to the album france-paris.

I told Grok what I needed and asked it to walk me through the steps, but it didn't work out. The steps it gave were just too complicated for me to follow. So I switched to Gemini. It gave me something simpler and more doable. When I finally got the finished image, I felt a real sense of accomplishment. I think I'm starting to like Figma.

I have to say, it was not an easy route. We ended up taking over 6 hours in the end! But it was totally worth it. The scenery along the way was beautiful, through mountains and forests, past lakes and rivers.

By the time we got home, both of us had sore feet. But I'm sure we'll be feeling energetic and full of energy again tomorrow.

My English isn't great, especially when it comes to listening and speaking. The speaker was talking fast and using some complicated words, so I was pretty much burned out by the end. I really can't stand meetings, no matter when or where.

My girlfriend always complains that my photos are pretty bad, especially the ones of her. Though maybe landscape photos are a bit better. I also know I'm not naturally talented at photography, and maybe a phone camera is just a better fit for me, simpler and more convenient.

In the end, it turned out just like I thought. I found my job through English, not German. Will I keep learning German someday? Honestly, I have no idea.

I've always been frustrated by this, even though I've put a lot of time and effort into trying to get better. Nothing really seemed to work. This time, I'm trying something different: writing short daily musings. I hope I can keep it up.

Sagrada Família

Sagrada Família barely needs an introduction. Gaudí's life work, still pulling in crowds from every corner of the world. We happened to be there on the day it was officially topped out. 144 years in the making, now the tallest church in the world. The mayor and the archbishop both spoke in the square outside, the crowd was enormous, and the whole thing felt genuinely historic. Just got lucky.

From Park Güell up on the hill, we could see the whole city spread out below. Sagrada Família rose above everything else, unmistakable against the low rooftops.

Casa Batlló & Casa Milà

Casa Batlló and Casa Milà both are essential Gaudí, the kind of thing you feel obligated to see in Barcelona.

I'll be honest, I'm not really an architecture person, but Casa Batlló's facade stopped me in my tracks. The mosaic tiles are intricate and colorful, almost alive in the sunlight. Casa Milà feels grander. Different vibes, both worth a visit.

Street Walking

Some of the best moments on any trip are when you're not really doing anything, just wandering. Barcelona's winter sun is generous, and walking around without a plan felt cozy.

The pigeons at Plaça de Catalunya were something else. Hundreds of them, completely unbothered by people, waddling around like they owned the place. I'd never seen that many birds packed into one square.

We'd just gotten home and I was already looking at flights again. Maybe March, when everything starts waking up. Feels like a good time to go somewhere.

This will be my third year in Munich instead of going home. I'm planning to go to Barcelona this year, but I haven't booked my flight or put in for time off yet. Honestly though, I can't focus on work at all right now. I can't wait.

I spent two full days going back and forth on whether to add a staggered fade-in animation to my blog pages, tweaking all sorts of parameters and details, but I still couldn't get it quite right. It's always tough deciding between practicality and aesthetics.

I looked it up and found it's from the poem To the Virgins, to Make Much of Time.

It took us about an hour to get there, and then we arrived at our meeting point, Neupullach Gasthaus. Our group of about a dozen included mostly Chinese students, along with a few older ladies.

After a short wait, our guide showed up—everyone affectionately calls him "Brother Fang." He led us straight into the forest. It was peak mushroom season, and the forest floor was dotted with all kinds of mushrooms—some delicious, others definitely not for eating. Since many in the group were beginners, Brother Fang walked us through the basics on how to tell edible species from the toxic ones.

Even though it was my first real trip, my girlfriend had already taught me a few basics on our hikes, so I could recognize some common edible types. Instead of sticking close to the group, we searched the forest on our own.

After about an hour and a half, crossing through two patches of forest, our haul was pretty decent—we managed to fill up a big bag. To catch the return bus, we decided to wrap up and head home.

Once home, we went through what we'd picked: mostly Bay bolete and Red-footed bolete, plus a few Chanterelles. That night we cooked up a feast—two stir-fries that turned out delicious. We didn't find the porcini or honey mushrooms we'd hoped for, but with honey mushroom season coming up, we're already excited to try again.

Actually, next weekend's trip is already planned. After this week's rain, the forest should be bursting with mushrooms—can't wait to get back out there.

Pizza, the Real Deal

No trip to Naples would be complete without paying homage to the birthplace of pizza, and L'Antica Pizzeria da Michele was our first stop. The line was already wrapped around the block, and with more than forty thousand reviews online, we figured we were in the right place.

Inside was pretty chaotic but in a good way—dough flying through the air, waiters squeezing between crowded tables, everyone buzzing with excitement. We kept it classic and ordered a Margherita and a Marinara. When the pizzas landed on our table—charred on the edges, loaded with San Marzano tomatoes and fresh mozzarella—I finally got what all the hype was about. And the best part? The pizzas were unbelievably cheap.

Underground Wonders

The next morning found us exploring Naples' gritty city center. Everyone raves about Toledo Metro Station as "the world's most beautiful subway stop," but honestly, it was nice but not as amazing as everyone says.

The real discovery came at a bustling seafood stand where we devoured fresh mussels and clams, tasted even better with the sea breeze.

Later, we joined a tour of Napoli Sotterranea, the underground city beneath Naples. Walking through those narrow tunnels felt like stepping back in time. To finish the day, we visited Naples Cathedral. The place was dimly lit with candles, locals murmuring prayers around us, and for a moment the chaos of the city outside completely disappeared.

Ancient Pompeii

We set aside a full day for Pompeii, and it turned out to be the right call. The train ride itself was worth it—rolling past the countryside with Mount Vesuvius in the distance, both beautiful and a little eerie when you think about what happened here two thousand years ago.

Once inside the ruins, it honestly felt surreal. We wandered through stone streets, peeked into old houses and bathhouses, and tried to picture daily life frozen in time. The site is vast—we spent almost six hours walking around and still felt like we'd only seen a fraction.

The adventure didn't end there, though. A wildfire nearby shut down the train service, so we ended up packed into a replacement bus with a bunch of other sweaty, tired tourists. It was slow and chaotic, but somehow it added to the whole Pompeii experience—like the day wasn't ready to let us go just yet.

Island Paradise

The ferry ride to Capri took about fifty minutes, and the whole way it felt like we were heading straight into a postcard. The island has a reputation for being glamorous—and expensive—and it didn't take long for us to notice both.

Still, the views made up for the prices. We took a chairlift up to the top of the mountain, from the top, the whole Bay of Naples opened up around us, dotted with yachts that looked tiny from so high up. It was one of those views you just stand and stare at, trying to take it all in.

We had planned to visit the famous Blue Grotto, but the sea was too rough, so it was closed. A little disappointing, sure, but that's travel—sometimes the unexpected ends up being part of the story.

A Lemon-Scented Goodbye

On our last day we took a trip to Sorrento, a town perched high on the cliffs with views that go on forever. The place is famous for its lemons, but what I'll remember most is how calm it felt compared to Naples.

We treated ourselves to a big seafood lunch by the water, then found an old bench down by the harbor. For about an hour, we didn't do much of anything—just sat there, watching ferries come and go, while pigeons hovered around hoping for crumbs. It was one of those rare travel moments where you're not rushing anywhere. Just the sea, the sunshine, and the person you love sitting beside you.

The Real Naples

I'll be honest—Naples isn't the kind of city that tries to win you over at first sight. The traffic is crazy, the streets can feel rough around the edges, and half the time things don't seem to work the way you expect. But that's also what makes it unforgettable.

In just five days we saw a city where ancient ruins sit next to busy pizzerias, where tunnels run under crowded streets, and where chaos and beauty somehow manage to live side by side. Naples doesn't try to impress you—it just is what it is. And maybe that's why it sticks with you long after you've left.

Knowledge improvement

Writing technical articles is an excellent way to deepen your understanding of a subject. As the saying goes, "You don't truly understand something unless you can explain it to your grandmother." Writing forces you to explore topics in detail, research thoroughly, and consider different perspectives. This process not only enhances your knowledge but also helps you communicate it more effectively.

Better communication skills

Writing is more than just knowledge, it's about conveying your thoughts clearly and effectively. Good communication skills are vital in all areas of life, and writing articles is a practical way to refine them.

Improve English

If English isn't your first language, writing articles can significantly improve your proficiency. Through consistent practice, you'll expand your vocabulary, refine your grammar, and boost your confidence in both writing and speaking.

Public exposure

Publishing articles regularly establishes you as an authority in your field. This can open doors to new opportunities, such as career advancements or collaborations. Additionally, well-written articles earn respect within your professional community, which can help you negotiate better roles or benefits.

Financial opportunities

Writing technical articles can also provide a source of extra income. While it might not replace your primary job, it can still play a meaningful role in your financial stability.

By starting your journey as a technical writer, you'll not only grow personally and professionally but also contribute valuable knowledge to others.

The OneDrive client on macOS is limited to a single sync folder, while the folder I want to sync is on an external drive. I tried to use a symlink to mount that folder into the OneDrive directory. However, this approach is not supported on macOS.

With the help of AI, I found Rclone. It can bypass the limitations of the OneDrive client and sync any folder directly to the cloud.

What bisync does

Rclone has a command called bisync that keeps two locations in sync:

• Add a file locally, it shows up in the cloud
• Add a file in the cloud, it shows up locally
• Delete a file on either side, it gets deleted on the other

Install rclone

brew install rclone

Connect to OneDrive

rclone config

Follow the steps:

1. Type n to create a new config
2. Name it onedrive
3. Choose Microsoft OneDrive
4. Press enter to skip client_id and secret
5. Choose your account type (personal or business)
6. Log in in the browser when it opens
7. Finish setup

Check if it works:

rclone lsd onedrive:

If you see your folders, it is ready.

First-time setup

Before running bisync for the first time, you need to pass --resync to build the initial baseline. This tells rclone to scan both sides and record their current state. Future syncs compare against this snapshot to detect changes.

If the two sides already have different files, the result might not be what you expect.
Run with --dry-run first to preview what will happen. Back up anything important before proceeding.

I also recommend using --check-access. It requires a file called RCLONE_TEST in both folders. If it is missing, the sync will stop. This is a simple safeguard against mistakes like a wrong path or an unmounted drive. Create the files first:

# Create locally
touch /Users/xin/Documents/SyncTest/RCLONE_TEST
 
# Create on OneDrive
rclone touch onedrive:SyncTest/RCLONE_TEST

Then run the initial sync:

rclone bisync /Users/xin/Documents/SyncTest onedrive:SyncTest \
  --resync \
  --check-access \
  --recover \
  --resilient \
  --create-empty-src-dirs \
  --max-delete 50 \
  --conflict-resolve newer \
  --verbose \
  --progress

Here is what each flag does:

Daily sync

After the first run, drop --resync and add --track-renames:

rclone bisync /Users/xin/Documents/SyncTest onedrive:SyncTest \
  --check-access \
  --recover \
  --resilient \
  --create-empty-src-dirs \
  --max-delete 50 \
  --conflict-resolve newer \
  --track-renames \
  --log-file=/tmp/rclone-bisync.log \
  --progress

Sync script

Typing that command every time is tedious. I do not need automatic or scheduled syncing, so I wrote a short script to run it manually when I want.

#!/bin/bash
 
LOCAL="/Users/xin/Documents/SyncTest"
REMOTE="onedrive:SyncTest"
LOG_FILE="/tmp/rclone-bisync.log"
 
echo "🔄 Syncing $LOCAL <-> $REMOTE"
 
rclone bisync "$LOCAL" "$REMOTE" \
  --check-access \
  --recover \
  --resilient \
  --create-empty-src-dirs \
  --max-delete 50 \
  --conflict-resolve newer \
  --track-renames \
  --log-file="$LOG_FILE" \
  --progress
 
if [ $? -eq 0 ]; then
  echo "✅ Done"
else
  echo "❌ Sync failed. Check the log: $LOG_FILE"
  exit 1
fi

Make it executable before running:

chmod +x sync.sh

Just Enjoy it.

Something beautiful
All natural pine, faux fur and a bit of soho vibes for the classy minimalist.

Natural, restrained, with a touch of warmth, exactly what I was after. I've switched everything over to Rosé Pine now: VSCode, Antigravity, Obsidian, and naturally, my blog.

The Palette

Rosé Pine uses semantic color naming where each color has a clear purpose:

You can find the full color values on their palette. With this palette, my theme definition stays incredibly clean, one line per color variable, with light and dark modes all in one place:

/* https://rosepinetheme.com/palette/ingredients/ */
:root {
  --color-base: light-dark(hsl(32deg 57% 95%), hsl(246deg, 24%, 17%));
  --color-surface: light-dark(hsl(35deg 100% 98%), hsl(248deg, 24%, 20%));
  --color-overlay: light-dark(hsl(33deg 43% 91%), hsl(248deg, 21%, 26%));
  --color-muted: light-dark(hsl(257deg 9% 61%), hsl(249deg, 12%, 47%));
  --color-subtle: light-dark(hsl(248deg 12% 52%), hsl(248deg, 15%, 61%));
  --color-text: light-dark(hsl(248deg 19% 40%), hsl(245deg, 50%, 91%));
  --color-love: light-dark(hsl(343deg 35% 55%), hsl(343deg, 76%, 68%));
  --color-gold: light-dark(hsl(35deg 81% 56%), hsl(35deg, 88%, 72%));
  --color-rose: light-dark(hsl(3deg 53% 67%), hsl(2deg, 66%, 75%));
  --color-pine: light-dark(hsl(197deg 53% 34%), hsl(197deg, 48%, 47%));
  --color-foam: light-dark(hsl(189deg 30% 48%), hsl(189deg, 43%, 73%));
  --color-iris: light-dark(hsl(268deg 21% 57%), hsl(267deg, 57%, 78%));
}

Theme Switching

The traditional approach to light/dark themes requires media queries or class names, maintaining separate color declarations:

/* The old way: define each variable twice */
:root {
  --color-base: hsl(32deg 57% 95%);
}
 
@media (prefers-color-scheme: dark) {
  :root {
    --color-base: hsl(246deg 24% 17%);
  }
}

This works, but when you have lots of color variables, maintenance becomes a pain.

The light-dark() function was introduced in CSS Color Module Level 5. It takes two parameters for light and dark mode values:

/* Basic syntax */
color: light-dark(<light-value>, <dark-value>);
 
/* Works with various color formats */
color: light-dark(black, white);
color: light-dark(rgb(0 0 0), rgb(255 255 255));
color: light-dark(var(--light), var(--dark));

Before using it, you need to declare color-scheme to tell the browser which color schemes your page supports:

:root {
  color-scheme: light dark;
}

Compared to the traditional approach, light-dark() keeps both colors on the same line, less code and the relationship is immediately clear. Since 2024, major browsers have all shipped support, so it's production-ready.

If you look closely, you'll notice my site's favicon uses a gradient from Love to Gold—warm and cozy, which is exactly the feeling I'm going for.

In this article, we'll explore how to solve this problem using JavaScript's Set object, which naturally ensures uniqueness among its elements.

The Problem with Random Generation

When you call Math.random() multiple times, there's always a chance of getting duplicate values, especially when working with smaller ranges or generating many numbers. For example:

// This might produce duplicates
const numbers: number[] = [];
for (let i = 0; i < 5; i++) {
  numbers.push(Math.floor(Math.random() * 10) + 1);
}
console.log(numbers); // Could be [3, 7, 3, 9, 1] - notice the duplicate 3

Leveraging Sets for Uniqueness

Sets in JavaScript automatically handle uniqueness—they simply ignore attempts to add duplicate values. This makes them perfect for our use case. Here's our strategy:

1. Create a Set to store our unique numbers
2. Define our parameters: how many numbers we need and the range to draw from
3. Generate and collect random numbers until we have enough unique values
4. Convert to array for easier manipulation

Here's a robust function that generates unique random numbers:

const generateRandomNumbers = (
  count: number,
  min: number,
  max: number,
): number[] => {
  const rangeSize = max - min + 1;
  // Validation: ensure we're not asking for more numbers than possible
  if (count > rangeSize) {
    throw new Error("Count cannot be greater than the size of the range");
  }
  if (count <= 0) {
    throw new Error("Count must be a positive number");
  }
  if (min > max) {
    throw new Error("Minimum value cannot be greater than maximum value");
  }
 
  const uniqueNumbers: Set<number> = new Set();
 
  // Keep generating until we have enough unique numbers
  while (uniqueNumbers.size < count) {
    const random = Math.floor(Math.random() * rangeSize) + min;
    uniqueNumbers.add(random);
  }
 
  return Array.from(uniqueNumbers);
};
 
console.log(generateRandomNumbers(5, 5, 10));

Performance Considerations

This method works well for most use cases, but be aware that as the ratio of count to rangeSize approaches 1, the algorithm may need many iterations to find the remaining unique values.

For such scenarios, you might consider alternative approaches like:

• Generating all possible numbers and shuffling the array
• Using a rejection sampling method with tracking

Wrapping Up

By combining JavaScript's Math.random() with the uniqueness properties of Sets, we can easily generate collections of unique random numbers. This approach is clean, readable, and handles edge cases gracefully.

The key takeaway? When you need uniqueness in randomness, don't fight against duplicates—use data structures that naturally prevent them.

Han Script and Han Characters

Let's start by understanding two fundamental concepts:

• Han Script is a writing system that originated from Chinese and was later adopted by Japanese, Korean, and other languages
• Han Characters (CJK Ideographs) are the basic units of Han Script

Many countries and regions in the Han cultural sphere have developed their own character encoding standards. Unicode unifies these standards, aiming to achieve lossless conversion between original standards and Unicode encoding.

Character Sets & Encodings

What's the difference between Unicode, GBK, and UTF-8? They are actually concepts from different domains.

Character Sets

Common character sets like Unicode and ASCII are designed to represent characters with a series of numbers, also known as code points.

ASCII uses one byte to represent a character, defining encodings for 128 characters that correspond to English characters and binary values.

For Asian languages like Chinese, more bytes are needed to represent a single character. For example, GB2312 (for Simplified Chinese) uses two bytes per character, allowing representation of up to 65,536 characters (256 x 256).

The existence of multiple encoding systems meant that the same binary number could be interpreted as different symbols. Reading text with the wrong encoding results in garbled characters. This is why Unicode was created.

Unicode is a unified character set that assigns a unique code to every symbol in the world. This uniqueness eliminates character encoding confusion.

Character Encodings

Unicode is just a character set - it defines binary codes for symbols but doesn't specify how to store these codes. To save characters in computers, they must first be encoded.

UTF-8 is one of Unicode's encoding methods and the most widely used on the internet. Other implementations include UTF-16 (using two or four bytes per character) and UTF-32 (using four bytes per character).

UTF-8's main feature is its variable-length encoding, using 1-4 bytes per symbol depending on the character.

GBK (Chinese Internal Code Specification) is similar to UTF-8 but specifically for Chinese characters. It's an extension of GB2312.

In summary: ASCII and Unicode are character sets, while UTF-8 and GBK are encoding methods. They serve different purposes and cannot be directly compared.

In summary:

• Character sets (e.g., Unicode, ASCII) define mappings between characters and codes.
• Encodings (e.g., UTF-8, GBK) specify how those codes are stored.

Regex for Chinese Characters

Now that we understand character sets and encodings, let's return to our main topic. What exactly do we mean by "Chinese characters" in terms of character sets?

Unicode unifies characters from different encoding standards based on three dimensions: semantics, abstract shape, and typeface. Characters with the same origin, meaning, and similar shapes are given the same encoding. These encoded characters are called CJK Unified Ideographs, which we referred to as "Han Characters" earlier.

The regex /[\u4e00-\u9fa5]/ matches the CJK Unified Ideographs block included in Unicode 1.0.1. Before Unicode 3.0 (1992-1999), this expression correctly matched all Han characters. This regex is likely over 20 years old.

However, Unicode has evolved significantly, with version 10.0.0 released in June 2017. Many new Han characters have been added over these 20 years, falling outside the range of this regex. We need a modern solution that keeps up with Unicode standards.

Here's a maintenance-free regex for matching Han characters:

const HanZi = /\p{Unified_Ideograph}/u;
 
!!"你好".match(HanZi); // true

It's called Unicode property escapes and already available in Chrome 64, Firefox 78, Safari 11.1 and Node.js 10.

• \u is a regex flag defined in ECMAScript 2015, treating the pattern as Unicode code point sequences
• \p is a Unicode property escape defined in ECMAScript 2018, enabling pattern construction based on Unicode character properties
• Unified_Ideograph is a binary property of Unicode characters: Yes for Han characters, No for others

\p{Unified_Ideograph} matches all Unicode characters with Unified_Ideograph=yes. The implementation depends on the Unicode version of the runtime, freeing developers from maintaining specific code point ranges.

Similar Unicode Property Escapes

/\p{Ideographic}/u;

This matches all characters with Ideographic=yes, including CJK Unified Ideographs, Tangut characters and components, Nüshu, CJK compatibility characters, Suzhou numerals, " 〇 ", and the Japanese letter-ending mark "〆".

Using /\p{Ideographic}/u is too broad for matching Han characters as it includes Tangut, Nüshu, and compatibility characters.

/\p{Script=Han}/u;

The Script property selects characters that:

1. Share common graphical features and historical development
2. Are used to represent textual information in a writing system

Script=Han includes all CJK Unified Ideographs, compatibility characters, Suzhou numerals, " 〇 ", "〆", " 々 ", and commonly used radicals in dictionaries.

/\p{Script=Han}/u matches all characters in the Han Script, including radicals and modifiers that either lack independent meaning or cannot exist independently. This regex confuses the scope of Han Script with Han Characters.

Summary

1. /[\u4e00-\u9fa5]/ is outdated, don't use this 20-year-old regex
2. /\p{Unified_Ideograph}/u is correct, maintenance-free and matches all Han characters
3. /\p{Ideographic}/u and /\p{Script=Han}/u match additional characters beyond Han characters and are incorrect for this specific purpose

Ref:

• Unicode character class escape
• Unicode Regular Expressions

At first I used string.length as the filename byte count, which resulted in an identifier error. After I checked the wiki documentation, I have a new perception of character encoding.

Unicode Code Points

The charCodeAt() method of String values returns an integer between 0 and 65535 representing the UTF-16 code unit at the given index.

The codePointAt() method of String values returns a non-negative integer that is the Unicode code point value of the character starting at the given index. Note that the index is still based on UTF-16 code units, not Unicode code points.

Unicode code points range from 0 to 1114111 (0x10FFFF). charCodeAt() always returns a value that is less than 65536, because the higher code points are represented by a pair of 16-bit surrogate pseudo-characters. Therefore, in order to get a full character with value greater than 65535, it is necessary to retrieve not only charCodeAt(i), but also charCodeAt(i + 1), or to use codePointAt(i) instead.

So we use codePointAt(i) method to get the Unicode code point value at the given index.

const charCode = str.codePointAt(i)

UTF-8

UTF-8 is a variable-length Unicode encoding format that uses one to four bytes to encode each character.In the following table, the x characters are replaced by the bits of the code point:

Information about UTF-8 encoding on Wikipedia: UTF-8 Encoding.

So we can count the number of bytes in each code point character in segments and then add them up to get the total number.

It's important to note that the higher code points are represented by a pair of 16-bit surrogate pseudo-characters, so when the UTF-16 code units is greater than 0x10FFFF, the index should be an additional 1.

/**
 * @description Calculating the number of bytes in a UTF-8 encoded string
 * @param  str - Target string
 * @return The number of bytes in the target string
 */
const stringByteUTF8 = (str: string): number => {
  let total = 0
  let charCode: number
  for (let i = 0, len = str.length; i < len; i++) {
    charCode = str.codePointAt(i)
 
    if (charCode <= 0x007f) {
      total += 1
    } else if (charCode <= 0x07ff) {
      total += 2
    } else if (charCode <= 0xffff) {
      total += 3
    } else {
      total += 4
      i++ // the index should be an additional 1
    }
  }
  return total
}

UTF-16

UTF-16 encodes up to 65535 with two bytes, and beyond 65535 with four bytes.

So the code to calculate the number of bytes in a UTF16 string is relatively simple.

/**
 * @description Calculating the number of bytes in a UTF-16 encoded string
 * @param  str - Target string
 * @return The number of bytes in the target string
 */
const stringByteUTF16 = (str: string): number => {
  let total = 0
  let charCode: number
  for (let i = 0, len = str.length; i < len; i++) {
    charCode = str.codePointAt(i)
 
    if (charCode <= 0xffff) {
      total += 2
    } else {
      total += 4
      i++
    }
  }
  return total
}

Final Code

/**
 * @description Calculating the number of bytes in a string
 * @param  str - Target string
 * @param  charset - Encoding format of the target string
 * @return The number of bytes in the target string
 */
type Charset = "utf-8" | "utf-16"
 
const stringByte = (str: string, charset: Charset = "utf-8") => {
  let total = 0
  let charCode: number
 
  if (charset === "utf-8") {
    for (let i = 0, len = str.length; i < len; i++) {
      charCode = str.codePointAt(i)
 
      if (charCode <= 0x007f) {
        total += 1
      } else if (charCode <= 0x07ff) {
        total += 2
      } else if (charCode <= 0xffff) {
        total += 3
      } else {
        total += 4
        i++
      }
    }
  } else if (charset === "utf-16") {
    for (let i = 0, len = str.length; i < len; i++) {
      charCode = str.codePointAt(i)
 
      if (charCode <= 0xffff) {
        total += 2
      } else {
        total += 4
        i++
      }
    }
  }
 
  return total
}

Q.E.D.

What is AbortController?

The AbortController interface represents a controller object that allows you to abort anything when desired.

Here's how you use it:

const controller = new AbortController()
 
controller.signal
controller.abort()

Creating a controller instance provides you with two key components:

• AbortController.signal: an instance of AbortSignal, which can be used to communicate with, or to abort, an asynchronous operation.
• AbortController.abort(): aborts an asynchronous operation before it has completed. When called, triggers the abort event on the signal. It also updates the signal to be marked as aborted.

You might wonder where the actual abort logic resides. Here's the elegant part—you define it! Simply listen for the abort event and implement your cancellation logic as needed:

controller.signal.addEventListener("abort", () => {
  // Implement the abort logic.
})

Now, let's explore which standard JavaScript APIs have built-in support for AbortSignal.

Usage

Event listeners

You can provide an abort signal when adding an event listener for it to be automatically removed once the abort happens.

For example, calling controller.abort() removes the resize listener from the window. That is an extremely elegant way of handling event listeners because you no longer need to separately define the listener function for later removal with .removeEventListener().

const listener = () => {}
 
// window.addEventListener('resize', listener)
// window.removeEventListener('resize', listener)
 
const controller = new AbortController()
window.addEventListener('resize', listener, { signal: controller.signal })
controller.abort()

This pattern is especially useful when different parts of your application need to manage listener cleanup, as passing around an AbortController instance is much cleaner than sharing function references.

One of the most powerful features is the ability to use a single signal to manage multiple event listeners simultaneously!

useEffect(() => {
  const controller = new AbortController()
 
  window.addEventListener("resize", handleResize, {
    signal: controller.signal,
  })
  window.addEventListener("hashchange", handleHashChange, {
    signal: controller.signal,
  })
  window.addEventListener("storage", handleStorageChange, {
    signal: controller.signal,
  })
 
  return () => {
    // Calling `.abort()` removes ALL event listeners
    // associated with `controller.signal`. Gone!
    controller.abort()
  }
}, [])

The example above demonstrates how a single useEffect() hook can manage multiple event listeners with different purposes. The cleanup is beautifully simple - one call to controller.abort() removes all listeners at once!

Fetch requests

The fetch() API also integrates seamlessly with AbortSignal. When an abort event is triggered, any pending request will be cancelled, and its promise will reject.

function uploadFile(file: File) {
  const controller = new AbortController()
 
  // Provide the abort signal to this fetch request
  // so it can be aborted anytime be calling `controller.abort()`.
  const response = fetch("/upload", {
    method: "POST",
    body: file,
    signal: controller.signal,
  })
 
  return { response, controller }
}

In this example, uploadFile() starts a file upload and returns both the response promise and the controller. This makes it easy to cancel uploads when needed, such as when users click a "Cancel" button.

AbortSignal provides several convenient static methods that make request handling even easier.

AbortSignal.timeout

The AbortSignal.timeout() method offers a concise way to create time-limited operations. It automatically aborts after the specified duration - perfect for adding request timeouts without manual AbortController setup:

fetch(url, {
  // Abort this request automatically if it takes
  // more than 3000ms to complete.
  signal: AbortSignal.timeout(3000),
})

AbortSignal.any

Similar to how you can use Promise.race() to handle multiple promises on a first-come-first-served basis, you can utilize the AbortSignal.any() static method to group multiple abort signals into one.

const publicController = new AbortController()
const internalController = new AbortController()
 
channel.addEventListener("message", handleMessage, {
  signal: AbortSignal.any([publicController.signal, internalController.signal]),
})

The example above shows two controllers working together: a public one that lets code consumers trigger aborts, and an internal one for our own cleanup needs. Either controller can remove the message listener independently.

When any signal provided to AbortSignal.any() aborts, it triggers the combined signal to abort as well. Once aborted, subsequent abort events from other signals are ignored.

Streams

You can use AbortController and AbortSignal to cancel streams as well.

const stream = new WritableStream({
  write(chunk, controller) {
    controller.signal.addEventListener('abort', () => {
      // Handle stream abort here.
    })
  },
})
 
const writer = stream.getWriter()
await writer.abort()

The WritableStream controller provides a signal property that works just like any other AbortSignal. Calling writer.abort() triggers the abort event on this signal, allowing for clean stream cancellation.

Abort error handling

Each abort event can carry a custom reason, enabling you to handle different cancellation scenarios in distinct ways.

You can provide an abort reason when calling controller.abort(), and later access it through the signal's reason property to determine why the operation was cancelled.

const controller = new AbortController()
 
controller.signal.addEventListener("abort", () => {
  console.log(controller.signal.reason) // "user cancellation"
})
 
// Provide a custom reason to this abort.
controller.abort("user cancellation")

The reason argument can be any JavaScript value so you can pass strings, errors, or even objects.

Ref:

• MDN AbortController
• Don't Sleep on AbortController

<p> // ReactElement = JSX.Element
  <Custom> // ReactElement = JSX.Element
     {true && "test"} // ReactNode
  </Custom>
</p>

A ReactElement is an object with a type and props.

type Key = string | number
 
interface ReactElement<P = any, T extends string | JSXElementConstructor<any> = string | JSXElementConstructor<any>> {
  type: T
  props: P
  key: Key | null
}

A ReactNode is a ReactElement, a ReactFragment, a string, a number or an array of ReactNodes, or null, or undefined, or a boolean.

type ReactText = string | number
type ReactChild = ReactElement | ReactText
 
interface ReactNodeArray extends Array<ReactNode> {}
type ReactFragment = {} | ReactNodeArray
 
type ReactNode = ReactChild | ReactFragment | ReactPortal | boolean | null | undefined

JSX.Element is a ReactElement, with the generic type for props and type being any. so they are more or less the same.

declare global {
  namespace JSX {
    interface Element extends React.ReactElement<any, any> {}
  }
}

Components return:

render(): ReactNode;

And functions are "stateless components":

interface StatelessComponent<P = {}> {
  (props: P & { children?: ReactNode }, context?: any): ReactElement | null
  // … doesn't matter
}

• TS class component: returns ReactNode with render(), more permissive than React/JS
• TS function component: returns JSX.Element | null, more restrictive than React/JS

A stagger animation makes child elements animate one after another with a delay. Instead of all animating at once, each element appears in sequence, creating a smooth, rhythmic effect.

While looking for blog design inspiration, I noticed that Paco Coursey blog and the Rosé Pine official website had much smoother stagger enter animations. So I dove into their source code to see how they implemented it.

How It Works

After studying the source code, I found the implementation is pretty simple. The core idea is using CSS variables and animation delays to control when each element enters.

[data-animate] {
    --stagger: 0;
    --delay: 120ms;
    --start: 0ms;
    animation: enter 0.6s both;
    animation-delay: calc(var(--stagger) * var(--delay) + var(--start));
}
 
@keyframes enter {
    0% {
        opacity: 0;
        transform: translateY(10px);
    }
 
    to {
        opacity: 1;
        transform: none;
    }
}

Then in HTML, you use it like this:

<p style="--stagger: 1" data-animate>Hello, I'm Shiyu.</p>
<p style="--stagger: 2" data-animate>A curious soul with big dreams.</p>
<p style="--stagger: 3" data-animate>Full-Stack Developer</p>

The core principle is calculating different delay times for each element. Each element has a --stagger value representing its position in the sequence. When multiplied by a fixed delay interval, elements play their enter and upward slide animations in order.

Since this approach uses native CSS animations, it performs much better and feels smoother than Framer Motion's stagger animations. I immediately switched to this native solution.

Automation Approach

While implementing the new animations, I realized that manually adding data-animate and setting --stagger values for every element was a real pain. It gets even worse when you need to add animations to content rendered by third-party components, like MDX components, which requires invasive modifications. So I started looking for simpler automation approaches.

My first thought was CSS Counters, which can automatically increment variables based on usage count, achieving auto-incrementing --stagger values that can even work across element hierarchies—similar to how Framer Motion works.

But reality hit hard. As of now, variables defined by CSS Counters can't participate in calc() method calculations because counter values are treated as string types and can't be used in mathematical operations.

Just when I was about to give up, I discovered the sibling-index() function in a GitHub issue. It returns the current element's index within its parent element, and unlike counters, this value can actually be used in calculations.

This allows the code above to be greatly simplified:

 
.animate-auto {
	--delay: 120ms;
	--start: 0ms;
}
 
.animate-auto > p {
	--stagger: sibling-index();
	animation: enter 0.6s both;
	animation-delay: calc(var(--stagger) * var(--delay) + var(--start));
}

All you have to do is add animate-auto to the parent element, and all child elements automatically get the animation effect. The only limitation is that it can only calculate sibling element indices, so it can't add animations across hierarchical levels. But I'm already quite satisfied with the current effect—what more could I ask for?

If you also want to add this kind of smooth stagger animation to your website, give this approach a try!

In react, both useEffect and useRef are marked as an escape hatch.

Why Escape Hatches?

Why are ref and effect categorized in the escape Hatches? This is because both operate on factors that are 「out of React's control」.

What is handled in effect is the side effects. For example:

• document.title is modified in useEffect. document.title does not belong to the state in React, React can not sense his changes, so it is classified in effect.
• making the DOM focus requires calling element.focus(), and the direct execution of the DOM API is not controlled by React.

Although they are factors out of React's control, React also wants to prevent them from getting out of control as much as possible in order to ensure the robustness of the application.

To use the ref prop, you can assign it a callback function that receives the DOM element as an argument，you can then access the DOM element using the current property of the ref object.

import React, { useRef } from "react"
 
function MyComponent() {
  const ref = useRef(null)
  return <div ref={ref}>Hello, World!</div>
}

Out-of-Control Ref

In react, ref allows you to access the DOM elements of a component directly. This can be useful if you need to manipulate the element's style or if you want to trigger an action based on the element's position in the DOM.

First, look at the case where it is not out of control.

• Execute ref.current's focus, blur, etc. methods
• Execute ref.current.scrollIntoView to scroll the element into the view
• Execute ref.current.getBoundingClientRect to measure the DOM size

In these cases, although we manipulate the DOM, they involve factors outside of React's control, so they are not considered out of control.
But in the following cases.

• Execute ref.current.remove to remove the DOM
• Execute ref.current.appendChild to insert a child node

These are also DOM operations, but they are within React's control, so performing these operations via ref is out of control.

Here is an example of an out of control situation caused by using Ref to manipulate the DOM.

export default function Counter() {
  const [show, setShow] = useState(true)
  const ref = useRef(null)
 
  return (
    <div>
      <button
        onClick={() => {
          setShow(!show)
        }}
      >
        Toggle with setState
      </button>
      <button
        onClick={() => {
          ref.current.remove()
        }}
      >
        Remove from the DOM
      </button>
      {show && <p ref={ref}>Hello world</p>}
    </div>
  )
}

Button 1 removes the P-node by means of React control.
Button 2 removes the P-node by manipulating the DOM directly.

If these two ways of removing P-nodes are mixed, then clicking button 1 and then button 2 will report an error.

This is the result of the runaway situation caused by using Ref to manipulate the DOM.

How to limit runaway

Now the question arises, since it is called out of control, it is React can not control, so how to limit the loss of control?

In React, components can be divided into：

• Low-order components
• High-order components

Low-order components are those that are wrapped based on the DOM, such as the following components, which are wrapped directly based on input nodes.

In lower-order components, it is possible to point the ref directly to the DOM.

function MyInput(props) {
  const ref = useRef(null)
  return <input ref={ref} {...props} />
}

Higher-order components are those that are based on lower-order component wrappers, such as the following Form component, based on the Input component wrapper.

function Form() {
  return (
    <>
      <MyInput />
    </>
  )
}

Higher-order components cannot point ref directly to the DOM. This restriction keeps the scope of ref runaway within a single component, and there will be no runaway ref across components.
Take the example in the document, if we want to click a button in the Form component to operate the input focus.

function MyInput(props) {
  return <input {...props} />
}
 
function Form() {
  const inputRef = useRef(null)
 
  function handleClick() {
    inputRef.current.focus()
  }
 
  return (
    <>
      <MyInput ref={inputRef} />
      <button onClick={handleClick}>input聚焦</button>
    </>
  )
}

When clicked, an error is reported as follows.

This is because passing a ref to MyInput in the Form component fails, inputRef.current does not point to the input node.
The reason for this is that React does not support passing refs across components by default, as mentioned above, in order to keep the scope of refs out of control within a single component.

Artificially removing the restriction

If you must remove this restriction, you can use the forwardRef API to explicitly pass the ref.

const MyInput = forwardRef((props, ref) => {
  return <input {...props} ref={ref} />
})
 
function Form() {
  const inputRef = useRef(null)
 
  function handleClick() {
    inputRef.current.focus()
  }
 
  return (
    <>
      <MyInput ref={inputRef} />
      <button onClick={handleClick}>Focus the input</button>
    </>
  )
}

With the use of forwardRef it is possible to pass ref across components.In the example, we pass inputRef from Form across components to MyInput and associate it with input.

The intent of forwardRef is clear: since the developer manually calls forwardRef to break the restriction that prevents a runaway ref, he should know what he is doing and should take the corresponding risk himself.

Also, with the presence of forwardRef, it is easier to locate the error after a ref-related error occurs.

useImperativeHandle

In addition to restricting the passing of ref across components, there is another measure to prevent ref from getting out of control, and that is useImperativeHandle.

Since refs get out of control because they use DOM methods that shouldn't be used (like appendChild), I can restrict refs to only have methods that can be used.

Modifying our MyInput component with useImperativeHandle.

const MyInput = forwardRef((props, ref) => {
  const realInputRef = useRef(null)
  useImperativeHandle(ref, () => ({
    focus() {
      realInputRef.current.focus()
    },
  }))
  return <input {...props} ref={realInputRef} />
})

Now, the Form component can only fetch the following data structure through inputRef.current：

{
  focus() {
    realInputRef.current.focus();
  },
}

It eliminates the situation where the developer takes the DOM by ref and then executes the API that should not be used, and the ref gets out of control.

Summary

Normally, the use of ref is relatively rare, and he exists as an escape hatch.

To prevent misuse/abuse that leads to ref getting out of control, React restricts that by default, ref cannot be passed across components.

To break this restriction, forwardRef can be used.

To reduce the misuse of ref on DOM, you can use useImperativeHandle to restrict the data structure passed by ref.