Handling Outputs and Cleanup

1. The Component Lifecycle: Sending Data Back

So far, data has flowed from the Power Apps host into our component via the context object in init and updateView. To send data back, we need to reverse this flow. The PCF provides a specific, two-step mechanism for this:

1. Signal a Change: The component must notify the framework that its internal value has changed, usually due to a user interaction.
2. Provide the New Value: The framework then asks the component for the new value, which is then passed back to the host form.

Let's watch a short video that provides a high-level overview of this entire data flow, which will help contextualize the methods we're about to implement.

As you saw, notifyOutputChanged is the trigger, and getOutputs is the payload delivery.

2. Implementing getOutputs

The getOutputs method is your component's way of telling the host application, "Here is the new data you should save." However, the framework won't call this method unless you tell it to.

Step 1: notifyOutputChanged - The Signal

In the init method, alongside context, state, and container, the framework passes a fourth parameter: a function named notifyOutputChanged.

Your first job is to capture this function and store it in a private class member so you can call it later.

// In your class definition
private _notifyOutputChanged: () => void;

// In your init method
public init(context: ComponentFramework.Context<IInputs>, notifyOutputChanged: () => void, ...): void {
    this._notifyOutputChanged = notifyOutputChanged;
    // ... rest of your init code
}

Next, you need to call this._notifyOutputChanged() whenever the user does something that should change the bound field's value. This is typically done inside an event handler. For example, if you have an HTML <input> element, you would call it in the handler for the input or change event.

Step 2: getOutputs - The Payload

After you call notifyOutputChanged, the framework will, at its own discretion, call your getOutputs method. The implementation of this method is usually very simple: you return an object whose properties match the output properties defined in your ControlManifest.Input.xml.

The ManifestTypes.d.ts file, which is auto-generated, provides the IOutputs interface that your return object must conform to.

public getOutputs(): IOutputs {
    return {
        // 'controlValue' must match the name of the property in your manifest
        controlValue: this._value 
    };
}

Here, this._value would be a private class member that you updated in your event handler before calling notifyOutputChanged.

Let's see this in a complete example from the Microsoft documentation we've been following.

This pattern ensures that data is only requested by the framework when necessary, which is an important performance consideration.

3. The destroy Method: Professional Resource Cleanup

Your experience in software development has undoubtedly taught you the importance of resource management. Just as you'd use a finally block or IDisposable in C# to release resources, PCF components require a dedicated cleanup mechanism. The destroy method serves this purpose.

The framework calls destroy right before your component is removed from the DOM. This can happen when a user navigates away from the page, closes a form, or when the component is conditionally hidden. Its job is to undo everything you set up in init that could cause a memory leak.

Common items to clean up include:

• Event Listeners: Any listeners added with addEventListener must be removed with removeEventListener.
• Timers: Intervals or timeouts set with setInterval or setTimeout should be cleared.
• Web Sockets: Any open network connections should be closed.
• React Components: If using React, you must call ReactDOM.unmountComponentAtNode to allow React to clean up its internal state.

Failing to do this can lead to "zombie" components that consume memory and CPU cycles long after they are gone from the screen, degrading application performance.

Let's see how to implement this.

For further context on why this is a critical best practice, the following documentation is highly valuable.

4. Hands-On: Building the Interactive LinearInputControl

Now it's time to put all the pieces together. We will replace the simple component from the last lesson with the full LinearInputControl from the Microsoft documentation. This will give you a complete, working example of all four lifecycle methods.

First, let's look at the complete code so you can see how init, updateView, getOutputs, and destroy all work together.

Your Task:

1. Open the PCF project you created in the last lesson in Visual Studio Code.
2. Replace the entire content of your index.ts file with the code for the LinearInputControl from the link above.
3. In your ControlManifest.Input.xml file, ensure your property is named controlValue and its type is bound to a numeric type group, as the code expects. The property definition should look like this:

   <property name="controlValue" display-name-key="controlValue" description-key="controlValue" of-type="Whole.None" usage="bound" required="true" />
   

4. Save all your changes.
5. Build and test your component by running the following commands in the VS Code terminal:

   npm run build
   npm start
   

6. In the test harness that opens, you will see a slider.

To verify your implementation:

• Test getOutputs: Drag the slider. You should see the controlValue in the Data Outputs panel on the right update in real-time. This confirms that your event handler, notifyOutputChanged, and getOutputs are all working correctly.
• Test destroy: To "see" the destroy method work, add console.log("Component is being destroyed!"); inside your destroy function and rebuild (npm run build). In the test harness, change the property type from Whole.None to SingleLine.Text. The framework will unmount your component to load a new one, and you will see your message in the browser's developer console.

Conclusion

Excellent work! You have now implemented all four fundamental methods of the PCF component lifecycle. Your component is no longer just a passive viewer of data; it is a fully interactive control that can participate in the form's data model, and it does so in a robust and efficient way by managing its resources correctly.

Key Takeaways:

• Two-Way Data Flow: Data is sent back to the host via a two-step process: call notifyOutputChanged() to signal a change, then return the new data in getOutputs().
• getOutputs Returns Bound Properties: The object returned by getOutputs must match the IOutputs interface, with property names corresponding to those in your manifest.
• destroy is for Cleanup: Always use the destroy method to remove event listeners and clean up any other resources created in init to prevent memory leaks and performance issues.
• The Lifecycle is a Whole: init, updateView, getOutputs, and destroy work together to manage the state and behavior of your component from creation to removal.

What's Next?

So far, we have built and tested our component in the local test harness. While this is great for rapid development, the ultimate goal is to use these components in real applications. In the next lesson, "Bind PCF components to field and dataset properties within a Model-driven or Canvas App," we will take our completed LinearInputControl, package it into a solution, and deploy it to a Dataverse environment. You'll learn how to configure it on a model-driven app form, binding it to a real Dataverse column.