Storybook for the Power Platform.
Browse, try, configure and install PCF controls without ever opening Visual Studio.

pcfhub.dev →

Evaluating a Power Apps Component Framework control usually means cloning a repo, building it, packing a solution, importing it into a Dataverse environment and wiring it to a form — twenty minutes of work to answer one question: does this do what I need, and what does it look like?

PCFHub collapses that loop to seconds. Every published control runs live in your browser against a mock ComponentFramework context, with an editable property panel beside it, next to documentation that is versioned alongside the control's source.

The catalog is also an MCP server at https://pcfhub.dev/mcp, so an assistant can search controls, read their properties and documentation, and validate a pcfhub.json — from Claude, Cursor or VS Code, with no account needed.

claude mcp add --transport http pcfhub https://pcfhub.dev/mcp

Setup for other clients is on pcfhub.dev/api. It is listed in the official MCP Registry as io.github.pcfhub/pcfhub, and on Glama and Smithery.

The controls themselves. Each one is a public repository of its own, owned by its author, and the repository is the source of truth — PCFHub ingests it rather than building it.

The Demo column is the control's own demo.fidelity: how much of it the browser sandbox can run. Full means the real control, end to end. Limited means it renders and most of it works, but something the sandbox cannot provide — a camera, a live Dataverse, navigation — is stubbed and the page says so. Mocked means the writes go to a stand-in Web API. None means the page has docs and downloads but no live demo, usually because the host it needs (the Power Apps grid) has no browser equivalent.

Bound to one column on a form. Most are plain TypeScript; the ones marked React build on the platform's own React and Fluent, so neither is bundled.

A form has no native button. These two raise an event the app can handle — one per host, because the two hosts handle events differently.

Bound to a view — a subgrid, a canvas gallery's data source, or a related-records list — rather than a column.

Not controls a maker places, but renderers the Power Apps grid loads for a column type. They only exist inside that grid, so the hub either stands in a mock grid host or shows docs and downloads without a demo.

_template is the starting point for a new control — the layout below, already wired up, in four variants: a plain field control, a dataset control, a React (virtual) control, and a grid customizer. It also owns the shared CI: every control repository's build.yml and release.yml are thin callers of the reusable workflows in the template, pinned to @v1, so a fix to the pipeline reaches every control instead of the one that happened to be edited.

The portal that hosts all of this is a private repository; the controls are not.

A control does not have to live in this organisation to be on the hub — Code Editor, a Monaco editor for JSON, XML and other code in a multiline column, sits in its author's own account. The catalog is invite-only, and which controls get added is decided case by case.

pcf-<control>/              # from https://github.com/pcfhub/_template
├─ <Control>/
│  ├─ ControlManifest.Input.xml
│  ├─ index.ts
│  ├─ strings/              # .resx in en, es, fr, de, ja
│  └─ components/  css/
├─ Solution/                # cdsproj → managed + unmanaged zips
├─ docs/                    # overview · installation · canvas · model-driven ·
│                           # api · examples · limitations · faq · migration
├─ media/                   # logo, screenshots, poster — mirrored by the hub
├─ dev/                     # a stand-in host: npm run smoke / harness / preview
├─ scripts/                 # template setup, and the CI guard that keeps it adopted
├─ SPEC.md                  # what building it corrected: verified vs. read
├─ pcfhub.json              # the hub manifest: identity, category, links, demo presets, fidelity
└─ .github/workflows/       # build.yml + release.yml → pcfhub/_template reusable workflows @v1

Every control ships its maker-facing strings in English, Spanish, French, German and Japanese, and styles itself after Fluent whether or not it uses React.

A tagged release builds the control, packs the solution and publishes the demo bundle. PCFHub picks up the release — from a webhook within seconds, or from the hourly sweep otherwise — mirrors the artifacts, compiles docs/*.md into a version-pinned documentation set, and imports it as a draft. A person publishes it; from then on the new version appears on the site with docs, demo and downloads together.

The demo harness loads each control on a separate origin, inside an iframe without allow-same-origin, and talks to it only over postMessage. Third-party control code never shares an origin with your session. Behind that boundary sits a mock ComponentFramework context — parameters, datasets, formatting, resources and Web API stubs — so the property panel drives the real control, not a screenshot of one.

Some things a sandbox genuinely cannot do (camera, device APIs, a live Dataverse, the Power Apps grid). Where that is true, the control's page says so on the demo itself rather than quietly failing, and the repository's demo.fidelity says so up front.

The hub is invite-only: controls are added by arrangement, not by submission. If you have one you would like considered, open an issue here with a link to it. What a repository needs to be ingestible:

1. The layout _template sets up, with docs/ and pcfhub.json kept in the repo.
2. A tagged release carrying the managed and unmanaged solutions and the demo bundle.

Controls stay under their author's ownership and licence. PCFHub links back to the repository from every page and counts downloads on the author's behalf.

Questions and bug reports: open an issue on the relevant control repository, or on this one for anything about the site itself.