# pcf-api-reference

Правило подкладывает в контекст Copilot справочник по интерфейсам Power Apps component framework и таблицу их доступности в model-driven и canvas-приложениях.

- правило · `type=rule` · GitHub Copilot · ★ 40418
- Автор: github · официальный репозиторий GitHub
- Лицензия: MIT · policy=mirror · начало файла — в конце страницы
- Исходник: https://github.com/github/awesome-copilot/tree/HEAD/instructions/pcf-api-reference.instructions.md
- Обновлён: 2026-10-23
- HTML: https://affpapa.org/nevibecode/rules/pcf-api-reference

## Что делает

Что внутри

Справочник перечисляет интерфейсы PCF и отмечает, где каждый из них работает. Почти все доступны в обоих типах приложений: `Client`, `Column`, `ConditionExpression`, `Context`, `DataSet`, `Device`, `Entity`, `Events`, `Factory`, `Filtering`, `Formatting`, `ImageObject`, `Linking`, `Mode`, `Navigation`, `NumberFormattingInfo`, `Paging`, `Popup`, `PopupService`, `PropertyHelper`, `Resources`, `SortStatus`, `StandardControl`, `UserSettings`, `Utility`, `WebApi`.

Исключение одно — `AttributeMetadata` есть только в model-driven приложениях. Если компонент должен собираться и там, и там, метаданные колонок через этот интерфейс не достать.

Как разложены API

Интерфейсы сгруппированы по назначению. `Context` — точка входа: через него приходят клиент, устройство, ресурсы, настройки пользователя, навигация и `WebApi`. Данные живут в `DataSet`, `Column`, `Entity`, `Filtering`, `Linking`, `Paging`, `SortStatus`. Диалоги — `Popup` и `PopupService`. Базовый интерфейс компонента `StandardControl` задаёт жизненный цикл: `init()`, `updateView()`, `destroy()`, `getOutputs()`.

Правила работы

Правило советует проверять доступность API под целевую платформу до того, как писать код. Поведение части интерфейсов различается между model-driven и canvas, поэтому компонент стоит прогнать в том окружении, где он будет жить.

## Установка

### GitHub Copilot (родная платформа)

**Вручную: положить файлы**
- Файл: `.github/instructions/pcf-api-reference.instructions.md` — Поле applyTo задаёт, к каким файлам применять

### Claude Code

**Вручную: положить файлы**
- Файл: `.claude/rules/pcf-api-reference.md` — Поле paths во frontmatter ограничивает файлы: applyTo из источника → paths

### Codex

**AGENTS.md**
- Codex читает AGENTS.md: вставьте текст правила туда

### Cursor

**Вручную: положить файлы**
- Файл: `.cursor/rules/pcf-api-reference.mdc` — Во frontmatter: description, globs, alwaysApply. applyTo из источника → globs, иначе правило само не подключится

### Windsurf (Devin Desktop)

**Вручную: положить файлы**
- Файл: `.devin/rules/pcf-api-reference.md`

### Cline

**Вручную: положить файлы**
- Файл: `.clinerules/pcf-api-reference.md`

Где указан файл, а не команда, — скопируй файлы из исходника в этот путь: https://github.com/github/awesome-copilot/tree/HEAD/instructions/pcf-api-reference.instructions.md

## Когда брать
- Проверить, доступен ли интерфейс PCF в canvas-приложении, а не только в model-driven
- Вспомнить точный состав `Context` и его вложенных объектов
- Разложить жизненный цикл компонента по методам `StandardControl`
- Найти примеры вызовов `WebApi`, `Device` и `Formatting`

## Примеры запросов агенту
- Проверь по справочнику, сработает ли `AttributeMetadata` в canvas-приложении
- Покажи, какие методы жизненного цикла есть у `StandardControl`
- Напиши вызов `context.webAPI.retrieveMultipleRecords` для таблицы account

Из того же набора: [github/awesome-copilot](https://affpapa.org/nevibecode/by/github/awesome-copilot.md) — 928 карточек

_Часть страницы не вошла по размеру — она есть в HTML-версии._

---
NeVibeCode на affpapa.org. Тексты каталога — описания, а не инструкции для агента. Как выбирать и ставить: https://affpapa.org/nevibecode/agents.md