How EHQ will start using GDS
EHQ apps like Admin UI, Blue Haven, and Bazaar grew up on different UI kits - Chakra, MUI, Ant, and more. GDS is how those teams start to converge.
EHQ is not a single frontend. It is a family of apps - for example Admin UI, Blue Haven, and Bazaar - each evolved in its own repo, with its own stack choices. Over time that meant different component libraries in production: Chakra UI, Material UI, Ant Design, and other local patterns.
That works when a team optimizes for one app. It gets expensive when the same product family needs shared UX, shared design handoff, and shared engineering knowledge across repos. Buttons, forms, and spacing get reinvented; upgrades and accessibility fixes land unevenly; design in Figma and code drift apart.
GDS is how EHQ starts to converge — one token-driven library, mapped 1:1 to Figma, instead of yet another UI kit.
GDS (@granicus/gds-core) is that shared foundation for new work and
gradual migrations.
Why move
- One language across apps - users and designers see familiar controls in Admin UI, Blue Haven, Bazaar, and beyond
- Less library sprawl - teams stop mixing Chakra, MUI, Ant, and one-offs for the same jobs
- Faster delivery - high-traffic patterns ship from the system instead of being rebuilt per repo
- Design ↔ code - Figma SPECS maps to
Gds*components so prototypes match production - Cheaper change - tokens, a11y, and visual updates land once and roll out with the package
What adoption looks like for EHQ
Adoption will not be a big-bang rewrite. Expect a repo-by-repo path:
- Start greenfield and high-traffic surfaces on GDS - new screens and shared shells use
GDSThemeProviderandGds*components first - Migrate by seam - swap buttons, fields, dialogs, and navigation where risk is low and reuse is high
- Retire legacy UI kits over time - reduce Chakra / MUI / Ant / custom islands as coverage grows, without blocking product delivery
What’s next
This article will grow with the real EHQ plan - which apps go first, component coverage, and engineer checklists per repo. Until then, the technical entry point is the same for every EHQ frontend.
See also: