Building an Iframe-Based Gallery Control in Power Apps (PCF)
Functional Overview
From a functional perspective, the control does three main things:
-
Loads a web resource inside an iframe
-
Sends data to the iframe to render a gallery
-
Listens to user actions from the iframe and exposes them as outputs
What the User Sees
-
A gallery rendered inside an iframe
-
Data-driven columns and rows
-
Actions like:
-
Selecting records
-
Editing a single record
-
Deleting one or many records with a reason
-
Copying a record
-
All UI logic lives inside the iframe. The PCF control acts as a bridge between Power Apps and that UI.
Key Inputs and Outputs
Inputs (from Power Apps)
The control expects JSON-based inputs:
-
webResourceUrl – URL of the HTML/JS gallery
-
columnsJson – Column definitions
-
dataJson – Records to display
-
deleteReasonJson – Allowed delete reasons
These are passed as strings and parsed at runtime.
Outputs (to Power Apps)
The control exposes two outputs:
-
selectedRecordJson
-
actionType
Together, these tell Power Apps:
-
What the user did
-
Which records were affected
-
Any additional data (like delete reason)
Technical Architecture
PCF as a Message Broker
This control deliberately avoids rendering UI directly in PCF. Instead:
-
The PCF control hosts an iframe
-
Communication happens via
postMessage -
Data flows both ways
This keeps the PCF logic simple and lets the UI evolve independently.
Initialization Flow
init()
The init method sets up everything:
-
Stores context and callback
-
Creates the iframe
-
Loads the web resource URL
-
Registers a global
messagelistener
Once the iframe loads, the control immediately sends initialization data.
Sending Data to the Iframe
sendDataToIframe()
This method prepares and sends data required by the gallery UI.
Steps:
-
Parse JSON safely using
try/catch -
Store delete reasons locally
-
Send everything using
postMessage
If invalid JSON is passed, the control fails gracefully and sends empty arrays.
Handling User Actions
handleIframeEvents()
This is the core interaction logic.
The iframe sends messages with a type and payload. The control listens and translates those into Power Apps outputs.
Supported actions:
| Action Type | Description |
|---|---|
| SELECTION_CHANGE | Multiple record selection |
| EDIT | Single record edit |
| DELETE | Single delete with reason |
| BULK_DELETE | Multiple deletes with reason |
| COPY | Copy a record |
Each case sets:
-
actionType -
selectedRecordsJson
Then it calls:
This tells Power Apps to re-evaluate formulas and react.
Output Structure Examples
Selection Change
Delete / Bulk Delete
Copy
The format is intentionally flexible so Power Apps can branch logic easily.
Update and Lifecycle Handling
updateView()
Whenever inputs change (new data, refreshed view), the control:
-
Updates context
-
Re-sends data to the iframe
This keeps the UI in sync without reloading the iframe.
destroy()
The control cleans up properly by removing the event listener:
This avoids memory leaks when navigating between screens.
Why This Pattern Works Well
This design offers several advantages:
-
Separation of concerns
UI logic lives outside PCF. -
Reusability
The same iframe UI can be reused elsewhere. -
Flexibility
Complex UI frameworks can be used inside the iframe. -
Simple PCF code
The control focuses only on data flow and events.
Final Thoughts
This iframe-based PCF control is a solid pattern when you need rich, custom UI without fighting PCF rendering limits. By using postMessage, you get a clean contract between Power Apps and your UI layer.
Comments
Post a Comment