brianbrady.dev

Enterprise UX / Web Components / wrapper systems

Microsoft Fabric UX Web Components

Fabric UX is more than a catalog of UI components. It is the component platform layer for Microsoft Fabric and Power BI client experiences: the place where design-system intent becomes runtime behavior, framework adapters, documentation, tests, migration guidance, and releaseable packages.

The repo has to serve product teams moving at different speeds across different stacks without letting the design system split into local interpretations. The important architectural bet is that the Web Component is the source of truth, with React and Angular wrappers acting as intentionally thin adapters around that contract.

Fabric UX as a platform

Behavior, accessibility semantics, styling hooks, slots, events, and state models live in the Web Component first. Framework users still get idiomatic ergonomics, but they do not get separate implementations that can drift away from the design system over time.

This is what makes the platform useful for enterprise migration work. A component is not only something that renders correctly once; it is a public contract that has to survive package releases, wrapper updates, documentation generation, Storybook examples, accessibility checks, and product adoption.

What matters here

  • Manage Microsoft Fabric Web and Microsoft Fabric Copilot component libraries across Web Components, Angular, and React.
  • Keep the implementation model centered on one web component source of truth instead of three competing stacks.
  • Maintain thin framework wrappers that expose the same component behavior to Angular and React clients.
  • Support enterprise Power BI client migration work with stable, reusable UI primitives.
  • Scale the library across more than 120 components without letting product teams fork behavior or interaction patterns.
120+ components across the platform
3 delivery layers: Web Components, Angular, React
2 libraries: fabric-web and fabric-copilot
5,000+ auditor fixes, inconsistencies, missing exports, and metadata gaps resolved

Architecture diagram

One implementation contract fans out to every client surface.

The Web Component owns behavior. Wrappers translate that contract into framework ergonomics. Documentation, auditing, and migration tooling keep the whole system from drifting as product teams adopt it.

01

Design intent

Specs, tokens, accessibility expectations, states, slots, and product behavior.

02

Web Component

Source-of-truth runtime contract: DOM, events, parts, forms, focus, and styling hooks.

03

Thin wrappers

React and Angular expose the same behavior without becoming separate implementations.

04

Product clients

Fabric Web, Fabric Copilot, and Power BI surfaces consume stable reusable primitives.

Storybook and docs Checklist Auditor DevKit migration plans Release evidence

Repository architecture

What the repo contains

The repository is organized like a production platform rather than a single package. It includes Fabric Web Components, Copilot-specific Web Components, React wrappers, Angular wrappers, theme packages, SVG icon and illustration packages, Storybook documentation, localization support, integration harnesses, release tooling, Checklist Auditor, MCP servers, and the Microsoft Fabric UX Agentic AI Design-to-Code DevKit.

That shape matters because the work is not only build a button. A component change can affect generated custom-element metadata, wrapper APIs, Storybook examples, README docs, package exports, change files, release notes, visual baselines, integration tests, and downstream product migrations. The repo is designed to keep those surfaces coordinated.

Runtime

Web Components, design tokens, styling hooks, slots, events, state models, forms, focus, and accessibility semantics.

Adapters

Thin React and Angular wrappers, typed props, event wiring, package exports, examples, and framework documentation.

Platform

Storybook, localization, icon packages, release tooling, checklist auditing, MCP tools, agent skills, and DevKit adoption workflows.

Web Components

The Web Component packages are the behavioral core. They define the actual elements product teams consume: attributes, properties, slots, events, parts, CSS custom properties, design token usage, keyboard behavior, focus management, accessibility semantics, and form behavior. This is where component correctness lives.

A strong component in this repo is not just visually close to a spec. It has a stable public API, predictable DOM composition, documented slots and parts, test coverage, Storybook examples, wrapper compatibility, and a path through release. That is what lets the same primitive survive real enterprise usage across many products.

Fabric Web and Fabric Copilot

The repo carries two related but distinct component families. Fabric Web Components cover the broader enterprise design system: dense operational UI, migration primitives, navigation, inputs, feedback, surfaces, and layout helpers. Fabric Copilot components cover AI-oriented product moments: prompt surfaces, contextual commands, starter cards, citations, approval flows, and Copilot-specific interaction patterns.

That split lets Copilot experiences move quickly without polluting the core component model, while still sharing the same engineering standards: Web Component source of truth, thin wrappers, documented APIs, test coverage, and release discipline.

React and Angular wrappers

The wrappers are intentionally boring, which is the point. They should not reinterpret component behavior. Their job is to expose the Web Component contract in React and Angular ergonomics: typed props, event wiring, framework-friendly imports, examples, and package exports.

Wrapper drift is one of the biggest risks in a repo like this. If React supports a prop that Angular misses, or Angular wraps an event differently, or a wrapper teaches a different composition pattern than the Web Component supports, product teams inherit inconsistency. A lot of the engineering work is keeping wrappers thin, complete, and honest.

Documentation and Storybook

Storybook is not just a demo layer here. It is part of the component contract. Stories demonstrate supported compositions, states, attributes, variants, framework usage, accessibility behavior, and migration patterns. README generation and custom-elements metadata connect implementation to docs so consumers can trust that the examples match the shipped package.

That matters for agentic workflows too. Agents need concise, reliable examples. If docs drift, agents make plausible but wrong choices. Keeping Storybook, README content, options files, and generated metadata aligned makes both humans and agents better consumers of the platform.

Component surfaces

One contract, many clients

The work spans small primitives and composed enterprise moments: avatar attributes, onboarding surfaces, Copilot-flavored experiences, and Power BI migration screens that need the same semantics in every framework.

Primitive coverage Attributes, sizes, named colors, active appearances, and state semantics.

Attributes

Shapes

J J

Sizes

JJJ JJJ JJJ JJJ

Named Colors

Active States

J J J
Composed experiences Framework wrappers need to preserve content slots, actions, focus, and product-specific interaction details.

SWAP WITH CONTENT

Create a component with auto-layout and then swap the component.

Welcome

Use the power of AI to help you summarize documents, highlight key points, find specific information, and more.

Try Later Next

My role

My work in Fabric UX sits across the platform boundary: component implementation, wrapper consistency, audit automation, and agentic development infrastructure. I help keep the Web Component model authoritative while making it usable from Angular, React, product migration code, and AI-assisted workflows.

The through-line is drift control. Fabric UX has to scale across hundreds of components, multiple frameworks, Copilot-specific surfaces, and product teams migrating at different speeds. My work focuses on keeping that system coherent: one behavioral source of truth, thin wrappers, generated evidence, deterministic audits, and agents that accelerate the work without becoming the source of truth.

Auditing and component health

Checklist Auditor is one of the repo's most important leverage points. It turns component health from review folklore into executable rules. It checks for missing exports, incomplete wrapper coverage, stale README sections, missing Storybook argTypes, options/type mismatches, undocumented APIs, inconsistent slots or parts, contract drift, and repeat violations across the component catalog.

When the auditor resolves thousands of issues, it is not just cleaning up lint. It is removing friction from every future migration: fewer missing imports, fewer broken examples, fewer undocumented behaviors, fewer wrapper surprises, and fewer one-off review comments.

Its first major pass resolved more than 5,000 bugs, inconsistencies, missing exports, documentation gaps, metadata gaps, wrapper mismatches, and checklist violations. That changed component health from a manual review burden into a repeatable engineering system.

Agents and skills

The repo also contains a growing agentic layer: skills, instructions, MCP tools, PR review workflows, component scaffolding, component specs, Storybook debugging, unit-test guidance, release workflows, DevKit packaging, and ADO automation. These are not random prompts. They encode repository practice so agents can operate with the same constraints a maintainer would use.

Good agents in this repo are deliberately constrained. They read the right instruction files, respect component patterns, avoid invented compositions, generate change files when required, run the right validations, and file precise issues when Microsoft Fabric UX cannot satisfy a requirement. That turns AI from a code generator into a maintainer assistant.

DevKit relationship

The Microsoft Fabric UX Agentic AI Design-to-Code DevKit grows out of this repo's operating model. The repo contains the component source of truth; the DevKit packages the evidence-gathering, parity analysis, Figma intake, issue filing, and migration planning needed to use that source of truth correctly from product repos.

The DevKit is not separate from Fabric UX. It is the adoption layer for the component platform. It helps product teams decide when to use Microsoft Fabric UX, when to keep an existing component, when to file a feature request, and when to file a bug. Then the work loops back into this repo as component fixes, wrapper updates, docs, examples, and tests.

Deterministic tools + agentic workflows

A platform that can learn from its own usage

The result is a component platform that can learn from its own usage. Product migrations reveal missing capabilities. Checklist Auditor turns repeated review comments into rules. Agent workflows convert design and repo evidence into structured plans. Upstream fixes become reusable primitives instead of local patches.

Fabric UX is the system that keeps those loops connected: implementation, documentation, wrappers, validation, migration, and feedback all moving through one repo.