UK
English
Deutsch
Español
Français
Italiano
Português
Nederlands
Polski
Bahasa Indonesia
Русский
العربية
עברית
日本語
한국어Коли створювати власний PCF-компонент, а коли використовувати компоненти полотна в Power Apps
By Mirko Peters ·
Дізнайтеся, коли варто створювати власні компоненти коду PCF, а коли достатньо низькокодових компонентів полотна в Power Apps. Порівняйте вимоги до навичок, продуктивність і архітектуру.
Automatically translated with AI from the original post. Read the English original
Вибір між PCF-контролами Power Apps Component Framework (PCF) на основі коду та низькокодовими компонентами полотна визначає, чи успішним буде ваш проєкт, чи він застопориться. Цей посібник розбирає ключові архітектурні відмінності, вимоги до навичок, вплив на продуктивність і критерії вибору, щоб розробники та автори могли обрати правильний інструмент для складних завдань інтерфейсу.
Головне
- Компоненти полотна повністю створюються всередині застосунку за допомогою зручних для авторів виразів без коду, що забезпечує швидку реалізацію.
- Компоненти коду PCF потребують професійної розробки ПЗ з використанням TypeScript, HTML, CSS і Power Platform CLI.
- Вибір правильного типу компонента запобігає падінню продуктивності через надто складні обхідні рішення та нагромадження контролів.
- Бібліотеки платформи React і Fluent UI дозволяють розробникам створювати легкі PCF-контроли, які використовують уже завантажені корпоративні ресурси.
- Під час впровадження користувацьких залежностей коду в рішення Dataverse потрібно враховувати витрати на управління та довгострокову підтримку.
Архітектурний поділ: автори проти розробників
Рано чи пізно кожен застосунок Power Apps упирається в функціональну межу. Вам потрібна спеціальна візуалізація даних, інтерактивний план поверху, сітка для редагування в стилі електронної таблиці або поле для підпису, але стандартний набір елементів для перетягування просто не має такої можливості. У таких випадках команди часто вдаються до нагромадження обхідних рішень: ховають текстові поля за зображеннями, накладають невидимі тригери й налаштовують десяток окремих механізмів, щоб імітувати один цілісний користувацький досвід. Це працює деякий час, але швидко погіршує продуктивність застосунку та створює заплутаний лабіринт, у якому важко розбиратися кожному, хто успадкує рішення.
Щоб подолати цю архітектурну межу, Power Platform розділяє розширення інтерфейсу на два окремі шляхи: компоненти полотна та компоненти коду PCF. Розуміння того, де закінчується один і починається другий, є важливим для ефективного планування застосунку. Автори створюють компоненти полотна безпосередньо в полотні застосунку, використовуючи знайомі формули та без коду. Їх швидко розгортати, інші низькокодові автори легко змінюють, і вони ідеально підходять для стандартних шаблонів інтерфейсу. Натомість компоненти коду PCF створюють професійні розробники. Вони упаковані як автономні блоки логіки інтерфейсу, які можуть працювати в застосунках на основі моделі, застосунках полотна та Power Pages.
Компоненти полотна для швидкості, PCF для потужності
Вибираючи підхід для свого проєкту, потрібно зважити швидкість розробки проти глибоких функціональних вимог. Компоненти полотна чудово підходять, коли потрібно упакувати повторюваний фрагмент застосунку полотна, наприклад власне меню навігації чи оформлену картку, не виходячи з візуального редактора. Вони існують у пакеті застосунку, успадковують контекст застосунку без проблем і не потребують конвеєрів розгортання чи інструментів командного рядка.
Однак компоненти полотна обмежені мовою виразів і движком розмітки середовища полотна. Вони не можуть вийти за межі пісочниці платформи, щоб використовувати сторонні бібліотеки 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, архітектори рішень мають переконатися, що жоден вбудований елемент керування чи компонент полотна не може забезпечити дев'яносто відсотків необхідної функціональності. Якщо стандартний підхід дає змогу досягти більшої частини результату, економія на супроводі майже завжди переважає бажання створити індивідуальну розробку з точністю до пікселя.
Висновок
Вибір між компонентами полотна та Power Apps Component Framework зводиться до того, щоб відповідати технічним ресурсам конкретній проблемі інтерфейсу. Використовуйте компоненти полотна для швидкої інкапсуляції елементів інтерфейсу без коду в застосунках полотна, а компоненти коду PCF залишайте для складних вимог до продуктивності, що охоплюють рішення на базі Dataverse. Щоб дізнатися більше про цю тему та почути думки експертів щодо сучасної хмарної розробки Microsoft, послухайте повний епізод подкасту M365 FM.
Поширені запитання
Чи можна використовувати компоненти полотна в застосунках на основі моделі?
Ні, компоненти полотна призначені виключно для застосунків полотна. Якщо вам потрібні користувацькі елементи керування інтерфейсу в застосунках на основі моделі або в Power Pages, слід використовувати компоненти коду Power Apps Component Framework (PCF).
Які мови програмування потрібні для створення елементів керування PCF?
Для створення користувацьких компонентів коду потрібні практичні знання TypeScript (або JavaScript), HTML і CSS, а також знайомство з Microsoft Power Platform CLI для створення каркаса проєкту та пакування.
Чи повинні кінцеві користувачі вміти програмувати, щоб користуватися елементом керування PCF?
Зовсім ні. Щойно розробник створить і розгорне елемент керування PCF у рішенні Dataverse, мейкери можуть просто перетягнути його на форми, подання або інформаційні панелі, як і будь-який стандартний елемент керування.
Для чого потрібен файл маніфесту компонента?
Маніфест — це XML-файл, який оголошує метадані компонента, очікувані вхідні властивості та вихідні події. Він працює як схема з'єднань, щоб Power Apps правильно прив'язувала дані до компонента коду.