Power Apps Components – Finally also for citizen developers

Power Apps canvas components finally have access to the data of its host application ( app scope ). I am more than excited about the update.

Why is this such big news? Why is this update important? What is really changing?

Initially, the canvas components were designed for use in several different applications. As a result, making them has been far too complicated for beginners. In the real life the same component will be very rarely used in multiple applications. It is much more common to recycle the same elements within a single application.

Using components is now much easier than before, which makes it accessible to citizen developers.

Let’s go through the change with an example.

Example – Task management

Let’s build an app that presents tasks by status in their own areas. Tasks can be moved from one status to another.

So something like this.

Let’s create a new table in Dataverse for Teams. For each task, the following information is saved

• Title ( Name )
• Status ( Status )
• Creation time ( Created On , a constant field)
• Creator ( Created By, constant field)

Implementation without components

In the first version, we create a separate gallery for each status, where the tasks are presented. Each task has buttons from which you can change the status. When pressed, the task moves to another gallery.

But… We just created 18 controls on the screen. And what’s more horrible, when we make changes to the look or functionality of the task lists, we always have to make them in three places. Not good.

Components are handy in situations exactly like this.

Implementation with traditional components

First, let’s create the component like it was done before the update. Perhaps at the same time, it becomes clear why components have been used so little.

Navigate from Screens to Components, and create a new component.

Transmission of information to be displayed

The component is not aware of the application itself. It must therefore be given information about what you want to present in the gallery.

Create a new table-type property ( input custom property ) called Tasks for the component . It is used to transmit the tasks to the component from the screen.

Next, we define the structure of the Tasks table. That is, what fields the table obtained as a parameter contains.

How do we show the creator of a task on the list? Well, it’s not that simple. This is because the creator of the task is a relation to the users table. Let’s create a field for the task creator name ( CreatedByName ).

Finally, let’s create a gallery inside the component, the content of which is the table ( Tasks ) obtained as a parameter.

Next, create a screen and add the component we made to it.

The value of the Tasks property of the component is set to tasks filtered by the desired status (1). It is then stated which task fields correspond to which columns (2) of the table.

We cannot choose the name of the task creator because it refers to another table (Tasks -> User).

We add it as a separate column with the AddColumns command (1) so that it can be passed to component (2).

AddColumns(Filter(Tasks, 'Status (cra1a_status)' = 'Status (Tasks)'.Backlog), "CreatorName", 'Created By'.'Full Name')

Updating the task

The status of the task should be updated when one of the buttons is pressed. This also cannot be done with the component (in the old model), but rather the update is handled on the application side. The component only tells which row is being updated and to which state.

The update is done with the behavior property of the component. Let’s create this property ( OnStatusUpdate ) and define two mandatory parameters for it

• What record is being updated ( TaskGUID )
• New record status ( NewStatus )

Pressing the task-related buttons launches the behavior property ( OnStatusUpdate ). As a parameter, it gets the status according to the button and the task id.

The corresponding formula is added to each button in the component.

We can now react to pressing a button inside the component (i.e., an OnStatusUpdate event). We update the task we received ( TaskGUID ) to the correct state based on the parameter ( NewStatus ).

Like so.

The end result is what we wanted. The screen has only three components instead of 18 controls. The appearance of a component can be updated commonly within the component. However, some of the functionality is still defined on the screen.

I don’t think this was easy or simple.

That brings us to why I am excited about the update.

Implementation with a component that has access to application data

Let’s create another component. This time the new feature ( Acces app scope ) is turned on.

This gives the component visibility into its host application. You have access to variables (global, not context), controls, data sources, collections, images, and more.

Now only one parameter needs to be created for the component ( TaskStatus ). It defines what tasks to present.

We then filter the rows in the gallery based on the status obtained as a parameter. As if the gallery had been added to the app itself.

You can also update the status directly inside the component in the OnSelect button event. The formula used also looks much more familiar.

Let’s add three copies of the component we just made to the screen. The correct TaskStatus value ( Backlog, In Progress, Done ) is set for each .

And we are ready!

This is how components should have always worked.

Finally, we tidy up the list of tasks a bit. Naturally, the changes are made to only one location (the component).

Summary

Finally, using canvas components is so simple that you don’t have to learn it separately. With components, Power Apps are often both more efficient and more maintainable.

However, keep in mind that components implemented in this way cannot be used in other applications. In my opinion, It is a worthwhile tradeoff.