Jithesh
Back to Blog

Behind the Scenes: Refactoring Glyph Catalog 🛠️

If you’ve checked out the recent update to Glyph Catalog, you already know it’s now faster, cleaner, and better organized. But behind that smooth release was a major refactoring effort. In this post, I’ll share what changed, why I changed it, and what I learned along the way.

This is less of a “what’s new” announcement and more of a developer’s journal.

The Problems With the Old Setup

When I first built Glyph Catalog, the goal was simple: display symbols with their Unicode and HTML codes in a table format. That worked fine at first, but as the collection grew, cracks started showing:

  • Nested Table Structure → I originally used a Category → Major → Minor structure but displayed everything in one large table. The Table of Contents jumped around between categories instead of having dedicated pages. It quickly became messy and hard to maintain.

  • Catch-All Routing → I used Next.js catch-all segments to handle categories, majors, and minors in a single file. It worked, but the codebase became bloated and unmanageable.

  • No Dedicated Symbol Pages → Each symbol only appeared inside a table row. There was no detailed page showing usage, examples, or reference links.

  • Messy Data Management → I stored data as multiple TypeScript objects across different folders. This made updates painful, categories inconsistent, and adding new codes difficult.

  • Search Limitations → Search was built into a dialog, showing all results at once. It couldn’t store state, was buggy when jumping to results, and didn’t scale.

  • Database Growth Issues → Seeding had no validation. Data was stored across multiple sources before being seeded, with little metadata and no logs. Adding more codes or fixing errors became frustrating.

The Refactoring Journey

Here’s how I tackled it step by step:

1. Data Validation

I added a validation layer to check for:

  • Empty fields.
  • Duplicate code points (allowed if they appear in different categories).
  • Corrupted or invalid characters.

Now, every symbol in the database is clean, consistent, and reliable.

2. Route Structure

I replaced the messy catch-all route with dynamic pages: [category] → [major] → [minor] → [symbol].

  • Each symbol now has its own dedicated page with usage, examples, and reference links.
  • Tables were removed. Instead, I use cards for categories, majors, and minors, which improves readability and navigation.
  • Logic is split across multiple pages with minimal redundancy.

3. Database Restructure

I rewrote the seeding script to:

  • Load data from a single JSON source.
  • Validate, categorize, and assign metadata automatically.
  • Store metadata and reference links separately for flexibility.

This way, adding new formats (like binary) won’t break the schema, and maintaining data is much easier.

4. Search Improvements

  • Search now has its own dedicated page.
  • State is stored in the URL for persistence.
  • Added filters for refining results.
  • Results display more items with clearer context.
  • Supports searching by both description (“arrow”) and code (“U+2192” or →).

It’s still evolving, but it’s already far better than the old buggy dialog.

5. SEO & Accessibility

  • Each symbol now has its own page → better indexing and navigation.
  • Over 1,800 symbols are now available (up from under 200).
  • Metadata and accessibility have been improved.
  • Added a blog module (adapted from my portfolio site).

Design & UX Changes

  • Cleaner Layout: Minimal design, more spacing, and better visual hierarchy.
  • More Code Formats: Unicode, Alt Code, HTML Hex, HTML Dec, Binary (with usage examples). More coming soon.
  • Scalable Design: The layout supports adding new formats without clutter.

👉 On top of these big updates, there were many minor but meaningful tweaks: dark mode was changed from a dropdown to a toggle, the primary color was slightly adjusted, theme and wording polished, and small UI details refined. These might seem minor, but together they make the whole experience smoother.

The goal: make Glyph Catalog equally useful for developers, designers, and casual users.

What I Learned

  • Validation is everything → Without strict checks, bad data spreads fast.
  • Single source of truth → A central JSON file makes updates manageable.
  • Scalability requires early choices → Small structural fixes now save major headaches later.
  • Minimal design works best → Less clutter makes symbols easier to explore.
  • SEO matters → Dedicated pages and metadata significantly improve reach.
  • Audience is key → Features should be guided by real usage and demand.
  • Content is important → A blog isn’t just extra — it helps visibility and builds credibility.

What’s Next

  • Add support for more code formats and symbol metadata.
  • Introduce advanced search (intent-based, smarter results, character selection).
  • Improve accessibility guidelines.
  • Explore ways to make Glyph Catalog more community-driven.
  • Focus on growing traffic through blogs, SEO, and consistent improvements.
  • Optimize data handling → Currently, all symbols are stored in a single file, which causes noticeable load during opening, searching, and replacements (in local only). This needs to be restructured for smoother performance.

Final Thoughts

Refactoring wasn’t glamorous — it was a lot of rethinking and rewriting — but the result is a far more solid foundation for Glyph Catalog.

If you use it regularly, I’d love to hear what you think. And if you’re a developer, maybe this behind-the-scenes look gives you some ideas for your own projects.

👉 Try the updated Glyph Catalog and let me know your feedback!

View All Posts