DEV Community: yyj-dev

One React Component, Three Display Technologies — Flip Cards, Pixel LEDs, and Seven-Segment Digits in Pure CSS

yyj-dev — Fri, 03 Jul 2026 07:28:26 +0000

I recently shipped a fullscreen clock app, digitalclock.xyz, that offers eight themes. Four of them look like a mechanical flip clock, three like a retro pixel LED display, and one like a seven-segment alarm clock. Three genuinely different display technologies — and I wanted all of them rendered by the same component tree, with zero canvas, zero SVG, and zero image assets.

That constraint turned out to be the most interesting engineering decision in the project. Here's how the architecture actually works.

A theme is just data

The first rule I set: a theme is not a component, not a CSS file, not a variant prop scattered across the tree. It's a plain object.

export type ThemeStyle = "flip" | "pixel" | "segment";

export interface Theme {
  id: ThemeId;
  label: string;
  style: ThemeStyle;
  pageBg: string;
  cardBg: string;
  cardBgGradient?: string;
  digitColor: string;
  divider: string;
  glow?: string;
  fontClassVar: "var(--font-flip)" | "var(--font-flip-mono)" | "var(--font-pixel)";
  separatorColor: string;
  subtleText: string;
}

Everything a theme knows is color tokens, an optional glow, a font variable — and one 3-value enum, style, which decides which of three rendering branches the digit component takes. All eight themes fit in a single array in themes.ts. "Flip Ocean" and "Pixel Amber" differ only in the values of these fields.

The important consequence: adding a ninth theme is a data change, not a code change. Adding a fourth display technology is a code change — one new branch — but nothing else in the tree has to know about it.

The only interface between JS and styling is custom properties

React never writes real CSS declarations inline. The digit component's inline style contains nothing but CSS custom properties:

style={{
  "--seg-on": theme.digitColor,
  "--seg-off": `color-mix(in srgb, ${theme.digitColor} 10%, transparent)`,
  "--seg-glow": theme.glow ?? "none",
} as React.CSSProperties}

Static CSS rules in globals.css consume those variables. JS decides what the values are; CSS decides what they mean. That split is what keeps three unrelated display technologies from leaking into each other — the React side genuinely does not know how a segment gets its bevel or how a flip card folds.

One detail I like a lot: the seven-segment theme only declares a single color, digitColor. The dim "off" segments are derived in that snippet above with color-mix(in srgb, <digitColor> 10%, transparent), and the glow is another derivation of the same hue. One token in, an entire lit/unlit/halo palette out. When I added the theme picker, no theme ever shipped with mismatched on/off colors, because there's nothing to mismatch.

Branch 1: pixel — the trivial case

The pixel LED branch is almost embarrassingly simple, which is the point:

if (theme.style === "pixel") {
  return (
    <span className="flip-pixel-digit"
      style={{ color: theme.digitColor, textShadow: theme.glow }}>
      {value}
    </span>
  );
}

A pixel font does the heavy lifting for the dot-matrix look, and a two-layer text-shadow (an 18px halo plus a wider 36px falloff) makes it bloom like a backlit display. The glyph is text, so the glow technique that fits is text-shadow — it hugs the letterforms for free.

Branch 2: seven-segment — the font is in the stylesheet

This is the branch people don't believe until they open devtools. A seven-segment digit renders as seven empty spans:

<span className="seg-digit" data-value={value} aria-label={value}>
  <span className="seg seg-h seg-a" />
  <span className="seg seg-v seg-b" />
  <span className="seg seg-v seg-c" />
  <span className="seg seg-h seg-d" />
  <span className="seg seg-v seg-e" />
  <span className="seg seg-v seg-f" />
  <span className="seg seg-h seg-g" />
</span>

No text content at all. The "font" — which segments light up for which digit — lives entirely in CSS as ten attribute-selector rules. It's literally the 0–9 truth table you'd find in a 7-segment decoder datasheet, written in selectors:

.seg-digit[data-value="2"] :is(.seg-a, .seg-b, .seg-d, .seg-e, .seg-g),
.seg-digit[data-value="4"] :is(.seg-b, .seg-c, .seg-f, .seg-g),
.seg-digit[data-value="8"] :is(.seg-a, .seg-b, .seg-c, .seg-d, .seg-e, .seg-f, .seg-g) {
  background: var(--seg-on);
}

React's entire job here is setting data-value="4". The cascade does the decoding.

The geometry is absolutely positioned in em units — seg-a at top: 0, seg-g at top: 0.455em, seg-d at top: 0.91em, verticals hung at the corners — so the whole digit scales with font-size like real text does. The classic tapered segment ends are one clip-path: polygon(...) per orientation, hexagons instead of rectangles.

Two branch-specific details worth stealing:

Glow: text-shadow is useless here because there's no text. The segment branch uses filter: drop-shadow(var(--seg-glow)) on the container, which follows the clipped hexagon shapes exactly — including the tapered tips.
Accessibility: a pile of empty spans is meaningless to a screen reader, so the container carries aria-label={value}. Cheap insurance for a fully decorative DOM structure.

Branch 3: flip — the only branch that needs memory

Flip is the one technology that can't be stateless, because a flip has a before and an after. The component keeps the previous value in state and runs a two-phase animation — the top half folds down over 300ms, then the bottom half unfolds for another 300ms — before committing:

useEffect(() => {
  if (value === prev) return;
  if (theme.style !== "flip") {
    setPrev(value);   // pixel/segment themes: no animation, just sync
    return;
  }
  setFlipping(true);
  timerRef.current = window.setTimeout(() => {
    setPrev(value);
    setFlipping(false);
  }, 600);
}, [value, prev, theme.style]);

Note the second early return: when the active theme is pixel or segment, the same component silently degrades into "just track the value." The flip machinery — the extra state, the timeout, the transient fold elements rendered during flipping — costs nothing on the branches that don't use it. That's what lets one FlipDigit component serve all three technologies instead of three sibling components duplicating the value-diffing logic.

The one SSR wrinkle

A clock is the canonical hydration-mismatch generator: the server has no idea what time it is in the client's timezone. My useNow hook returns Date | null, starts as null, and only picks up a real Date inside useEffect — so the server render and first client render agree on "no time yet," and the 250ms interval is purely a refresh rate after that.

What this bought me

The final tally for eight themes across three display technologies: one digit component with three branches, one theme array, and a few hundred lines of static CSS. No canvas contexts to manage, no SVG sprites to generate, nothing to preload. The DOM stays inspectable — you can watch digit 4 light up b, c, f, g in the elements panel, which also made every rendering bug a devtools problem instead of a bitmap-debugging problem.

If you want to poke at the result (devtools open, ideally), it's live at digitalclock.xyz. And if you've pushed attribute selectors somewhere equally questionable, I'd honestly love to hear about it in the comments.

What Western Devs Need to Know Before Visiting China in 2026: Alipay, WeChat Pay & the Mobile Web

yyj-dev — Tue, 23 Jun 2026 15:42:03 +0000

If you write software for a living and you're considering a trip to China in 2026, the friction you'll hit is not what you expect. The Great Firewall is the headline, but it's rarely what trips up a first-time visitor. What actually breaks your week is the small stuff: a QR code at a noodle shop, a metro turnstile that won't take your foreign card, a hotel Wi-Fi that quietly drops every request to Google.

This is a brief survival guide written from a developer's mindset: what's actually changed in 2026, what you can fix before you leave, and what you should just accept.

1. Visa-free entry now covers most Western devs

As of late 2025, China extended its 30-day visa-free transit policy to passport holders from 38 countries, including the US, UK, Germany, France, Australia, the Netherlands, and most of the EU. If you're flying in for a vacation, a conference, or even a short remote-work stretch, you may not need to apply for a visa at all — you just need an onward ticket within 30 days.

The catch: the rules per nationality drift quarterly, and the official guidance is scattered across embassy pages. I keep a more current breakdown here: FirstTripChina visa-free guide — worth checking the week you book your ticket.

2. The payment problem is the real "API" you need to integrate

China runs on two payment rails: Alipay and WeChat Pay. Cash is technically legal but vendors below the level of a 4-star hotel will look at you like you handed them a stone tablet. Foreign credit cards work at airports and big chains; they do not work at the dumpling place you actually want to eat at.

The fix that exists in 2026 — and that did not exist three years ago — is "Tour Card" inside Alipay and "International" mode inside WeChat Pay. Both let you link a Visa/Mastercard issued outside China and pay via the same QR system locals use. Setup steps (roughly):

Install Alipay (App Store / Play Store, US/EU regions both work).
Verify with passport + selfie (KYC takes about 3 minutes).
Tap Tour Card → add your foreign card → top up an in-app balance, OR enable real-time charges.
Repeat the equivalent flow in WeChat → Me → Services → Wallet → International.

Two tips that took me embarrassingly long to figure out:

Top-ups under ¥200 (~$28) waive fees; above that, you pay ~3%. Re-charge often instead of once.
WeChat Pay's International mode has a daily transaction cap that resets at midnight Beijing time, not midnight local time. Plan accordingly.

I wrote up the full setup with screenshots: Alipay & WeChat Pay setup for foreigners.

3. Your phone is a router, not just a phone

If you're traveling from a country with a "free roaming in China" plan (T-Mobile US, Three UK, some EU carriers), the bandwidth is throttled but the route is unfiltered — your traffic exits in Hong Kong or Singapore. Google, GitHub, Slack, your work VPN: all just work.

If you're not on one of those plans, you have three options:

Buy a physical or eSIM tourist plan from China Unicom HK or 3HK — these route through Hong Kong, so still unfiltered. ~$25 for 20 GB / 30 days.
Pre-install a paid VPN with a stealth protocol (WireGuard over obfuscation works in mid-2026; pure OpenVPN is detected). Test it before you land — VPN provider websites are blocked inside the wall, so you can't sign up after arrival.
Do nothing and accept that for one week, your Slack will live on Telegram, your Gmail on Outlook, and your Google Maps on Apple Maps. (Yes, Apple Maps works in China. It's surprisingly good. Baidu Maps is better.)

4. High-speed rail beats everything else for inter-city

The high-speed rail (HSR) network in 2026 is the single best argument for traveling in mainland China. Beijing → Shanghai (1,300 km / 800 mi) is 4h 18m at 350 km/h, costs ¥553 (~$77) in second class, and runs every 12 minutes. There is no airport security line, no boarding pass, no luggage check — you tap your passport at the gate and walk on.

Book through Trip.com or 12306 English in your Apple/Play store. The native 12306 app is more reliable but the English UI is rough. Buy your ticket the day before; popular Beijing-Shanghai trains do sell out on weekends.

5. The three cities most worth your first week

If this is your first trip and you have 7–10 days, the strongest itinerary I've seen:

Beijing (3 days) — Forbidden City, Mutianyu Great Wall, 798 art district. The history is the point.
Xi'an (2 days) — Terracotta Army, the Muslim Quarter night market. Worth the detour.
Shanghai (3 days) — Modern China. The Bund, Pudong skyline, plus the food scene most worth flying for.

HSR connects all three in <6 hours each leg. Full city-by-city breakdown: FirstTripChina city guides.

Short version

Check visa-free eligibility before you book — for most Western passports in 2026, you don't need a visa for ≤30 days.
Install Alipay + WeChat Pay before you fly. Their KYC requires a phone number you can receive SMS on; do it from home.
Get an HK-routed eSIM if your home carrier doesn't include China roaming.
Beijing → Xi'an → Shanghai by HSR is the optimal first-trip loop.

The country is friendlier to foreign travelers than its reputation suggests, but the friction is concentrated in the first 24 hours after you land. Front-load the prep, and the rest of the trip is a breeze.

I built PDF Dark — convert any PDF to true dark mode, 100% in your browser

yyj-dev — Mon, 22 Jun 2026 13:12:29 +0000

Why another PDF tool?

I read a lot of PDFs at night — research papers, ebooks, technical manuals. Every PDF reader I tried had the same problem: their "dark mode" was just a viewer toggle. The moment I forwarded the PDF to my Kindle or iPad, the white background blasted me again.

So I built PDF Dark — a tool that converts any PDF into a real dark-mode PDF file you can download, share, and reread anywhere.

What it does

100% browser-side conversion. Your file never touches a server. Verifiable in DevTools.
Real dark output PDF, not a viewer trick. Works on Kindle, iPad, Acrobat, anywhere.
Saturation-aware algorithm — photos and charts keep their original colors.
Free, MIT-licensed, no signup, no ads.

How it works under the hood

The conversion runs entirely in the browser using PDF.js to parse the original PDF page by page, then re-renders each page through a Canvas pipeline. The algorithm walks pixel data and inverts only low-saturation regions (text, line art, white background), while preserving high-saturation regions (photos, color charts, logos).

The output is then re-encoded as a standard PDF using pdf-lib. No server, no upload — your file never leaves your device.

Try it

Website: https://pdfdark.org
GitHub (MIT): https://github.com/1436941541/pdf-dark

Feedback welcome

This is an early version. PRs, bug reports, and feature requests are very welcome — especially edge cases (complex form PDFs, scanned PDFs with dense images, RTL languages). Drop a comment below or open an issue on GitHub.

If you read PDFs at night, give it a try and let me know what breaks.