DEV Community: Chen Hui Jing

Designing a who-pays-the-fee interface

Chen Hui Jing — Sat, 21 Mar 2026 11:44:48 +0000

I still walk around with cash in my wallet. Not a lot of it, but enough to pay for at least a meal plus a drink. Where I live today, most people can get by their day with just their mobile phone. I've had friends lose their wallet and not realise until a few days later because they simply didn't need it. If they misplaced their phone, it'd be a different matter, I'm sure.

Paying for stuff and giving other people money happens mostly digitally these days. Not a major deal these days, especially within a country. India has UPI, Brazil has Pix, the Southeast-asian countries have their own digital payment systems often tied to either a national ID or mobile number. Usually, within a country, these systems don't incur extra fees. If I send my friend SGD10, my friend receives SGD10. Straightforward.

Things get more complicated when you're dealing with cross-border payments. For myself, until 2023 when I ran into some friends I hadn't seen in a while in Spain during WeyWeyWeb, we were still having trouble paying each other after a meal.

Cross-border payment interfaces

I think most people have heard of Wise, if you're in Singapore, you might have heard of Youtrip. And I'm sure each region has their own preferred cross-border payment service of sorts.

Without going into the details of currency exchange, those of us who have had to handle multiple currencies would understand that fees are involved. Many fees involving different parties. I'm making a sweeping assumption that most people are not sure which part of the fees charged to us goes to who in the convoluted pipeline. But we know that the amount we pay is not the amount the recipient gets.

Honestly, I think most people don't care, but they just want to know how much to pay to ensure the recipient gets the amount they had in mind. Wise and Youtrip use the same method. Depending on how much you actually want to pay or how much you actually want the recipient to get, the app just does the calculation for you.

Back when I worked for the Interledger Foundation, they were working on a wallet product of their own. I'm not sure how the real one looks like, but this is what the test version looks like. They went with an explanation tooltip.

Cross-border is not what I'm trying to focus on here today, it's more of the fees part of the interface. And how to make it clear that someone has to pay the fees, but the sender needs to decide who.

Some blockchain background

If you don't care for blockchain or crypto, you can skip past the background straight to the interface design part.

My first experience of building anything with Circle involved something called the Cross-Chain Transfer Protocol (CCTP). If you're unfamiliar with blockchain technology, the short version is that there are many different blockchains in existence, and value on one chain needs some sort of a protocol to be transferred (or bridged) onto a different blockchain. CCTP is the native solution for USDC.

There's this thing called gas fees when you try to do anything on a blockchain, which are essentially transaction fees used to keep the network running. Most blockchains have a native currency (or token) that is used for this purpose.

So when you're trying to bridge a stablecoin like USDC from one chain to another, you will need native tokens on both the source chain and the destination chain. This means holding 3 different cryptocurrency tokens across 2 different blockchains, yes, the UX of crypto is not the best.

Circle now provides a forwarding service for its crosschain interoperability solutions, CCTP and Gateway. It lets you not worry about native tokens for the destination gas fees by letting Circle take care of that part, and you just have to pay a small fee in USDC to use it.

So, a big part of my role is to test out our SDKs and APIs, mostly by building with them, then explaining to other people how they work. So I've built a big ole' pile of sample applications for various products. When the forwarding service was released, I wanted to build it into a couple of my bridge applications.

Bridge interface design

To test out the forwarding service, I built the most barebones interface I could think of, practically no CSS other than spacing and some font size adjustments across the form elements. The thing I spent quite a bit of time thinking about was how to present the forwarding fee.

The fee is taken out of the amount the recipient gets, which means if you wanted your recipient to get say 10 USDC, you would have to take into account the forwarding fee amount as well. You would only know the fee after you hit "Estimate Fees". If you just hit "Bridge USDC", your recipient would get the amount less the fee.

I had thought about automatically adding the fee to the amount input but that was just a bad idea. Don't mutate the user input automatically. That's the conclusion I landed on. No, the fee should be tracked separately. Cue the <output> element. I'm so fond of the <output> element for no reason. But I put the fee amount there and added a checkbox for the user to decide if they wanted to cover the fee or not.

The next issue was now to label this checkbox. I had considered options like, "you pay" versus "receiver pays", but that sounded weird. Eventually I settled on adding a "Recipient receives X USDC" note under the amount input, coupled with "Add on top" for the checkbox label. The <legend> for the <fieldset> was "Fees (USDC)" so I figured people could read it as adding the fees on top of the amount.

Now I had a more unconventional Bridge UI idea for a madlibs-style interface. This is by no means the recommended way to build a bridge application. At first, it was just a sentence, but then I realised I needed to add more and more elements just to make the logic work. Eventually, the SDK added even more features and now it looks absolutely stuffed. Oh well.

The interface itself was pretty fun to build. I had referenced Sara Soueidan's technique for hiding and styling checkboxes and radio button, as well as used the field-sizing CSS property that is unfortunately not yet supported by Firefox at the moment. If you're going to use a full-height gradient background, it might be a good idea to try background-attachment: fixed.

Wrapping up

Overall, it was an interesting thought exercise on how to convey a seemingly straightforward yet easy to misunderstand concept, on an interface that involved the transferring of value. Keeping in mind there is a high chance people will get upset if the amount transferred is not what they intended.

Anyway, if you're interested in the source code for the styling as well as how the bridging logic is implemented, here are the CodePen links for the plain interface and the madlibs interface.

Stay safe out there, my friends.

Mathematical precision in Javascript

Chen Hui Jing — Thu, 19 Mar 2026 11:44:48 +0000

In a world where most people don't read anymore, and content is written by or at least run through AI for edits, I still find writing out my own thoughts fairly self-entertaining. I guess it's largely because a majority of the blog posts on here were written for future me. If it happens to be of use to someone else, that's just a bonus.

Anyway, math. But first, long backstory about payments.

Really tiny payments

The term “micropayments” was coined by Theodor (Ted) Holm Nelson back in the 1960s. He had been working on Project Xanadu. It is very interesting to look back on this project 57 years later given the state of the internet today.

COPYRIGHT is to be handled simply within the system. Royalty will be paid automatically by the reader, or anyone making a printout, on a byte-by-byte basis; each bytesworth of royalty (or nib) is paid to the owner of its native document.

– The Xanadu* Paradigm by Ted Nelson

Ted Nelson's idea was born in a time when the technology needed to implement it simply did not exist, way before the World Wide Web, and HTTP status codes. Innovation and creativity were abundant during a time when computing was no where near mainstream, and people thought about things without the shackles of profit maximization. Just my spicy take on the state of the world.

For the longest time, because of transaction fees, tiny payments just didn't make sense. Traditional payment infrastructure was built to handle large amounts, processing a 39 cent transaction probably costs more than the transaction itself, so why would anyone bother?

However, as of time of writing (we shall see how well this blog post ages), it feels like we are on the cusp of having new financial infrastructure that better suits the nature of the internet.

Blockchains as financial rails

Blockchain technology is one of many innovations meant to modernize financial rails and payments infrastructure to better suit how the internet works. It's not the only solution, but it seems poised to become one of the most viable enhancements to existing systems.

I don't say "replacement" because my unprofessional and unqualified brain just thinks people don't like change, so the old rails will still hang around for a while. But without going into the history of blockchain technology, it is probably safe enough to say that blockchain technology brought the concept of programmable money into reality.

Although there are a handful of currencies in the Middle East that use 3 decimals (see ISO 4217), in general, people are used to 2 decimal places in their day-to-day calculations since most currencies' have cents as their smallest unit. But when you work with blockchains, you have to wrap your mind around a lot more token decimals.

For Ethereum Virtual Machine (EVM) chains, the standard is 18 decimals. On Ethereum, the native currency is ether (ETH), which is used as a form of payment for transaction fees. Wei is the smallest unit of ether, where 1 wei = 10^-18 ETH.

Solana uses 9 decimals for its native currency, SOL. Lamports are the smallest denomination used to represent SOL balances and 1 lamport = 10^-9 SOL. And given the number of blockchains that exist, I'm sure there are a plethora of different choices for token decimals among them.

Stablecoins poised for mainstream adoption

When I talk to my friends who are unfamiliar with cryptocurrencies, I try to explain that it is a range. On one end you have worthless (and often scammy) memecoins. And on the other end, you have stablecoins, with the most broadly used being backed by the US dollar and are essentially digital representations of the fiat currency.

In March 2026, Ethereum is widely regarded as the largest stablecoin ecosystem by onchain supply and overall infrastructure. It uses ERC-20 as the standard for Fungible Tokens. This simply means that they have a property that makes each Token be exactly the same (in type and value) as another Token.

Many stablecoins on Ethereum use 6 decimals. Honestly, I don't know why there is such a large variety of token decimal options. Perhaps the easiest answer is, because it's possible. Who knows? But because of all these decimals flying around, I found myself using BigInt more than I ever have before.

As part of my job, I'm building a lot of scripts and applications that use USDC and Circle's APIs. Depending on the API called, the response could contain values measured in basis points or percent values, human-readable decimal USDC or strings, native token smallest units or integer enum-like numerals. Just loads of different types of values.

The most common conversion I end up doing is human-readable decimal USDC to subunits and back. And so I landed on these 2 helper functions:

toUsdcSubunits() to convert a USDC string into the integer amount that APIs or smart contracts expect
formatUsdcSubunits() to

`toUsdcSubunits()`

This function is most often used when parsing user input so it's safer to take in a string, to preserve whatever the input was.

// Convert USDC to subunits (6 decimals)
function toUsdcSubunits(value: string): bigint {
  if (!/^\d+(\.\d{1,6})?$/.test(value)) {
    throw new Error(
      `Invalid USDC amount "${value}". Expected a non-negative decimal with up to 6 fractional digits.`,
    );
  }

  const [whole, decimal = ""] = value.split(".");
  return BigInt(whole) * 1_000_000n + BigInt(decimal.padEnd(6, "0"));
}

The regex validates the input and allows only digits before the decimal, an optional decimal point and 1–6 digits after the decimal. It doesn't allow for negatives, commas, currency symbols or extra formatting. The next line splits the whole and decimal parts at the decimal point.

Then the whole gets converted to USDC subunits in BigInt because they are exact whole number token amounts, so we avoid Javascript's infamous floating-point number handling. And the decimal part gets padded with zeroes until it is 6 characters long, because USDC is always 6 decimal places.

So 1.5 USDC gets converted to 1_500_000n. The n makes it BigInt and the underscores are just to help readability.

`formatUsdcSubunits()`

This function is most often used when I need to display a USDC value on the frontend, because nobody, or at least, not that many people find it intuitive to read 1455233n subunits worth of USDC. The number of decimals to display is a parameter from 0–6.

function formatUsdcSubunits(value: bigint, outputDecimals = 6): string {
  if (!Number.isInteger(outputDecimals) || outputDecimals < 0 || outputDecimals > 6) {
    throw new Error(`Invalid outputDecimals "${outputDecimals}". Expected an integer from 0 to 6.`);
  }

  const negative = value < 0n;
  let absValue = negative ? -value : value;

  if (outputDecimals < 6) {
    const divisor = 10n ** BigInt(6 - outputDecimals);
    absValue = (absValue + divisor / 2n) / divisor;
  }

  const scale = 10n ** BigInt(outputDecimals);
  const whole = absValue / scale;
  const fraction = absValue % scale;

  if (outputDecimals === 0) {
    return `${negative ? "-" : ""}${whole}`;
  }

  return `${negative ? "-" : ""}${whole}.${fraction.toString().padStart(outputDecimals, "0")}`;
}

The first bit just checks that the provided outputDecimals argument is valid.

Then, check if the value is negative (const negative = value < 0n), because if it is, the function needs to tack on a - at the end. Meanwhile, work with the absolute value (let absValue = negative ? -value : value) to make the math easier.

If the number of decimals to be displayed is less than 6, then round the number to the intended display precision. divisor is the number used to reduce the precision. So if the display is meant to be 2 decimals, the divisor is 10⁴ or 10_000n, and dividing by 10_000n shifts the number 4 places to the right in decimal terms.

scale is used to rebuild the final decimal string because after rounding the function needs to split the number into the whole number (const whole= absValue / scale) and the decimal part (const decimal = absValue % scale). scale indicates where the split should happen, and is the power of 10 that matches the number of decimal places to be shown.

If no decimals are required, just return the whole number, otherwise build out the final string by adding back the minus sign if needed, put the whole and decimal parts together and pad the decimal part with leading zeroes if required.

I find basis points annoying. Sue me.

Actually, don't sue me. I can't afford a lawyer. But my point is, basis points make my brain hurt when I'm already juggling all these decimal points 😮‍💨.

Basis points is a common thing in the finance industry because apparently they make small rate changes easier to talk about. Sure. If you say so.

async function calculateMaxFee(
  sourceDomain: number,
  destDomain: number,
  transferAmountUSDC: string, // USDC amount like "1" or "10.5"
) {
  // Convert USDC to subunits (6 decimals)
  const [whole, decimal = ""] = transferAmountUSDC.split(".");
  const decimal6 = (decimal + "000000").slice(0, 6);
  const transferAmount = BigInt(whole + decimal6);

  // Get current fee
  const response = await fetch(
    `https://iris-api-sandbox.circle.com/v2/burn/USDC/fees/${sourceDomain}/${destDomain}`,
  );
  const fees = await response.json();

  // Extract minimumFee for Fast Transfer (finalityThreshold 1000)
  const minimumFee = fees[0].minimumFee; // Fee in basis points

  // Calculate fee as percentage of transfer amount
  const protocolFee = (transferAmount * BigInt(Math.round(minimumFee * 100))) / 1_000_000n;

  // Add 20% buffer to protocol fee (protocolFee × 1.2) - result in subunits
  const maxFee = (protocolFee * 120n) / 100n;

  return maxFee; // denominated in USDC subunits (6 decimals)
}

// Use in your burn call
const maxFee = await calculateMaxFee(0, 1, "10.5");

The API returns anything between 0 and 14 bps depending on the blockchains involved in the transaction. That's why we need the protocolFee line which scales the value so it can be converted into an integer, makes sure it is a clean whole number before converting to BigInt, apply the fee rate to the transfer amount, then scales the result back down to the correct USDC subunit amount.

Ergh.

Wrapping up

Anyway, this is the first non-employer blog post I've published this year. I planned to do this earlier, but I guess I only have a specific quota of word output and most of it is being spent trying to keep my job. Until AI takes over all the things.

At least CSS will still be a hobby.

References

Database troubleshooting for Umami

Chen Hui Jing — Sat, 25 Oct 2025 11:44:48 +0000

I suck at SQL. There. I said it. I just never really had to interact with a SQL database directly over the years. So yeah, I can query a database, but managing one? Nah. My SQL knowledge is pretty much limited to SELECT * FROM something WHERE otherthing = ?.

My website uses Umami for site analytics, which was set up around October 2020. Between that blog post and now, I had migrated my database from Heroku to AWS RDS, which I did not do on my own. Someone else had set things up on AWS and sent me the database URL to connect to.

I had also migrated to Umami v2 at some point, dutifully following the migration instructions, which thankfully just worked. But then, when version v2.18.0 was released, I ran into this little error:

Error: P3018

A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

Migration name: 09_update_hostname_region

Database error code: 40P01

Database error:
ERROR: deadlock detected
DETAIL: Process 27550 waits for AccessExclusiveLock on relation 16967 of database 16401; blocked by process 26654.
Process 26654 waits for AccessShareLock on relation 16982 of database 16401; blocked by process 27550.
HINT: See server log for query details.

DbError { severity: "ERROR", parsed_severity: Some(Error), code: SqlState(E40P01), message: "deadlock detected", detail: Some("Process 27550 waits for AccessExclusiveLock on relation 16967 of database 16401; blocked by process 26654.\nProcess 26654 waits for AccessShareLock on relation 16982 of database 16401; blocked by process 27550."), hint: Some("See server log for query details."), position: None, where_: None, schema: None, table: None, column: None, datatype: None, constraint: None, file: Some("deadlock.c"), line: Some(1135), routine: Some("DeadLockReport") }

✗ Command failed: prisma migrate deploy
Error: P3018

A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

Migration name: 09_update_hostname_region

Database error code: 40P01

Database error:
ERROR: deadlock detected
DETAIL: Process 27550 waits for AccessExclusiveLock on relation 16967 of database 16401; blocked by process 26654.
Process 26654 waits for AccessShareLock on relation 16982 of database 16401; blocked by process 27550.
HINT: See server log for query details.

DbError { severity: "ERROR", parsed_severity: Some(Error), code: SqlState(E40P01), message: "deadlock detected", detail: Some("Process 27550 waits for AccessExclusiveLock on relation 16967 of database 16401; blocked by process 26654.\nProcess 26654 waits for AccessShareLock on relation 16982 of database 16401; blocked by process 27550."), hint: Some("See server log for query details."), position: None, where_: None, schema: None, table: None, column: None, datatype: None, constraint: None, file: Some("deadlock.c"), line: Some(1135), routine: Some("DeadLockReport") }

ELIFECYCLE  Command failed with exit code 1.
ERROR: "check-db" exited with 1.
ELIFECYCLE  Command failed with exit code 1.

I am not equipped to solve such errors. But I wasn't alone. Scouring GitHub revealed:

I also submitted an issue of my own, but was told to resolve my database deadlock first. Nobody really had the exact same error as I did but based on everyone else's issues, I guessed that my database was probably too large for the tiny RDS instance to cope with the migration.

Given that v3 was coming out soon, I figured now would be an excellent time to actually sit my ass down and resolve this database issue once and for all.

The most basic of basics

You need tools for troubleshooting, and the first thing is to figure out how to actually access your database. I had to finally log into the database for the first time ever (the migration was previously run via script, I didn't actually have to do anything). AWS provides this guidance on how to connect to your PostgreSQL DB instance. You need psql.

If you're on Mac OS, like me, install libpq via brew.

brew install libpq

Then add it to your PATH. I'm using fish shell so I used fish_add_path.

fish_add_path /opt/homebrew/opt/libpq/bin

Connect to your remote database. This really depends on where your database lives. For me, I used this URL pattern.

psql "postgres://dbuser:password@aws_rds_endpoint:port/db_name?sslrootcert=path_to_pem_file"

Start operation recovery

The migration borked at 09_update_hostname_region, and the migration.sql file looks like this:

-- AlterTable
ALTER TABLE "website_event" ADD COLUMN "hostname" VARCHAR(100);

-- DataMigration
UPDATE "website_event" w
SET hostname = s.hostname
FROM "session" s
WHERE s.website_id = w.website_id
    and s.session_id = w.session_id;

-- DropIndex
DROP INDEX IF EXISTS "session_website_id_created_at_hostname_idx";
DROP INDEX IF EXISTS "session_website_id_created_at_subdivision1_idx";

-- AlterTable
ALTER TABLE "session" RENAME COLUMN "subdivision1" TO "region";
ALTER TABLE "session" DROP COLUMN "subdivision2";
ALTER TABLE "session" DROP COLUMN "hostname";

-- CreateIndex
CREATE INDEX "website_event_website_id_created_at_hostname_idx" ON "website_event"("website_id", "created_at", "hostname");
CREATE INDEX "session_website_id_created_at_region_idx" ON "session"("website_id", "created_at", "region");

The migration never finished, so I first had to mark the failed migration as rolled back so we can do it all over again.

npx prisma migrate resolve --rolled-back 09_update_hostname_region

A check on the state of my database revealed that I had 1,003,518 rows to deal with and my database was on a t3.micro instance. Probably not the best combination but it is what it is.

It seemed like a better idea to run the migration in batches and commit after every batch so I could recover without having to go through the entire database all over again if something went wrong. These are the steps I went through.

Start off with some defensive session settings for my puny t3.micro instance:

SET lock_timeout = '2min';
SET statement_timeout = '60min';
SET idle_in_transaction_session_timeout = '10min';
SET maintenance_work_mem = '256MB';

Also add helper indexes in addition to the required column:

ALTER TABLE public.website_event ADD COLUMN IF NOT EXISTS hostname VARCHAR(100);

CREATE INDEX CONCURRENTLY IF NOT EXISTS session_website_id_session_id_idx
  ON public."session"(website_id, session_id);

CREATE INDEX CONCURRENTLY IF NOT EXISTS website_event_wid_sid_null_idx
  ON public.website_event(website_id, session_id)
  WHERE hostname IS NULL;

Create a helper function to fill in the rows for the newly added column:

CREATE OR REPLACE FUNCTION fill_hostname_batch(batch_size int)
RETURNS integer
LANGUAGE plpgsql
AS $$
DECLARE r_count integer;
BEGIN
  WITH chunk AS (
    SELECT w.ctid AS w_ctid, s.hostname
    FROM public.website_event w
    JOIN public."session" s
      ON s.website_id = w.website_id
     AND s.session_id = w.session_id
    WHERE w.hostname IS NULL
    LIMIT batch_size
  )
  UPDATE public.website_event w
  SET hostname = c.hostname
  FROM chunk c
  WHERE w.ctid = c.w_ctid;

  GET DIAGNOSTICS r_count = ROW_COUNT;
  RETURN r_count;
END$$;

Set the function to run in batches. I manually stopped this when it returned 0. But this took more than 24 hours. I actually had to go on a business trip before it completed so I stopped it and resumed it when I came back home.

\set batch 2000
SELECT fill_hostname_batch(:batch);
\watch 1

Create the new website_event index:

CREATE INDEX CONCURRENTLY IF NOT EXISTS website_event_website_id_created_at_hostname_idx
  ON public.website_event(website_id, created_at, hostname);

Drop the legacy session indexes:

DROP INDEX CONCURRENTLY IF EXISTS public.session_website_id_created_at_hostname_idx;
DROP INDEX CONCURRENTLY IF EXISTS public.session_website_id_created_at_subdivision1_idx;

Apply the required session column changes:

BEGIN;
SET LOCAL lock_timeout = '5s';

DO $$
BEGIN
  IF EXISTS (
    SELECT 1 FROM information_schema.columns
    WHERE table_schema='public' AND table_name='session' AND column_name='subdivision1'
  ) THEN
    EXECUTE 'ALTER TABLE public."session" RENAME COLUMN subdivision1 TO region';
  END IF;
END$$;

ALTER TABLE public."session" DROP COLUMN IF EXISTS subdivision2;
ALTER TABLE public."session" DROP COLUMN IF EXISTS hostname;

COMMIT;

Almost there now. Create the new session index:

CREATE INDEX CONCURRENTLY IF NOT EXISTS session_website_id_created_at_region_idx
  ON public."session"(website_id, created_at, region);

Finalise the migration record:

UPDATE public._prisma_migrations
SET finished_at = NOW(),
    rolled_back_at = NULL,
    logs = 'Manually completed after deadlock recovery and verified schema.'
WHERE migration_name = '09_update_hostname_region'
  AND finished_at IS NULL;

Thankfully at this point, there weren't any new errors, and it seemed like the migration went through.

Wrapping up

I ran npx prisma migrate status which told me that I had 13 pending migrations, and I went ahead and applied them with npx prisma migrate deploy. Again, no new errors, and when I finally ran the build command, it actually worked and the app compiled successfully. 🥳

Hopefully v3 doesn't involve such a mega database update. 🤞

How standards enhance the developer experience

Chen Hui Jing — Sat, 18 Oct 2025 01:14:50 +0000

My timeline of how the web has evolved is based on CSS layout eras. If you ever came across an earlier post I wrote back in March, you'll know that I started out at the tail-end of the HTML tables era and the start of the floats era.

There's even more cool stuff after Grid but I can't find my source file for this graphic

I had joined the industry as a paid developer the same year the Web Standards Project had wound down because standards were a real thing and the browser wars were over. This means I had not truly lived the wild west times of either writing a whole lot of extra code to make sure things worked in different browsers or just picked one browser and hoped for the best.

Well, now that I'm doing work in the blockchain space, I feel like I have a better understanding of how things would have been like for developers back then. When it comes to decentralised applications (dApps), Ethereum is probably considered the foundational ecosystem, given they were the first blockchain to introduce smart contracts, enabling programmable financial transactions and other interesting applications.

Little bit of background info

Ethereum has standards, which are introduced as Ethereum Improvement Proposals (EIPs). Conceptually they are grandchildren of the Python Enhancement Proposals (PEPs) process. Given that Ethereum has been around for a decade, it's a fairly long list of EIPs so far, and a good number are considered final.

There is a JavaScript API for Ethereum, defined by EIP-1193: Ethereum Provider JavaScript API. It describes how key management software (AKA wallets) need to expose their API via a JavaScript object, known as a "Provider". This Provider allows the application to make Ethereum RPC requests and respond to state changes in the Provider’s Ethereum chain, Client, and Wallet.

At first this was fine, because the software wallet space wasn't that crowded, most people were just using Metamask. It's considered the first wallet that catered to a "beginner" audience, and was installed as a browser extension. But as the ecosystem expanded, the number of different wallet products also grew. It isn't uncommon to have users with multiple wallet browser extensions installed.

So if you are the developer of a dApp that makes use of the user's connected wallet, you now have a problem. Browser extension wallets would inject their Ethereum providers into the same window.ethereum object. And the user cannot control which Provider gets to interact with. The last wallet to load usually wins 🤨.

This problem is outlined in EIP-6963: Multi Injected Provider Discovery, which came into existence as a resolution. So between the two standards, we have a pretty good idea of how browser wallets are expected to behave. The keyword here is "expected". Look, I've been swimming around in the lake of CSS specifications for a number of years now. I learned early on that having defined in a standard is only the beginning of the journey.

Rules seem like suggestions

I'm Malaysian, and the joke I love to make to the Singaporeans around me is, where I come from, traffic laws are less like rules and more like suggestions. Like, MAYBE you don't wanna park next to a no parking sign. Or MAYBE you should slow down when the light turns yellow. But you do you. In this day and age, I realise I must explicitly say this is a JOKE. Please obey traffic laws when you come to Malaysia.

The point is, even though the standard exists, the browser wallet extension makers aren't forced to implement it within a specific deadline after the standard is made final. There generally are no hard deadlines for specification implementation. For example, Firefox just started supporting View Transitions 4 days ago. Chrome released in early March 2023, and Safari released in mid September 2024.

That being said, standards and specifications are great, because it allows for a predictable interface when developers want to build atop such foundational elements. The start of most dApp user journeys involves the user clicking a "Connect Wallet" button to connect their browser wallet to the application and perform blockchain transactions, i.e. record state changes onto the blockchain.

The technical details of building a connect wallet interface I will cover in a separate post, but I just wanted to provide a description of how the experience was like with a picture. It's worth a thousand words.

Granted I did have more than the normal number of browser wallets installed at the same time and most users probably don't do this (maybe). Call it a stress test. Web standards for HTML, CSS and JavaScript are focused on end-user interaction with the browser, and I was very used to thinking along those lines. However, for the Ethereum standards, it is more focused on the wallet interacting with the blockchain. In that sense, the dApp interacting with the wallet is one level away.

An example would be disconnecting your wallet from the dApp. The disconnect event outlined in EIP-1193 is meant for the wallet to indicate that it has lost its connection to the blockchain, and not for indicating the user disconnecting their wallet from the application. So the issue I ran into was the scenario where someone wanted to switch to a different wallet to interact with my application, and I kept getting stuck with the old wallet provider.

Libraries like Wagmi provide a layer of abstraction for connecting wallets which simulates disconnection behaviour with a shim. Metamask has its own API that exposes a wallet_revokePermissions for developers to use, and there are some standard proposals like ERC-7715: Grant Permissions from Wallets that could alleviate the problem eventually.

Wrapping up

It seems to me that this space of developing dApps is similar to the earlier days of the web where the entire ecosystem is still trying to nail down things that are worth standardising across the board. Which is giving me a taste of what it must have been like building websites back in the day of the browser wars.

Now I don't think I'm even experiencing half the exasperation, but it is giving me a greater appreciation of the work so many people have done to make web standards a thing. Today, I can happily build sites with the reassurance that it will almost always behave the same across browsers, and that's not something to be taken for granted.

Web pioneers, I salute you. 🫡

Thank you for paving the way for the rest of us.

Migrating from Hugo to Astro

Chen Hui Jing — Mon, 06 Oct 2025 01:09:20 +0000

I'm migrating my blog again. This blog has been in existence for more than 11 years. It started as a Jekyll site. Then I moved to Hugo. Now I'm moving it to Astro. The design has NEVER changed, which makes me quite contrarian to most frontend developers in the industry. But when I came up with the design back then, I wanted it to feel like me. And today, when I look at my blog, it still feels like me. I guess this says more about me as a person than my actual blog design, but I'm past the age where I care any more.

Hugo says I have 287 pages on my blog but I only have 226 blog posts 🤔. But the point is, I have a lot of pages to migrate. Do I really have to port over everything, you might ask? Well, yes. I do. This is my entire web developer journey, how could I possibly leave anything behind? Also, why am I migrating to begin with? Honestly, I completely lost the plot with Hugo.

When they released their revamped template system in v0.146.0, I couldn't wrap my head around it. My listing pages all broke locally. If you check my blog statistics, I clearly haven't been writing that much since 2021 anyway, but I don't actually know Go or work on Hugo websites. So this is not a Hugo problem, it's a me problem. I also started living in Astro since 2023, when I was documentation infrastructure czar (this is a fake title) at the Interledger Foundation.

Needless to say, I have fallen in love with Astro and its fantastic community. I will always have good things to say about Astro. At this point in my career, I feel reasonably confident in my migration capabilities. I've built my career on similar projects, enough to learn that it's never easy, and things will break, but nothing can't be fixed. Probably not going to be a single day project this time though.

However, this is now a mid-sized website (that earns NOTHING, haha), so I did need to think through some migration strategies.

Set up Astro site

I also love bun. At first, it was because I liked the logo, because I'm superficial like that. But I've felt the benefits of its package manager, how it does .env files, how it supports TypeScript natively and so on. Yay, bun.

Anyway, first step was creating a new Astro project:

bunx create-astro@latest website

Astro warns you that using Astro with Bun is a little rough around the edges, but it was alright for me. I went with the blog template.

Migrate generated components

The blog template has some Astro components like the site header and footer. I figured those could be the first things to go over. I did have quite a lot of template logic going on, but low-hanging fruit first tends to be how I do things. I had not looked at my styling code in years, but the Sass features I had been using are pretty much native CSS at this point, so this was a good time for a styles refactor.

I had previously broken up my files into different Sass files loosely based on Harry Robert's ITCSS, so it did make porting over to Astro components relatively easy. I rewrote all the Sass back to native CSS because I really wasn't doing anything spectacular Sassy to begin with. Just some nesting and colour functions. Nothing today's native CSS couldn't handle.

Once the base styles came over, there was an illusion that things were progressing quickly. No, they were not. This was largely due to the amount of template logic I had introduced over the years. Porting over the stuff in the head element took a good while, because I had relied on a lot of post frontmatter to do that. So that also meant setting up the frontmatter in Astro via the content.config.ts file.

I also needed to inject some logic into the RSS feed implementation because my blog listed writing that I did for external publications and I wanted the canonical links to point to those external URLs. The external URL thing ended up taking a lot more time than I expected, but at least it works now. By now the plan to migrate generated components first had gone out the window, because I got distracted by migrating pages instead.

import { getCollection } from "astro:content";
import rss from "@astrojs/rss";
import { SITE_DESCRIPTION, SITE_TITLE } from "@/consts";

export async function GET(context) {
  const posts = await getCollection("blog");
  return rss({
    title: SITE_TITLE,
    description: SITE_DESCRIPTION,
    site: context.site,
    items: posts
      .sort((a, b) => +new Date(b.data.date) - +new Date(a.data.date))
      .filter((post) => !post.data.nofeed)
      .map((post) => ({
        ...post.data,
        link: post.data.external_url ? post.data.external_url : `/blog/${post.id}/`,
        pubDate: new Date(post.data.date),
      })),
  });
}

Migrate pages

There were not that many pages (i.e. not blog posts) on my website, but the only straight-forward page was the "About" page. My "Talks" and "Work" pages were a combination of frontmatter filtering and looping over external data files. The meat of the site was my blog, so there was the full listing page, tag pages and the home page which showed the latest 10 posts. Also had a contact page, résumé page and custom 404 page.

By this point, I had fully realised that my brain reads Javascript with a fluency that does not exist for Hugo's style of Go templating syntax. Migrating the tag pages were a good example of this. For Astro, creating tag pages was a matter of filtering the blog content collection for posts with tags in their frontmatter. I'll probably write up the details of the implementation in a separate post.

I also had data for my talk slides and side projects in separate YAML files, and had some logic that would display different URLs, if it should link to a blog post or an external URL. That logic in Hugo was… let's just say I'm not that great with double curly braces? I'm just more used to mapping arrays. Honestly, the most complicated logic was probably the head element if I'm being honest. Those OG tags, canonical URLs and noindex scenarios needed some extra scrutiny.

But in a nutshell, compare this:

<head>
  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name=viewport content="width=device-width, initial-scale=1">

  <title>{{ if .Params.title }}{{ .Params.title | safeHTML }}{{ else }}{{ .Site.Title }}{{ end }}</title>
  <meta name="description" content="{{ if (eq .Type "blog") }}{{ .Summary | truncate 130 }}{{ else }}{{ .Site.Params.description }}{{ end }}">

  {{ if .Params.noindex }}
  <meta name="robots" content="noindex">
  {{ end }}

  {{ template "_internal/opengraph.html" . }}
  {{ template "_internal/twitter_cards.html" . }}

  <meta name="twitter:site" content="@hj_chen">
  <meta name="p:domain_verify" content="1623582e8d2881f774efff746a6f3f1f">
  <meta name="msvalidate.01" content="30F5181A4C23EE64C2F947E2910DDBBA">

  {{ if .Params.external_url }}
  <link rel="canonical" href="{{ .Params.external_url }}">
  {{ else }}
  <link rel="canonical" href="{{ .Permalink }}">
  {{ end }}

  {{ with .OutputFormats.Get "RSS" -}}
    {{ printf `<link rel="%s" type="%s" href="%s" title="%s">` .Rel .MediaType.Type .Permalink $.Site.Title | safeHTML }}
  {{ end -}}

  <link href="https://micro.blog/huijing" rel="me">
  <link rel="monetization" href="https://ilp.gatehub.net/747467740/USD" />

  {{ if (eq .Type "blog") }}
  {{ $options := (dict "targetPath" "posts.css" "outputStyle" "compressed" "enableSourceMap" true) }}
  {{ $style := resources.Get "sass/posts.scss" | resources.ToCSS $options }}
  <link rel="stylesheet" href="{{ $style.RelPermalink }}">
  {{ else }}
  {{ $options := (dict "targetPath" "pages.css" "outputStyle" "compressed" "enableSourceMap" true) }}
  {{ $style := resources.Get "sass/pages.scss" | resources.ToCSS $options }}
  <link rel="stylesheet" href="{{ $style.RelPermalink }}">
  {{ end }}

  <link rel="preload" href="/assets/fonts/eightbitoperatorplus8-bold-webfont.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/assets/fonts/eightbitoperatorplus-regular-webfont.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/assets/fonts/magnetic-pro-black.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/assets/fonts/magnetic-pro-light.woff2" as="font" type="font/woff2" crossorigin>

  <link rel="apple-touch-icon" sizes="180x180" href="/assets/favicons/apple-touch-icon.png">
  <link rel="icon" type="image/png" href="/assets/favicons/favicon-32x32.png" sizes="32x32">
  <link rel="icon" type="image/png" href="/assets/favicons/favicon-16x16.png" sizes="16x16">
  <link rel="manifest" href="/assets/favicons/manifest.json">
  <link rel="mask-icon" href="/assets/favicons/safari-pinned-tab.svg" color="#009418">
  <link rel="shortcut icon" href="/assets/favicons/favicon.ico">
  <meta name="msapplication-config" content="/assets/favicons/browserconfig.xml">
  <meta name="theme-color" content="#ffffff">
</head>

with this:

<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width,initial-scale=1" />
  <link rel="sitemap" href="/sitemap-index.xml" />
  <link rel="alternate" type="application/rss+xml" title={SITE_TITLE} href={new URL("rss.xml", Astro.site)}
  />
  <meta name="generator" content={Astro.generator} />

  <title>{title ? `${title} | ${SITE_TITLE}` : SITE_TITLE}</title>
  <meta name="author" content="Chen Hui Jing" />
  <meta name="title" content={title ? `${title} | ${SITE_TITLE}` : SITE_TITLE} />
  <meta name="description" content={description ? description : SITE_DESCRIPTION} />
  {noindex && <meta name="robots" content="noindex, nofollow" />}
  <link rel="canonical" href={canonicalURL} />

  <link rel="preload" href="/assets/fonts/eightbitoperatorplus8-bold-webfont.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/assets/fonts/eightbitoperatorplus-regular-webfont.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/assets/fonts/magnetic-pro-black.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/assets/fonts/magnetic-pro-light.woff2" as="font" type="font/woff2" crossorigin>

  <meta property="og:title" content={title ? `${title} | ${SITE_TITLE}` : SITE_TITLE} />
  <meta property="og:type" content={ogType ? ogType : "website"} />
  <meta property="og:image" content={ogImageUrl ? ogImageUrl : new URL("/images/avatar-ponytail@2x.png", Astro.site).href} />
  <meta property="og:url" content={canonicalURL} />
  <meta property="og:description" content={description ? description : SITE_DESCRIPTION} />

  <meta name="twitter:card" content="summary_large_image" />
  <meta name="twitter:title" content={title ? `${title} | ${SITE_TITLE}` : SITE_TITLE} />
  <meta name="twitter:image" content={ogImageUrl ? ogImageUrl : new URL("/images/avatar-ponytail@2x.png", Astro.site).href} />
  <meta name="twitter:description" content={description ? description : SITE_DESCRIPTION} />

  <link rel="apple-touch-icon" sizes="180x180" href="/favicons/apple-touch-icon.png" />
  <link rel="icon" type="image/png" href="/favicons/favicon-32x32.png" sizes="32x32" />
  <link rel="icon" type="image/png" href="/favicons/favicon-16x16.png" sizes="16x16" />
  <link rel="manifest" href="/favicons/manifest.json" />
  <link rel="mask-icon" href="/favicons/safari-pinned-tab.svg" color="#009418" />
  <link rel="shortcut icon" href="/favicons/favicon.ico" />
  <meta name="msapplication-config" content="/favicons/browserconfig.xml" />
  <meta name="theme-color" content="#ffffff" />

  <meta name="twitter:site" content="@hj_chen" />
  <meta name="p:domain_verify" content="1623582e8d2881f774efff746a6f3f1f" />
  <meta name="msvalidate.01" content="30F5181A4C23EE64C2F947E2910DDBBA" />
  <link href="https://micro.blog/huijing" rel="me" />
  <link rel="monetization" href="https://ilp.gatehub.net/747467740/USD" />
</head>

Migrate blog posts

For the blog posts themselves, my content had always been in markdown since day 1 (which would be 4257 days ago). However, given that this is my third migration, I have started to think more about the use of components to keep things DRY. I then recalled the first time I did the migration, I had similar concerns. It was evident, looking at the current state of the blog posts this time, that I was in two minds back then.

In that previous migration blogpost, former me literally said:

But I oscillated between using Hugo’s custom shortcodes versus writing out HTML in full for my responsive images because I kept thinking what would happen if I migrated again. That would mean writing the stuff in the shortcodes within my content.

Somewhere along the lines in 2023, I sort of lost the plot, and ended up using shortcodes for a bit. Thankfully, my decreased writing output meant that it wasn't that much to deal with. But for now, I did create temporary components in Astro, that I plan to slowly migrate anyway from back to just the HTML in full. I hope I remember this, if not, it's gonna be kinda hilarious for migration number 3.

You know what, I'll create an issue to track this. I don't understand why previous me did not do this when all my stuff is on GitHub to begin with. 🙄

Astro is a TypeScript-first kind of framework, so type safety is totally a thing. Anyway, the documentation states: “Every frontmatter or data property of your collection entries must be defined using a Zod data type”. Considering I had 1001 frontmatter properties for all kinds of rendering logic (see the above section), my schema was a little long-ish.

const blog = defineCollection({
  loader: glob({ base: "./src/content/blog", pattern: "**/*.{md,mdx}" }),
  schema: () =>
    z.object({
      title: z.string(),
      date: z.coerce.date(),
      tags: z.array(z.string()).default([]),
      og_image: z.string().optional(),
      description: z.string().optional(),
      hastweet: z.boolean().default(false),
      hascaniuse: z.boolean().default(false),
      hascodepen: z.boolean().default(false),
      project: z.string().optional(),
      project_image: z.string().optional(),
      external_url: z.string().url().optional(),
      external_site: z.string().optional(),
      nofeed: z.boolean().default(false),
      noindex: z.boolean().default(false),
    }),
});

I had run the blog template when I first created the site and the schema had included Image as a type, and I'd thought to use it for my 2 image frontmatter properties but turns out, it doesn't really work? I did not dig into it but there was a whole GitHub issue and the conclusion was, just use a string. ¯\_(ツ)_/¯

Wrapping up

The first time I migrated, it took 3 days. This one sort of took 3 days as well. So maybe that's the average amount of time needed to migrate a website. I'm sure it will take less time if I ever complete paying off my tech debt of framework-locked partials/shortcodes/components. But maybe I'll actually stick with Astro since it's really close to HTML, CSS and Javascript.

Check back in 5 years I guess.

Migrating content collections from Astro 4 to 5

Chen Hui Jing — Sat, 29 Mar 2025 21:14:50 +0000

In case you missed it, Astro 5 has been out and about since Dec 3, 2024. As of time of writing, we’re at 5.5.4 already. What can I say, the team moves fast. ¯\_(ツ)_/¯

I have 2 projects that make use of Astro’s content collections and I migrated the first of those back on Dec 16, 2024. What can I say, I’m one of THOSE people. ¯\_(ツ)_/¯

Anyway, I finally got around to migrating the second project in February, and because I’m old(er) now, I can’t remember shit any more. Just in case I have to do the migration a third time for whatever reason, it’s probably a good idea to write all the gotchas down.

Documentation is great, refer to it

The Astro team has provided a really good migration guide, and that should be your first stop. Keep it open the whole time you’re doing the migration. It’s good stuff. The part that was most relevant to me was Legacy: v2.0 Content Collections API.

There are step by step instructions on exactly what to do, so follow the 4 steps outlined in the documentation.

Move (and rename) the content config file (content.config.ts). This file (config.ts) no longer lives within the src/content/ folder. This file should now exist at src/content.config.ts.

Edit the collection definition within the content config file. For me, it went from:

import { z, defineCollection } from "astro:content";
import { docsSchema, i18nSchema } from "@astrojs/starlight/schema";

const blogCollection = defineCollection({
  type: "content",
  schema: z.object({
    title: z.string(),
    description: z.string(),
    date: z.date(),
    image: z.string().optional(),
    tags: z.array(z.string()),
  }),
});

export const collections = {
  docs: defineCollection({ schema: docsSchema() }),
  i18n: defineCollection({ type: "data", schema: i18nSchema() }),
  blog: blogCollection,
};

to:

import { z, defineCollection } from "astro:content";
import { glob } from "astro/loaders";
import { docsLoader, i18nLoader } from "@astrojs/starlight/loaders";
import { docsSchema, i18nSchema } from "@astrojs/starlight/schema";

const blogCollection = defineCollection({
  loader: glob({ pattern: "**/[^_]*.{md,mdx}", base: "./src/content/blog" }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    slug: z.string(),
    date: z.date(),
    image: z.string().optional(),
    tags: z.array(z.string()),
    authors: z.array(z.string()),
    author_urls: z.array(z.string()),
  }),
});

export const collections = {
  docs: defineCollection({ loader: docsLoader(), schema: docsSchema() }),
  i18n: defineCollection({ loader: i18nLoader(), schema: i18nSchema() }),
  blog: blogCollection,
};

Change references from slug to id and switch to the new render() function (this combines step 3 and 4 from the documentation). This one I had some trouble with. Not instructions per se. That was relatively straightforward. The file went from:
```
---
import { getCollection } from 'astro:content';

export async function getStaticPaths() {
  const blogEntries = await getCollection('blog');
  return blogEntries.map(entry => ({
    params: { slug: entry.slug },
    props: { entry },
  }));
}
const { entry } = Astro.props;
const { Content } = await entry.render();
---
<Content />
```
to:
```
---
import { getCollection, render } from 'astro:content';
import BlogLayout from '../../layouts/BlogLayout.astro';

export async function getStaticPaths() {
  const blogEntries = await getCollection('blog');
  return blogEntries.map(entry => ({
    params: { id: entry.id },
    props: { entry },
  }));
}

const { entry } = Astro.props;
const { Content } = await render(entry);
---
<BlogLayout frontmatter={entry.data}>
  <Content />
</BlogLayout>
```
The total amount of changes seem trivial when I write it down like that but it took me forever to figure out why the routes for the individual blog posts just refused to render and kept 404-ing.

Things finally started to work when I changed the file name from [...slug].astro to [...id].astro. Do I know why that works? Not really, except that it matches the API change from slug to id. Someone smarter than me and more experienced in Astro please tell me why this fixes the problem.

In addition, one of the breaking changes outlined in the upgrade docs was the bit about the layout field no longer being supported in Markdown collection entries.

This one was mildly annoying to fix, but it was merely a matter of importing the layout file at the dynamic route page template instead of the individual blog post. The BlogLayout had relied on the frontmatter directly from the markdown or MDX post, which now had to be passed in via frontmatter={entry.data}.

I also had issues rendering blog posts that were written in MDX instead of markdown. The solution for me was to install the latest @astrojs/mdx and import it in my astro.config.js file. This is possibly related to how Astro 5 handles JSX and MDX rendering.

Wrapping up

Again, I’m just trying to document gotchas that I’m most likely going to forget otherwise and then get that annoying feeling of deja vu that I fixed it before. But then again, Astro moves so fast that the API might change again the next time I have to do this. Oh well, just the price of progress, I suppose. 🤷

The case for “old school” CSS

Chen Hui Jing — Tue, 25 Mar 2025 01:14:50 +0000

Do people still write CSS in CSS files any more? I honestly don’t keep up with the trends as much as I did back when I started by career. Partly because I’ve started to feel that the web development community online has become a lot more “this(my) way is the best way” than when I started out at the tail-end of the HTML tables era and the start of the floats era.

Love this slide from my The State of CSS talk at Web Directions Code back in 2024

Regardless, personal opinions aside, I do have projects that involve CSS in CSS files. It’s a Drupal 10 site, so the custom theme uses CSS. Who still uses Drupal in 2025, you might ask? Apparently, Drupal is used by 1.2% of all the websites whose content management system we know. This is 0.9% of all websites.. As of time of writing, there are estimated to be 192 million actively maintained websites, so it’s still a good number.

So what’s the use case?

The use case is i18n. If you’re new to Drupal, or someone like me who returned from a long hiatus since Drupal 7, the Drupal documentation SEO is a little messed up if you just Google directly. Largely because Drupal 7 had such a long, long shelf life.

Anyway, the up-to-date Drupal i18n documentation is at Chapter 10. Making Your Site Multilingual and Multilingual guide. Go there if you’re trying implement i18n on your own Drupal 10 site.

The specific problem I was trying to solve was related to the language switcher. Once you turn on multilingual capabilities on your Drupal site, there is a language switcher block that you can place where you deem fit.

I suppose, depending on the Drupal theme you are using, there may or may not be some styling associated with the block. But as my site was a fully custom implementation, my theme was built off Starterkit theme.

Without doing anything to the default implementation, once you turn on the Language Switcher block in your Header region on a vanilla theme, you will get an unordered list of all the languages supported by your site.

Those language labels can be edited via the admin interface. You have to go to admin/config/regional/language and edit each of the languages listed there. My use case only involved 2 languages, so I decided to design the language switcher to appear like additional link options on the header, with the labels being the 2-letter language code.

Templating with Twig

You can’t old-school CSS without CSS classes. And in the land of Drupal theming, that menas it’s Twig templating time. Templates in Drupal make use of naming conventions to let you override them.

So if you are starting from scratch with a starterkit base theme, your out-of-the-box markup is going to be wrapped in layers of <div>s, which I personally do not like. My first thing is to override the page.html.twig and region.html.twig templates with ones that provide some useful CSS class names.

# page.html.twig
{% if logged_in %}
  {{ page.admin }}
  {% endif %}

<header class="site-header" role="banner">
  {{ page.header }}
</header>

<main role="main">
  <a id="main-content" tabindex="-1"></a>
  <h1 class="visually-hidden">{{ current_page_title }}</h1>
  {{ page.content }}
</main>

# region.html.twig
{%
  set classes = [
    'region',
    'region-' ~ region|clean_class,
  ]
%}
{% if content %}
  <div{{ attributes.addClass(classes) }}>
    {{ content }}
  </div>
{% endif %}

The out-of-the-box menu list also has zero CSS classes. Nah, gotta add some in there for the menu as well.

# menu--main.html.twig
{% import _self as menus %}

{{ menus.menu_links(items, attributes, 0) }}

{% macro menu_links(items, attributes, menu_level) %}
  {% import _self as menus %}
  {% if items %}
    {% if menu_level == 0 %}
      <ul{{ attributes}} class="site-nav__links menu--level-{{ menu_level + 1 }}" id="siteNavMenu">
    {% else %}
      <ul class="menu--level-{{ menu_level + 1 }}">
    {% endif %}
    {% for item in items %}
      {%
        set classes = [
          'menu-item',
          item.is_expanded ? 'has-submenu',
          'menu-item--level-' ~ (menu_level + 1)
        ]
      %}
      <li{{ item.attributes.addClass(classes) }}>
        {{ link(item.title, item.url) }}
        {% if item.below %}
          {{ menus.menu_links(item.below, attributes, menu_level + 1) }}
        {% endif %}
      </li>
    {% endfor %}
    </ul>
  {% endif %}
{% endmacro %}

And finally, I wanted to sprinkle on some extra stuff onto the navigation block, like a site logo and mobile menu icon so that meant overriding the main menu block.

# block--blank-main-menu.html.twig
{% set heading_id = attributes.id ~ '-menu'|clean_id %}

<nav class="site-nav" role="navigation" aria-labelledby="{{ heading_id }}"{{ attributes|without('role', 'aria-labelledby') }}>
  {% if not configuration.label_display %}
    {% set title_attributes = title_attributes.addClass('visually-hidden') %}
  {% endif %}
  {{ title_prefix }}
  <h2{{ title_attributes.setAttribute('id', heading_id) }}>{{ configuration.label }}</h2>
  {{ title_suffix }}

  <a href="{{ path('<front>') }}" rel="home" class="site-logo">
    <img src="{{ site_logo }}" alt="{{ 'Home'|t }}" fetchpriority="high" />
  </a>

  <div class="site-links-wrapper" data-nav-wrapper id="siteNavLinks">
    {{ content }}
  </div>

  <button
    type="button"
    class="site-nav__toggle"
    aria-controls="siteNavMenu"
    aria-label="Toggle Menu"
    title="Toggle Menu"
    id="siteNavToggle"
  >
    <div id="menuIcon" class="menu-icon">
      <span></span>
      <span></span>
      <span></span>
      <span></span>
    </div>
  </button>
</nav>

Always remember to drush cr after messing around with templates.

CSS time

After that it’s really all CSS. Mostly around using flexbox. But let’s see if going through it (almost) line by line makes sense to people who no longer write “traditional” CSS, whatever that means.

I’d like my header to remain sticky at the top of the page even as people scroll down. The trick here is to remember to set the top value, otherwise it’s not going to stick.

.site-header {
  padding: 0 var(--space-m);
  position: sticky;
  top: 0;
  z-index: 2;
  box-shadow: var(--box-shadow);
  background-color: white;
}

I have a <nav> element with the CSS class .site-nav which wraps around the site logo, list of navigation links and mobile menu toggle button. Let’s make it a flexbox and make everything inside align center, plus some basic hover styles.

.site-nav {
  display: flex;
  align-items: center;
}

.site-logo {
  flex: none;
}

.site-nav__links {
  list-style: none;
  padding-inline-start: 0;
}

.site-nav__links a {
  display: block;
  color: currentColor;
  transition: text-decoration 200ms ease-in-out;
  white-space: nowrap;
  text-underline-offset: 8px;
  text-decoration: underline 1.5px transparent;
  padding: var(--space-s) var(--space-2xs);
}

.site-nav__links a:hover {
  background-color: ghostwhite;
}

.site-nav__links .is-active {
  text-decoration-color: currentColor;
}

As for the language switcher, it’s an unordered list by default, but we can and should spruce it up a little bit.

.language-switcher-language-url {
  flex: none;
}

.language-switcher-language-url .links {
  display: flex;
  list-style: none;
  padding: 0;
  margin-inline-start: var(--space-2xs);
}

.language-switcher-language-url .links li:first-child::after {
  display: inline-flex;
  content: "|";
}

.language-switcher-language-url .links a {
  padding: var(--space-s) var(--space-2xs);
}

At this point, your header still looks very wonky. Don’t worry, it’s all part of the process.

When there is enough space in the viewport, for this example, when there’s at least 700px worth of space, everyone can all hang out on the same line.

@media screen and (min-width: 700px) {
  .region-header {
    display: flex;
    align-items: center;
  }

  .site-links-wrapper {
    flex: 1;
  }

  .site-nav {
    flex: 1;
  }

  .site-nav__links {
    display: flex;
    justify-content: center;
  }

  .site-nav__toggle {
    display: none;
  }
}

These layout styles essentially make sure the list of links take up the all the space left over after the site logo and the language switcher are accounted

Without modifying the markup further, we can sprinkle on some JavaScript to help create a mobile menu. But first, the styling.

@media screen and (max-width: 699px) {
  .site-links-wrapper {
    position: absolute;
    background-color: white;
    top: var(--site-header-height);
    right: 0;
    transition: transform 300ms ease-in-out;
    border-block-start: 1px solid lightgrey;
  }

  .site-links-wrapper.offscreen {
    transform: translateX(100%);
  }

  .site-links-wrapper a {
    padding-inline: var(--space-s);
  }

  .language-switcher-language-url {
    position: absolute;
    top: 25px;
    right: calc(var(--space-m) + var(--space-xs) + 24px);
  }
}

This absolutely positions the list of links to just under the site header and stuck to the right of the viewport. And if you are wondering why the language switcher is also absolutely positioned, this is because of the way the markup is structured.

The language switcher, as explained above, is a Drupal system block. Could we rewrite the main menu template to incorporate the language switcher? Probably, but between doing that and using CSS, I chose the CSS route.

So the approach was to position the language switcher next to the mobile menu toggle. A lesser of two evils approach methinks.

The styling for the mobile menu toggle goes something like this, which is essentially just 3 black lines, which are supposed to transform into a cross when the open class is added to the icon.

.site-nav__toggle {
  border: 0;
  background: initial;
  padding: var(--space-xs) 0;
  color: currentColor;
  margin-inline-start: auto;
}

.menu-icon {
  position: relative;
  transform: rotate(0deg);
  transition: 0.5s ease-in-out;
  cursor: pointer;
  height: 1em;
  width: 1.5em;
}

.menu-icon span {
  display: block;
  position: absolute;
  height: 4px;
  width: 100%;
  background: currentColor;
  border-radius: 4px;
  opacity: 1;
  left: 0;
  transform: rotate(0deg);
  transition: 0.25s ease-in-out;
}

.menu-icon span:nth-child(1) {
  top: 0;
}

.menu-icon span:nth-child(2),
.menu-icon span:nth-child(3) {
  top: 50%;
}

.menu-icon span:nth-child(4) {
  top: 100%;
}

.menu-icon.open span:nth-child(1),
.menu-icon.open span:nth-child(4) {
  top: 50%;
  width: 0%;
  left: 50%;
}

.menu-icon.open span:nth-child(2) {
  transform: rotate(45deg);
}

.menu-icon.open span:nth-child(3) {
  transform: rotate(-45deg);
}

A sprinkling of JavaScript

The actual opening and closing of the mobile menu needs the help of some JavaScript.

// Site navigation CSS classes
const siteLinksWrapper = document.querySelector("[data-nav-wrapper]");
const wideNavMinWidth = window.matchMedia("(min-width: 700px)");
handleNavDisplayStyles(wideNavMinWidth);
wideNavMinWidth.addEventListener("change", handleNavDisplayStyles);

const siteNavToggle = document.getElementById("siteNavToggle");
const siteNavLinks = document.getElementById("siteNavLinks");
const menuIcon = document.getElementById("menuIcon");

if (document.contains(siteNavToggle)) {
  siteNavToggle.addEventListener("click", handleMobileNavToggle, false);
}

function handleMobileNavToggle(event) {
  siteLinksWrapper.classList.toggle("offscreen");
  if (siteLinksWrapper.getAttribute("class").includes("offscreen")) {
    menuIcon.classList.remove("open");
  } else {
    menuIcon.classList.add("open");
  }
}

function handleNavDisplayStyles(event) {
  if (event.matches) {
    siteLinksWrapper.classList.remove("offscreen");
  } else {
    if (siteLinksWrapper) {
      flashPrevention(siteLinksWrapper);
    }
    siteLinksWrapper.classList.add("offscreen");
  }
}

function flashPrevention(element) {
  element.setAttribute("style", "display:none");
  setTimeout(() => {
    element.removeAttribute("style");
  }, 10);
}

After all that, you end up with something like this:

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Wrapping up

This was honestly really fun to write up, especially the part where I built out a fresh Drupal install to make sure all the theming code is not polluted with other components on my production website. If anyone still does Drupal, or still writes “old-school” CSS, let me know. I feel a sense of remote kinship with all of you. 😬

Credits: OG:image from CraftPix.net 2D Game Assets

Implementing pagination on an Astro blog

Chen Hui Jing — Sun, 23 Mar 2025 21:14:50 +0000

Even though I built the blog for our tech team to share their insights and knowledge with the rest of the interwebs, I wasn’t necessarily the one writing the actual blogs. Now that I think about it, I do not think I’ve published a single article on the blog. Haha.

Realistically, it was pretty much a build it and move on with life situation, where there were not many feature requests, it was mainly dependency updates and very minor CSS tweaks. So it did take me a while to realise that, I hadn’t actually built the pagination for the blog.

Back when I built the whole thing in March 2024, the only blog posts we had were 3 that were ported over from a Medium account we’d lost access to. Anyway, with 3 blog posts, and no commitment from anybody on the team that we would publish blog posts regularly, I figured we would get to pagination later, much later.

Well, by the time we had to upgrade Astro from 4 to 5 (there will be a blog post on this), I saw that we had 13 blog posts and yikes, the first blog post was gone from the listing. Yikes indeed.

See how other people do stuff

In my feeble attempt to be future-proof, I did consult the Googles on how other people did it, and I’m pretty sure Creating A Pagination Component With Astro by Ted Krueger was the article I had referred to.

Most other results were for pagination components other people had built and packaged into something you could just import. I’m not against importing and using components in general, but come on, it’s a pagination. I’d rather use my self-imposed import quota on something grander, if you know what I mean.

So the implementation I ended up with had the dynamic [...page].astro component for when you paginate the entire listing and end up with multiple blog listing pages but no actual pagination component.

---
import type { Page } from "astro";
import BaseLayout from '../../layouts/BaseLayout.astro';
import { getCollection } from 'astro:content';

type Props = {
  page: Page<any>;
};

export async function getStaticPaths({ paginate }: any) {
  const blogEntries = (await getCollection("blog")).sort((a, b) => b.data.date.getTime() - a.data.date.getTime());
  return paginate(blogEntries, { pageSize: 12 });
}

const { page } = Astro.props;
---
<BaseLayout title="Engineering blog">
  <main>
    <div class="content-wrapper">
      <ol class="breadcrumbs" itemscope itemtype="https://schema.org/BreadcrumbList">
        <li itemprop="itemListElement" itemscope
            itemtype="https://schema.org/ListItem">
          <a itemprop="item" href="/developers">
          <span itemprop="name">Developers Portal</span></a>
          <meta itemprop="position" content="1" />
        </li>
      </ol>
      <h1>Engineering Blog</h1>
      <ol class="postlist">
        {((page as any).data || []).map((blogPostEntry: any) => (
          <li class="postlist-item">
            <a href={`/developers/blog/${blogPostEntry.slug}`} class="postlist-link heading--6">{blogPostEntry.data.title}</a>
            <time class="postlist-date" datetime={blogPostEntry.data.date.toISOString()}>
              {blogPostEntry.data.date.toDateString()}
            </time>
          </li>
        ))}
      </ol>
    </div>
  </main>
</PageLayout>

<style>
/* all my blog listing styling */
</style>

And for the individual blog posts, the dynamic page for those was [...slug].astro.

---
import { getCollection } from 'astro:content';

export async function getStaticPaths() {
  const blogEntries = await getCollection('blog');
  return blogEntries.map(entry => ({
    params: { slug: entry.slug }, props: { entry },
  }));
}

const { entry } = Astro.props;
const { Content } = await entry.render();
---
<Content />

I’m just missing the Pagination component that Ted built out in his article. What’s the reason for this blog post if the implementation simply follows what Ted has already explained in his article?

Well, my project’s implementation has a URL suffix problem, i.e. the entire Astro site is not served on the root domain, but instead on <ROOT_DOMAIN>/developers. Oh, that /developers suffix. 😮‍💨

So I had diverged from how Ted implemented the parameters for this pagination component.

There are 5 "types" of links on a pagination component, or at least for this particular UI pattern I was trying to follow.

Go to first page
Go to previous page
Go to X page number
Go to next page
Go to last page

Astro has built-in Pagination support, and with use of the paginate() function, each page gets page-related data via a page prop.

The page prop provided all the parameters I need to fulfil the above 5 types of links on the Pagination component I was trying to build. So on the [...page].astro listing component, the parameters where passed into the Pagination component as follows:

<Pagination
  length="{page.lastPage}" /** number of last page */
  currentPage="{page.currentPage}" /** the current page number, starting from 1 */
  firstUrl="{page.url.first}" /** url of the first page (if the current page is not the first page) */
  prevUrl="{page.url.prev}" /** url of the previous page (if there is one) */
  nextUrl="{page.url.next}" /** url of the next page (if there is one) */
  lastUrl="{page.url.last}" /** url of the last page (if the current page in not the last page) */
/>

Now, because the url data returns undefined when it doesn’t exist, we can build logic to make sure there are no broken links in the pagination. The “edge” cases are when you hit the first page and when you hit the last page.

So the checks can be done like so:

{
  firstUrl ? (
    <a href={`/developers${firstUrl}`} class="pagination__link">
      &#171;
    </a>
  ) : (
    <span class="pagination__link disabled">&#171;</span>
  );
}

And so on and so forth for the rest of the cases. Putting everything together, the pagination component ends up looking like this:

---
const { length, currentPage, firstUrl, prevUrl, nextUrl, lastUrl } = Astro.props;
const paginationList = Array.from({length}, (_, i) => i + 1);
---
<nav aria-label="Blog pages" class="pagination">
  {firstUrl ? (
    <a href={`/developers${firstUrl}`} class="pagination__link">&#171;</a>
  ) : (
  <span class="pagination__link disabled">&#171;</span>
  )}

  {prevUrl ? (
    <a href={`/developers${prevUrl}`} class="pagination__link">&#8249;</a>
  ) : (
    <span class="pagination__link disabled">&#8249;</span>
  )}

  {paginationList.map((num) => (
    <a
      href={`/developers/blog${num == 1 ? "" : "/" + num}`}
      class={`pagination__link ${currentPage == num ? "disabled active" : ""}`}
    >
      {num}
    </a>
  ))}

  {!nextUrl ? (
    <span class="pagination__link disabled">&#8250;</span>
  ) : (
    <a href={`/developers${nextUrl}`} class="pagination__link">&#8250;</a>
  )}

  {lastUrl ? (
    <a href={`/developers${lastUrl}`} class="pagination__link">&#187;</a>
  ) : (
    <span class="pagination__link disabled">&#187;</span>
  )}
</nav>

<style>
/* all my pagination styling */
</style>

Wrapping up

Did I do all this by myself? Of course not. I had the help of the most patient human rubber duck / TypeScript therapist / overall programming whiz that I’ve had the privilege of being friends with, See Yishu.

Astro uses TypeScript by default, and 80% of the time, we’re fine. We have a cordial relationship, TypeScript and I. But then, there are times when TypeScript yells at me, and I just don’t know why.

I have a bad analogy using terrible stereotype but it’s like when the girlfriend gets mad at her partner and when the partner asks, “Why are you mad at me?”, the girlfriend responds “You should know. 😤”

Do you know who I call when TypeScript yells at me? Yes, I call Yishu. Because she’s the best TypeScript therapist I know.

Anyway, times are chaotic. Take care of yourselves, my friends. 🧘

Learning web extensions

Chen Hui Jing — Sat, 08 Feb 2025 21:14:50 +0000

I blinked and the first month of 2025 went by. NGL, 2024 was…challenging. So forgive me for choosing to just shut down during the end of last year. But I did do some things that I thought were worth sharing and I have deferred that until now.

It’s the first day of the Lunar New Year and I’m sitting in my childhood bedroom at mom’s house typing this up on top of her sewing machine. ¯\_(ツ)_/¯ Update: I did not finish this until 2 weeks later, don’t judge.

Why web extensions?

There was a point in time where I did a lot of conference speaking, and that died down quite a bit during the pandemic, but occasionally I will still talk to people about building stuff on the web. So I gave a talk titled “Expanding the browser experience with web extensions” at InternationalJS Singapore.

My interest in web extensions stemmed from the fact that our team at the Interledger Foundation has been working toward getting the Web Monetization standard implemented in browsers.

But most of us familiar with web standards know that realistically, getting a new feature into browsers is comparable to watching your toddler finally pack up and leave for college.

No I’m just joking.

Kinda.

The next best thing we could do was to build a web extension that would implement all the behaviours specified in the standard so we could get feedback on what we were proposing, allowing us to make adjustments to how we envisioned how the APIs would work and hopefully enhance the overall experience of web monetization.

What is a web extension?

This post will NOT be talking about what the boys did to build the web monetization because that has now become a beast of a piece of software at this point. You can read Sid Vishnoi’s blog post on End-to-end testing the Web Monetization browser extension on our engineering blog to get an idea of the scope of the extension.

No, we are going to the basics of basics of web extensions. Because we have to learn to flip over and sit up before we can even stand.

The Web Extensions community group on W3C was launched in 2021, initiated by Apple, Google, Microsoft and Mozilla with the aim of aligning on a common vision for browser extensions and to work towards future standardisation.

The heart of an extension is the manifest.json file, which is the only mandatory file that must exist in any web extension. The manifest file contains metadata about the extension, as well as pointers to other files that make up the extension.

These other files include background scripts, sidebars, popups and options pages, extension pages, content scripts and web accessible resources.

This manifest.json file has a specific syntax, and as of time of writing, the latest syntax is supposed to be v3. If you’ve never followed the development of web extensions over time, you might not be aware that there has been quite some controversy around v3.

I won’t go into all the detail but to summarise the key criticisms: v3 has reduced web extensions from being treated like a first-class application with their own persistent execution environment to being treated like accessories with limited privileges and reactive execution capabilities. This is largely a consequence of making service workers mandatory and removing the “blocking webRequest” mechanism.

Feel free to ask the Googles for more information if you’re interested.

The manifest.json

Here’s an example of an extension that does nothing but showcases the bare requirements for the browser to recognise an extension exists:

{
  "manifest_version": 3,
  "name": "AE1",
  "version": "1.0",

  "description": "This extension doesn't actually do anything",
  "icons": {
    "32": "icons/icon32.png",
    "48": "icons/icon48.png"
  },

  "action": {
    "default_popup": "nothing.html"
  }
}

Full code here: https://github.com/huijing/slides/tree/gh-pages/109-ijs-2024/extensions/AE1

The manifest.json will have the 3 mandatory keys, of manifest_version, name and version. Included in the example is also the description, icons and action keys.

Although description and icons are optional, they are required if you want to publish your extension to the Chrome Web Store. They also do enhance the user experience, because they give your extension a pretty icon and a proper description.

action determines how the extension looks like in the browser toolbar, and what clicking on it does. popup can contain any HTML content and the window will be automatically sized to fit the content.

<html>
  <body>
    <h1>Nothing</h1>
  </body>
</html>

To add some style and interactivity to the extension, CSS and Javascript can be included by link or style and script elements.

<html>
  <body>
    <h1>Nothing</h1>
    <button>Something</button>
  </body>
  <style>
    body {
      text-align: center;
    }
  </style>
  <script src="nothing.js"></script>
</html>

document.querySelector("button").addEventListener("click", () => {
  document.querySelector("h1").style.color = "tomato";
});

The environment in which the popup operates is isolated from the web page content loaded by the browser. In this example, nothing.js targets the extremely generic tag elements of button and h1, but the above code only affects the elements in the pop-up and not anything on the web page.

If you’re a frontend developer like me, you might prefer to have some visual feedback that your code has done something.

To load the extension in Firefox, you’ll have to load it up as a temporary add-on. The option to reload the extension after you made changes to the source is also available.

For Chrome, you’ll have to enable Developer Mode before you can load the unpacked extension. The same source works in both browsers.

Content scripts

When we want the extension to actually do something to the content on a web page, we will have use content scripts, which run in the context of the browser’s loaded web page. This is the only way we can access content on the page from the extension.

There are 3 ways to load an extension’s content script into the web page, namely via static declaration, dynamic declaration or programmatically. These different methods allow for the widest range of use cases, whether you want the extension to modify the default experience out-the-box or based on specific triggers.

Content scripts are isolated, in the sense that it can make changes to its own JavaScript environment without conflicting with the page or other extensions’ content scripts. Even though content scripts can access and change the DOM, they only see the “clean” version of the DOM that has not been modified by any JavaScript.

Firefox and Chrome handle this isolation behaviour differently. In Firefox, the concept is called Xray vision, where content scripts may encounter JavaScript objects from its own global scope or Xray-wrapped versions from the web page.

While for Chrome, there exists the concept of 3 kinds of worlds, a main world, an isolated world and a worker world. Each world has its own context, its own global variable scope and prototype chains.

Content scripts have access to a specific and limited set of extension APIs directly, but for other APIs, a form of message exchange is required, which we will briefly touch upon in the next example.

This extension consists of a button that will take over the entire web page and cover it with some pixel art sourced from the interwebs. Full code here: https://github.com/huijing/slides/tree/gh-pages/109-ijs-2024/extensions/AE2

{
  "manifest_version": 3,
  "name": "AE2",
  "version": "1.0",
  "description": "Activate pixel art",
  "icons": {
    "32": "icons/icon32.png",
    "48": "icons/icon48.png"
  },
  "permissions": ["activeTab", "scripting"],
  "action": {
    "default_popup": "pixel.html"
  },
  "web_accessible_resources": [
    {
      "resources": [
        "images/pixel-adventure-time.png",
        "images/pixel-cat.jpg",
        "images/pixel-city.png",
        "images/pixel-zen-garden.png"
      ],
      "extension_ids": ["*"],
      "matches": ["*://*/*"]
    }
  ]
}

For the extension to recognise and load images, they need to be declared in the manifest.json file with the web_accessible_resources key. The extension also needs the activeTab permission, which grants the extension extra privileges for the active tab only when an user interaction occurs and the scripting permission, which is required to use methods from the scripting API called in the content script.

let id;
browser.tabs.query({ active: true, currentWindow: true }, (tabs) => {
  id = tabs[0].id;
  browser.scripting.executeScript({
    target: { tabId: tabs[0].id },
    files: ["content.js"],
  });
  browser.scripting.insertCSS({
    target: { tabId: tabs[0].id },
    files: ["content.css"],
  });
});

document.getElementById("pixelate").addEventListener("click", () => {
  browser.tabs.sendMessage(id, { message: "pixelate" });
});

document.getElementById("reset").addEventListener("click", () => {
  browser.tabs.sendMessage(id, { message: "reset" });
});

browser.tabs.query() is used to obtain information about the tab we want to target, specifically, the tab ID, because the scripting method requires a tab ID to be passed into it, which makes sense since we have to specify the target we want to inject our script into, right?

Same goes for injecting CSS. Was it possible to style the stuff being injected via JavaScript? Of course, it is. Should we do it that way? It’s really up to you. I personally like my styles in CSS files, that’s all.

So what’s this sendMessage() method then? Well, because content scripts run in the context of the web page and not the extension itself, this is the way for the content script to communicate with the extension. The extension and the content scripts will listen for each other’s messages and respond on the same channel.

To access images supplied with the extension, the runtime.getURL() method is used, which converts the relative path of the image into a fully-qualified URL that the browser can render properly. And finally, the runtime.onMessage() event is used to listen for messages.

Background scripts

Another type of script that is seen in web extensions are background scripts. They are meant to monitor events in the browser and react to them accordingly. For example, if we wanted to implement keyboard shortcuts for our extension, we could make use of a background script to listen for specific commands and trigger some action accordingly.

The next example will add some keyboard shortcuts to the extension by making use of a background script. Full code here: https://github.com/huijing/slides/tree/gh-pages/109-ijs-2024/extensions/AE3.

There are some additions that need to be made to the manifest.json file to get things to work.

{
  "background": {
    "service_worker": "background.js", // v3 syntax
    "scripts": ["background.js"] // v2 syntax
  },
  "commands": {
    "_execute_action": {
      "suggested_key": {
        "default": "Ctrl+Shift+Y"
      }
    },
    "pixelate": {
      "suggested_key": {
        "default": "Alt+A"
      },
      "description": "Send a 'pixelate' event to the extension"
    },
    "reset": {
      "suggested_key": {
        "default": "Ctrl+Shift+E"
      },
      "description": "Send a 'reset' event to the extension"
    }
  }
}

The Commands API lets us define commands and bind them to specific key combinations. These commands must first be declared as properties in the manifest.json file. We then listen for an onCommand event to be fired using the background script and run whatever we want to run when the correct key combination is pressed.

There are 4 special shortcuts with default actions for which the onCommand event doesn’t fire, and _execute_action is one of them. This shortcut acts as if the user clicked on the extension icon in the toolbar.

In the background.js file, we make use of the onCommand.addListener to bind a handler to each of the commands listed in the manifest. As mentioned previously, the _execute_action command doesn’t trigger an event, so we don’t need a handler for that.

Wrapping up

This covers all the basic information required to get started with web extension development. The extension can be as simple as changing the colour of text on the page or as complicated as a full-fledged application (yes, you can use React to build your extension if you so choose).

I suppose if you’re wary of dodgy extension store downloads, you could always build your own extension to do exactly what you want it to do, so why not?

Chill day just HTML-ing and CSS-ing

Chen Hui Jing — Fri, 01 Nov 2024 12:38:36 +0000

I have not had as many chances to build websites lately because for a little over the past 100 days, I’ve been in a non-developer role at work. It’s not really my cup of tea, but I committed to filling the role and therefore I must give my best.

However, I really would very much prefer to be building websites. And so, when my friend, Kathy Giori, reached out about helping out with her company website’s redesign implementation, you cannot imagine the glee I felt. And how thankful I was that she let me run wild in her GitHub repo. I didn’t actually run wild, I branched out and made a PR, like responsible developers do. 😤

Today is my off-day, which means I get to sit in the same spot as I do when I’m at work but do something completely non-work related. Some people watch Netflix, some people play games, I indulge in my love of writing HTML and CSS.

Update: It's live! Check it out at https://tricyrcle.com/

Not a complicated web page

Don’t get me wrong, I do like the challenge of figuring out how to build all those special effects and interactions and things flying around the page, it’s genuinely fun to do that. But I also enjoy the simple, straight-forward web page.

This is a mostly single column layout, with some components within sections having side by side content. Such a design also performs very well on a narrow viewport. In the grand scheme of things, I probably spent more time trying to figure out how to get my Sequoia 15.0.1 macOS to run pip correctly so I could subset fonts than I did building this page.

Layered design with pseudo-elements

The most interesting bit of the design was this background half peaking out behind a piece of content that already had a background colour. I recognise this is a horrible description, so please refer to the image below. And if you are unable to see the image, again, I sincerely apologise for my lack of explanation skills.

Although my first thought was box-shadow but realistically, there is no way to rotate the shadow while leaving the original element untouched. If I’m wrong about this, please let me know. So I reach for my other trusty technique, the pseudo-element.

And because my brain is still time-zoned out from a month of travel, I ended up having to refer to my own blog post from 2 years ago on implementing shadow-style designs (CSS card shadow effects) to figure out how to get the pseudo-element be the same height as the parent element.

position. The answer is position. 🤦

.info-privacy::before {
  display: block;
  content: "";
  position: absolute;
  top: 0;
  left: 0;
  height: 100%;
  width: 100%;
  background-color: var(--brand-cyan);
  transform: rotate(-2deg);
  border-radius: var(--border-radius);
  z-index: -1;
}

I also had another brief moment of “eh, why is this happening” when I saw that the pseudo-element was just not in the right position. But that one came to me after a couple of minutes, so it wasn’t that bad. Remember to tell the absolutely positioned element what its offset needs to be. That’s all.

You can google math

If you look at the screenshot above, you’ll also see there are a few steps cards that are rotated in different angles. There are actually 4 of them but only 3 different colours so the fourth one is blue again. And I couldn’t figure out the n formula by myself. Thankfully, you can google math on the internet and I managed to get the answer: nth-of-type(3n - 2).

.affordable-privacy li:nth-of-type(3n - 2) {
  background-color: var(--brand-cyan);
}
.affordable-privacy li:nth-of-type(2) {
  background-color: var(--brand-chartreuse);
}
.affordable-privacy li:nth-of-type(3) {
  background-color: var(--brand-orange);
}

Did I need to do math? Not really, I could have just gone with li:first-of-type and li:nth-of-type(4) as 2 separate selectors but ¯\_(ツ)_/¯

Download CantinaVPN

So the whole reason why I was enjoying afternoon building this web page is because Tricrycle Corporation, which is Kathy’s project, now has proper branding, with a brand guidelines document and all that good stuff.

The organisation is behind CantinaVPN (Google Play/App Store), which is an affordable VPN solution that does not collect any private information from you. No registration, no login. You remain anonymous.

It’s good stuff, and if you’re wondering where the website is, well, the team is busy building the VPN software, so the website is a little on the back-burner, and that’s how I got this sliver of opportunity to help out.

Wrap up

This is a short post because there really wasn’t that much to building the page, other than the fact that I was very chill and at peace for about 2.5 hours on this off day. I also decided to take a stab at recording the whole thing just to see how it would look sped up.

Full disclosure, I realised the site needed more than just one page, so I moved the whole thing to Astro, but that took like all of 15 minutes. Which is another reason why I’m fond of Astro, it’s very close to vanilla flavoured web development, just the way I like it.

How to try experimental CSS features

Chen Hui Jing — Fri, 05 Jul 2024 01:10:21 +0000

I love that browsers are now shipping new CSS features that may not necessarily have been fully baked yet behind feature flags. I can’t actually pinpoint the exact date or event that started this, but my personal observation (because I was there) tags it at the development of CSS grid.

If you were not around for it, all the major browsers supported the stable version of CSS grid within 8 months of each other. Trust me, I took the time to check the dates in order to make this image for my talks.

Browser vendors and CSS specification authors want real-world developer feedback during the feature development process to work out the kinks in the proposals and implementations.

They had tried using vendor prefixes as an earlier approach, and we ended up with a decade’s worth of baggage, where browsers had to support property names that were deprecated in the specification because there will be people who inevitably choose to eat the marshmallow quickly instead of waiting it out and use features that are not ready in production.

When CSS grid rolled around, they tried a different approach. CSS grid was available to developers who wanted to try it out but behind feature flags in the respective browsers. This meant that the developer who decided to use the not-yet-ready feature had to bank on their audience turning on the flag themselves, and we all know that’s not likely to happen.

Which is why when browsers rolled out CSS grid in their stable versions, they did not have to worry about having to support earlier iterations of the syntax running around in the wild, because those were really quite minimal. The approach worked. And I think that’s why it has become a standard approach to how new CSS features are being released these days.

The UI of feature flags

Every browser handles their feature flags differently, and after seeing Safari’s approach for the first time today, I thought I’d summarise how the major browsers we develop on do this. I asked ChatGPT when each of the big 3 introduced feature flags and here are the answers.

🙋🏻‍♀️: when did chrome introduce feature flags?

🤖: Google Chrome introduced feature flags (also known as experimental features) with the launch of Chrome 8 in December 2010. Feature flags allow users to enable or disable various experimental features and options before they are officially released, by visiting chrome://flags in the browser.

🙋🏻‍♀️: when did firefox introduce feature flags?

🤖: Mozilla Firefox introduced feature flags, accessible via about:config, much earlier than Chrome. The about:config interface has been available since at least Firefox 2, which was released in October 2006. This interface allows users to modify advanced settings and enable or disable experimental features.

🙋🏻‍♀️: and when did safari roll out it’s new feature flag tab in developer settings?

🤖: Safari rolled out its new feature flag tab in the Developer settings with the release of Safari 13, which was introduced in September 2019. This feature, accessible through the “Develop” menu, allows developers to enable or disable experimental features and technologies in the browser.

I think these should be largely accurate, someone tell me if they’re not.

Update! ChatGPT is wrong!! Someone did tell me! Specifically Curtis Wilcox and Jen Simmons 🙇🏻

Safari

Admittedly, Safari is not a browser I use on the regular, only when testing, and it is generally a cursory load page, scroll page, move on to next page, kind of thing. So sadly, it was only recently (~~5 years~~ 10 months after release) that I noticed “Feature Flags” had a dedicated tab in Developer settings.

To me, this is a significant improvement in developer experience because it makes testing new features (not just CSS but all the other web APIs) easily discoverable and toggleable (this is not a word, I know).

The steps for Safari are:

From the menu bar choose Develop > Feature Flags…
Scroll through the list and pick what you want to try
Toggle the respective checkbox
Relaunch the browser

That’s it. Feature flags have been elevated to a first-class developer feature in Safari, given it gets dedicated menu shortcut space in the Develop dropdown. So I’m pretty impressed by this experience. You can read Safari’s documentation for more details.

Chrome

Chrome doesn’t do feature flags that granularly (at least that’s my observation). But they have had this feature for as long as since I started really deep diving into CSS. Chrome does flags in a broader manner and it can be summarised as major features, which have feature-specific flags, smaller features which take around 1-2 quarters of work under #enable-experimental-web-platform-features and very rarely, features that only ship in Canary.

The steps for Chrome are:

Type chrome://flags in your address bar
Search for the feature
Set value to Enabled
Relaunch the browser

Might be less intuitive than the Safari interface, and I’m not too sure where to find the list of features covered in under the #enable-experimental-web-platform-features flag, but still, good enough for me. You can read Chrome’s documentation for more details.

Firefox

Firefox takes the granular approach as well, but in a more “raw” manner. Basically, after you get past the Here be dragons message (I think they changed the copy but it was fun back then), you get a blank results screen that again warns you of messing up the browser. But once you click “Show all”, you will notice that the flags follow a naming convention.

I think these flag names are exposed from their usage in the source code (see StaticPrefList.yaml), because if you do it like Safari or Chrome, there’s probably an extra mapping to link the actual source code to the presentation of the feature in plain English. Just my speculation.

The steps for Firefox are:

Type about://config in your address bar
Accept the risk and continue knowing that you might screw up your browser messing with flags
Search for the feature you want
Double-click on the feature to toggle it. You can also change string values if that is relevant.
Relaunch the browser

The search function is pretty crucial here, but overall, you know which features you’re toggling, and because it covers all browser features, it’s not simply boolean, there are string and number values you can manipulate as well. I guess that’s why there’s an extra layer of here be dragons before letting you play around. You can read Firefox’s documentation for more details.

Wrapping up

Well, that’s it. Nice and short. Keep exploring, but don’t blow up your browser!

Credits: OG:image from Egor412112

Generating a weekly calendar from JSON data

Chen Hui Jing — Mon, 18 Mar 2024 02:48:51 +0000

The original purpose of this blog was for me to document solutions that I spent hours figuring out at work, which means it’s not my code therefore I cannot take it wholesale with me. I just extract the key parts, remove any references (or try to) to the original project and hopefully the next time I run into the problem, I have a solution.

Over the years, it has expanded to include code which had to be thrown away due to deprecated features, but the code is still good. Especially if I had called in favours with a smart friend to pair program the solution. You know who you are, Yishu.

Context

I needed a page that would display event data from a JSON file. The events should be displayed by month, but further broken down into columns for each week of the month.

And maybe display current month and the next month. Why not?

I wanted to keep the data file as simple as possible because it would potentially be updated by non-developers. (Some people might already be thinking, good luck with that one, but hey, sometimes I get a flash of random optimism in my life. 乁 ⁠(⁠ ⁠•⁠_⁠•⁠ ⁠)⁠ ㄏ)

So the data file looks like this:

[
  {
    "title": "ABC",
    "date": "2024-03-03",
    "description": "1-line description"
  },
  {
    "title": "DEF",
    "date": "2024-03-04",
    "description": "1-line description"
  },
  {
    "title": "GHI",
    "date": "2024-04-15",
    "description": "1-line description"
  }
]

Implementation time

What is a frontend developer other than someone who takes some raw data, massages it all around and makes sure the generated markup is semantic and fulfils layout goals? (A lot more than that but this is a big part of the job, no?)

The nice thing about Astro is that I can write the logic in plain Javascript (actually Typescript) on the component file itself. Then the plain CSS is also in the same file, wrapped in <style> tags.

The slightly more complicated part is putting the computed values from Javascript into the markup correctly. Life’s not perfect, we deal with it.

I did make an effort to make my function names descriptive, so we’ll see if I can still understand what everything does when I refer back to this code in a couple months (because the feature magically came back or something).

import eventsData from "../data/calendar.json";

const currentYear = new Date().getFullYear();
const currentMonth = new Date().getMonth();
const nextMonth = currentMonth + 1;
const months = Array.from({ length: 12 }, (e, i) => {
  return new Date(1970, i, 1).toLocaleDateString("en", { month: "long" });
});

const getISOWeekNumber = (date) => {
  const d = new Date(date);
  d.setHours(0, 0, 0, 0);
  d.setDate(d.getDate() + 4 - (d.getDay() || 7));
  return Math.ceil(
    ((+d - +new Date(d.getFullYear(), 0, 1)) / 86400000 + 1) / 7
  );
};

const allEventsGroupedByWeek = eventsData.reduce((acc, obj) => {
  const week = getISOWeekNumber(obj.date);
  if (!acc[week]) {
    acc[week] = [];
  }
  acc[week].push(obj);
  return acc;
}, {});

const eventsByMonth = (eventsData, monthIndex) => {
  const filteredEvents = {};
  for (const week in eventsData) {
    const eventsForWeek = eventsData[week].filter((event) => {
      const eventMonth = parseInt(event.date.split("-")[1], 10);
      return eventMonth === monthIndex + 1;
    });
    if (eventsForWeek.length > 0) {
      filteredEvents[week] = eventsForWeek;
    }
  }
  return filteredEvents;
};

const getWeeksOfYear = (year) => {
  const weeksArray: Array<{ start: Date, end: Date }> = [];
  const startDate = new Date(year, 0, 1); // January 1st of the given year

  // Calculate the offset to the next Monday
  const dayOffset = (8 - startDate.getDay()) % 7;
  startDate.setDate(startDate.getDate() + dayOffset);

  while (startDate.getFullYear() === year) {
    const endDate = new Date(startDate);
    endDate.setDate(startDate.getDate() + 6); // End date is 6 days after the start date (a week)
    weeksArray.push({
      start: new Date(startDate),
      end: new Date(endDate),
    });
    startDate.setDate(startDate.getDate() + 7); // Move to the next week
  }
  return weeksArray;
};

const generateWeekLabel = (year, weekNumber) => {
  const weeksArray = getWeeksOfYear(year);
  const targetWeek = weeksArray[weekNumber - 1];
  const weekLabel = `Week ${weekNumber}: ${targetWeek.start
    .toDateString()
    .slice(4, 10)}–${targetWeek.end.toDateString().slice(4, 10)}`;
  return weekLabel;
};

const replaceWeekNumber = (eventsData) => {
  for (const [key, value] of Object.entries(eventsData)) {
    eventsData[generateWeekLabel(currentYear, key)] = value;
    delete eventsData[key];
  }
  return eventsData;
};

const renderCurrentMonthEvents: {
  [key: string]: Array<{ title: string, date: string, description: string }>,
} = replaceWeekNumber(eventsByMonth(allEventsGroupedByWeek, currentMonth));
const renderNextMonthEvents: {
  [key: string]: Array<{ title: string, date: string, description: string }>,
} = replaceWeekNumber(eventsByMonth(allEventsGroupedByWeek, nextMonth));

Even though the markup looks reasonably straightforward, figuring out the correct syntax was not. Do you know how many console.log()s were needed to figure out {key.split(":")[1]}??

<section>
  <h2>
    {months[currentMonth]}&nbsp;{currentYear}
  </h2>
  <ul>
    {Object.entries(renderCurrentMonthEvents).map(([key, value], i) => (
      <li>
        <p class="week-dates" data-week-label={key.split(":")[0]}>
          {key.split(":")[1]}
        </p>
        {value.map((event) => (
          <div class="event-info">
            <p>{event.title}</p>
            <p>{event.date}</p>
            <p>{event.description}</p>
          </div>
        ))}
      </li>
    ))}
  </ul>
</section>

Might as well throw in the styling as well. It’s super uncomplicated. Grid makes life easy.

ul {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
  list-style: none;
  padding: 0;
  gap: 2em;
}

Which gives you something that ends up looking like this, if you have more entries in the data file.

Wrapping up

So now we wait and see if this feature will ever come back. I mean, if we’re still using the same tech stack and repository, I could probably just find the old file from git. But if not, future me better understand all the code in this post. We’ll see.