Binding PCF Components to App Properties

1. From Local Harness to Live App: Field-Bound Components

The local test harness is excellent for rapid development, but a component's true value is realized when it's part of a live application. The first step is to package it into a Dataverse solution. Since you're interested in professional development practices, we'll use the Power Platform CLI for this process.

Packaging and Deploying Your Component

The process involves creating a solution project, referencing your PCF component within it, and then building the deployable package. The following video provides a clear, step-by-step walkthrough of this entire workflow.

To summarize the key steps from the video for packaging:

1. Navigate to your project's root folder in the terminal.
2. Create a new sub-directory for your solution files (e.g., mkdir solution and cd solution). This keeps your component and solution projects separate and organized.
3. Initialize a solution project using the CLI: pac solution init --publisher-name <YourPublisherName> --publisher-prefix <yourprefix>.
4. Add a reference from the solution project back to your component project: pac solution add-reference --path <path-to-your-pcf-project>. The path should point to the directory containing the pcfproj file.
5. Build the solution using MSBuild: msbuild /t:build /restore. This command creates the deployable .zip file in the solution/bin/debug folder.

Binding the Component in a Model-driven App

Once your solution is built and imported, you can bind your component to a field on a form. The final part of the video demonstrates this configuration.

This process of switching a standard control for your custom PCF component is a fundamental skill. As noted in the video and Microsoft's documentation, this configuration is often still done via the classic solution editor, as the modern interface may not yet support all PCF configuration options.

2. Replacing Grids with Dataset-Bound Components

While field components modify a single data point, dataset components are more powerful: they can be bound to a collection of records. This allows you to replace entire views or subgrids with a completely custom user experience.

Manifest and Code Differences

The primary difference starts in the ControlManifest.Input.xml. Instead of a <property> tag, you define a <data-set> tag.

<data-set name="records" display-name-key="Records">
  <!-- property-set definitions for columns go here -->
</data-set>

In your index.ts, you then access this dataset via context.parameters.records (or whatever name you provided). You can iterate through its columns and records to render your custom grid.

The following video provides a concise overview of creating and configuring a dataset component.

Configuring a Dataset Component

As you saw, a dataset component is not configured on a field but on a grid. You can apply it to:

• A table's main grid (e.g., the default 'Active Accounts' view).
• A subgrid on a form (e.g., the list of Contacts on an Account form).

For detailed, step-by-step instructions on configuring these components, the official Microsoft documentation is an excellent reference.

3. Binding Components in Canvas Apps

Canvas apps also support PCF components, but the integration model is different and designed to align with the Power Fx formula-based paradigm.

The high-level process is:

1. Enable the Feature: An administrator must enable the "Power Apps component framework for canvas apps" feature in the environment settings.
2. Import Component: In the canvas app editor, you don't use solutions in the same way. Instead, you go to Insert > Get more components, select the Code tab, and import your desired component into the app.
3. Bind Properties: Once imported, the component appears in the Insert panel under "Code components". You add it to a screen and then bind its properties using Power Fx formulas. A dataset component, for example, will have an Items property that you would bind to a data source, like Search(Contacts, txtSearch.Text, "fullname").

The following tutorial provides a complete walkthrough of this process. Your task is to focus specifically on the deployment and configuration part.

Conclusion

Fantastic work today! You have successfully bridged the gap between local PCF development and real-world application. You now understand the critical process of packaging, deploying, and binding components in both model-driven and canvas apps.

Key Takeaways:

• Packaging is Key: PCF components must be packaged into a Dataverse solution for deployment, typically using pac solution and msbuild commands.
• Two Binding Types:
  • Field components are bound to a single column via the Controls tab of a field on a form.
  • Dataset components are bound to a table of records via the Controls tab of a view or subgrid.
• App Types Differ: Model-driven apps use solution imports and configuration in the form/view editor. Canvas apps use a direct component import feature and property binding with Power Fx.

What's Next?

So far, our components have been able to render data passed to them. But what if a component needs to fetch additional data on its own or update records directly? In our next lesson, we will explore how to "Use the ComponentFramework.WebApi to perform CRUD operations against Dataverse data from within a component." This will empower you to build even more powerful and self-sufficient components.