Unanswered

Communication between PCF component runtime and host form's JavaScript environment

(0) Share

Report

Posted on by liun

Hello

Can someone comment on the communication between PCF component runtime and host form's JavaScript environment. It's been stated that "Unlike HTML web resources, code components are rendered as a part of the same context, load at the same time as any other components, providing a seamless experience for the users."

However, the runtime environment's "window" object is actually different than the "window" object exposed to the form script, suggesting that they may not be on same frame and share same JS space. It can be easily confirmed by put a stop point in any PCF code debug session and exam the window object and compare.

If the two Js context are different, is there a way to bridge them, so that it's possible to invoke a public function defined in the form script in the PCF code? I can see using a field and pass the value between them, but seems overkill and the model design would be a bit awkward. With web resource it is possible to use the window.Xrm object to bridge the two environment.

Please comment if you have looked into this issue.

Thanks in advance.

Categories:

Power Apps Pro Dev & ISV

I have the same question (0)

All responses (4)

Answers (0)

Sort by

ScottDurow 1,039 on at

Like (1)

Report
Copy link

Link copied!

Hi @liun,
HTML Webresources are loaded into child IFrames and even JS Webresource are loaded into the ClientApiFrame which is a child IFrame script host - the PCF code is actually loaded into the main form IFrame window host where the Unified Client HTML is hosted. Although it is possible to hack calling a function on the child JS Frames from a PCF component I would think that this wouldn't a be good idea due to the unsupported nature.
It is definitely awkward passing values back and forth using bound attribute values - and so I expect that this will be made easier in the future with PCF Framework.
You can still access the Xrm.Page API from a PCF component to grab a reference to an IFrame control - which is also unsupported - but definitely much less unsupported than calling a function directly via the window frames references.

Hope this helps!

Was this reply helpful? Yes No
liun 48 on at

Like (0)

Report
Copy link

Link copied!

@ScottDurow Thanks! Looked at the debug console a bit more, it looks like the PCF code is at root top frame, but the actual form script is in a child frame, I was thinking the opposite way because the PCF is part of the form.

With that structure, if I want the PCF code to execute a custom function on entity form, I just need to expose that form function to the parent via a separate namespace. It's not really accessing the DOM directly like the getElementById stuff, so I have an argument about "supported" , especially "parent", "window" object is all over the sample code.

That would save me the need to create dummy fields just for the sake of passing data around, which could get frowned upon by the data people.

There were talks about "unbounded" control in this forum early on, but seems not getting much attention.

Was this reply helpful? Yes No
Hemant Gaur Microsoft Employee on at

Like (1)

Report
Copy link

Link copied!

Currently using the bound fields is the only supported way for PCF control to talk to environment (model form or canvas) and this maintains the PCF isolation and reuse modularity. Form structure and nesting can change under the hood and control functionality can be impacted so using the supported patterns is strongly suggested. App source validation will flag and block invalid patterns.

Adding 1st class declarative way for controls to communicate events (or behavior) like canvas apps is in our roadmap. Please use https://aka.ms/PCFIdea to share community votes which help us prioritize.

hemant

Was this reply helpful? Yes No
Community Power Pla... Microsoft Employee on at

Like (1)

Report
Copy link

Link copied!
Hi @liun
The idea is create a "common access point" so that PCFs can communicate with each other and receive external commands.
It is similar how the Unified Service Desk use to communicate with the Host Controls.

Define a common interface tho add on controls:

export interface IHostedControl { DoAction(action: string, data: string | null): void; }

Implement the interface:

export class StaticOrchestrator implements ComponentFramework.StandardControl<IInputs, IOutputs>, IHostedControl { public DoAction(action: string, data: string | null): void { //your logic }

Import the class PCF and on init() method, register the control:

import { PCF } from "./PCF"; public init(context: ComponentFramework.Context<IInputs>, notifyOutputChanged: () => void, state: ComponentFramework.Dictionary, container: HTMLDivElement) { this._id = PCF.AttributeLogicalName(context.parameters.sampleProperty); PCF.Register(context.parameters.sampleProperty, this); }

On browser, usign Javascript or by other controls, just call:

classes.zip

Was this reply helpful? Yes No