Когда создавать пользовательский PCF-элемент управления, а когда использовать canvas-компоненты в Power Apps

By Mirko Peters · 2026-10-27

Разберитесь, когда стоит создавать код-компоненты PCF, а когда достаточно низкокодовых canvas-компонентов в Power Apps. Сравните требуемые навыки, производительность и архитектуру.

Automatically translated with AI from the original post. Read the English original

Выбор между код-компонентами Power Apps Component Framework (PCF) и низкокодовыми canvas-компонентами определяет, will ли ваш проект успешно продвигаться или застопорится. В этом руководстве разбираются ключевые архитектурные различия, требования к навыкам, влияние на производительность и критерии выбора, которые помогут разработчикам и мейкерам подобрать подходящий инструмент для сложных задач интерфейса.

Главное

• Canvas-компоненты создаются прямо внутри приложения с помощью простых выражений без кода, что позволяет быстро выпускать решения.
• Код-компоненты PCF требуют профессиональной разработки на TypeScript, HTML, CSS и Power Platform CLI.
• Правильный выбор типа компонента предотвращает падение производительности из-за излишне сложных обходных решений и наложенных друг на друга элементов управления.
• Библиотеки платформ React и Fluent UI позволяют разработчикам создавать легковесные PCF-элементы управления, которые используют уже загруженные корпоративные ресурсы.
• При внедрении собственных кодовых зависимостей в решения Dataverse необходимо учитывать затраты на управление и долгосрочное сопровождение.

Архитектурный разрыв: мейкеры и разработчики

Рано или поздно каждое приложение Power Apps упирается в функциональный предел. Вам нужна конкретная визуализация данных, интерактивный план помещения, редактируемая таблица в стиле электронной таблицы или поле для подписи, но стандартный набор элементов с перетаскиванием просто не предоставляет такой возможности. В таких случаях команды часто прибегают к нагромождению обходных решений: прячут текстовые поля за изображениями, накладывают невидимые триггеры и связывают десяток отдельных механизмов, чтобы имитировать один цельный пользовательский сценарий. Такой подход какое-то время работает, но быстро снижает производительность приложения и создает запутанный лабиринт, в котором не сможет разобраться никто другой, кто унаследует решение.

Чтобы преодолеть этот архитектурный предел, Power Platform разделяет расширение интерфейса на два независимых пути: canvas-компоненты и код-компоненты PCF. Понимание того, где заканчивается один путь и начинается другой, необходимо для эффективного планирования приложения. Мейкеры создают canvas-компоненты прямо на холсте приложения, используя привычные формулы и без единой строки кода. Такие компоненты быстро внедряются, легко изменяются другими низкокодовыми создателями и идеально подходят для стандартных шаблонов интерфейса. Код-компоненты PCF, напротив, создаются профессиональными разработчиками. Они упаковываются как самодостаточные блоки логики пользовательского интерфейса, которые могут использоваться в model-driven приложениях, canvas-приложениях и на Power Pages.

Canvas-компоненты для скорости, PCF для возможностей

Выбирая подход для своего проекта, нужно взвесить скорость разработки против глубоких функциональных требований. Canvas-компоненты хорошо подходят, когда нужно вынести повторяющийся фрагмент canvas-приложения, например пользовательское навигационное меню или оформленную карточку, без выхода из визуального редактора. Они находятся внутри пакета приложения, беспрепятственно наследуют его контекст и не требуют конвейеров развертывания или инструментов командной строки.

Однако компоненты canvas фундаментально ограничены языком выражений и механизмом компоновки среды canvas. Они не могут выйти за пределы песочницы платформы, чтобы использовать сложные сторонние библиотеки JavaScript, отрисовать нестандартные SVG-визуализации или нативно превратить сетку в высокоплотную редактируемую таблицу данных. Здесь на сцену выходит Power Apps Component Framework. Используя Microsoft Power Platform CLI, разработчики создают настоящие веб-компоненты на TypeScript с опорой на современные веб-стандарты. Такие компоненты кода объявляют явные входы и выходы в файле манифеста, что позволяет приложению-хосту подключать данные к элементу управления без догадок о его внутреннем состоянии.

Оптимизация производительности с React и Fluent UI

Раньше создание пользовательского элемента управления с нуля означало включение в пакет всех внешних зависимостей, что часто раздувало размер файлов и замедляло загрузку. Современная разработка PCF устраняет эти накладные расходы за счёт платформенных библиотек. Разработчики могут создавать компоненты с помощью React и Fluent UI, нативной системы дизайна Microsoft, используя библиотеки, которые уже предварительно загружены средой-хостом.

Когда приложение загружает несколько пользовательских элементов управления, использующих общие платформенные библиотеки, браузер не скачивает повторно один и тот же код фреймворка. Это делает интерфейс быстрым, отзывчивым и визуально согласованным с остальной экосистемой Microsoft 365. За кулисами методы жизненного цикла компонента (init, updateView, getOutputs и destroy) отвечают за отрисовку, обновление при изменении данных и очистку памяти при размонтировании элемента управления. Такая строгая дисциплина жизненного цикла предотвращает утечки памяти и медленный рендеринг, которыми страдают любительские пользовательские внедрения кода.

Управление и реалии долгосрочной поддержки

Внедрение пользовательских компонентов кода приносит профиль обслуживания, которого низкокодовые решения обычно избегают. Поскольку элементы управления PCF требуют этапа сборки, репозитория исходного кода и развёртывания через решения Dataverse, им необходим назначенный владелец. Если первоначальный разработчик уйдёт без должной документации, пользовательский элемент управления быстро может превратиться в непонятный «чёрный ящик», который невозможно поддерживать.

Кроме того, ИТ-администраторы должны применять строгие политики управления, чтобы предотвратить распространение дублирующих или плохо оптимизированных компонентов кода в корпоративных средах. Прежде чем одобрять пользовательскую сборку PCF, архитекторы решений должны убедиться, что ни один встроенный элемент управления или компонент canvas не может обеспечить девяносто процентов требуемой функциональности. Если стандартный подход позволяет решить большую часть задачи, экономия на обслуживании почти всегда перевешивает желание добиться идеального пиксель в пиксель индивидуального решения.

Заключение

Выбор между компонентами canvas и Power Apps Component Framework сводится к соответствию технических ресурсов конкретной задаче интерфейса. Используйте компоненты canvas для быстрой инкапсуляции интерфейса без кода внутри приложений canvas, а компоненты кода PCF оставляйте для продвинутых высокопроизводительных требований, охватывающих решения на базе Dataverse. Чтобы глубже разобраться в этой теме и послушать мнения экспертов о современной разработке в облаке Microsoft, послушайте полный эпизод подкаста M365 FM Podcast.

Часто задаваемые вопросы

Можно ли использовать компоненты canvas в приложениях, управляемых моделью?

Нет, компоненты canvas предназначены исключительно для приложений canvas. Если вам нужны пользовательские элементы управления в приложениях, управляемых моделью, или в Power Pages, необходимо использовать компоненты кода Power Apps Component Framework (PCF).

Какие языки программирования нужны для создания элементов управления PCF?

Для создания пользовательских компонентов кода требуется практическое знание TypeScript (или JavaScript), HTML и CSS, а также знакомство с Microsoft Power Platform CLI для создания каркаса и упаковки.

Нужно ли конечным пользователям уметь программировать, чтобы использовать элемент управления PCF?

Совсем нет. После того как разработчик создаст и развернёт элемент управления PCF в среде решения Dataverse, мейкеры могут перетаскивать его на формы, представления или панели мониторинга так же, как любой стандартный элемент управления.

Для чего нужен файл манифеста компонента?

Манифест — это XML-файл, который объявляет метаданные компонента, ожидаемые входные свойства и выходные события и работает как схема подключений, позволяя Power Apps корректно привязывать данные к компоненту кода.