Enhanced component properties

We’ve added two great new experimental features to formula based components:

• Behavior properties.  You can now fire a custom event from the component to the hosting app.  Previously, you could only fire OnReset.  You can now, for example, fire your own OnChange event from a date picker component.
• Property parameters.  You can now pass parameters for a property evaluation, similar to how you would pass parameters to a parameterized query or function in other languages.   You can now, for example, define an output property MathUtils.RandBetween  that does a calculation based on its parameters and is called like a function.

With property parameters, you can now create simple user defined functions with formulas!  There are some limitations, such as output properties must be pure without side effects, but it shows the direction we are headed.  There will be more to come in the months ahead.

As with all experimental features, this is a first look for feedback and these features may change dramatically.  Please don’t use them in production until they reach Preview.  To enable these features, toggle this switch under File > Settings > Advanced settings > Experimental features:

Behavior properties

Let’s start simple.  Imagine you’d like to create a component for collecting start and end dates.  It might look like this with two date picker controls:

Now, let’s say you wanted to know in your app if one of these two dates change.   The date picker controls have OnChange events, but until now there was no way to plumb this through to the app that hosts the component.

But now we can.  We can add a new custom property, name it OnChange, and make it’s property type Behavior:

With this in place, we can now invoke this property from within our component as if it was a function call, shown here from the OnChange for both of the date pickers:

And from within our app, we can write a function to take action when either of these date pickers change:

The result:

Great!  Easy so far.

Property parameters

Now, wouldn’t it be great if we could pass parameters to OnChange?

Let’s return to our example and pass Begin and End dates to the OnChange formula.   Down at the bottom of the component property’s definition there is a new facility for adding Parameters:

By selecting + New parameter we can add Begin with a data type of DateTime:

And after doing the same thing for End, we will have two optional parameters:

With these parameters added, we can return to our invocation in the component and update it to pass the current values from the date pickers to the event:

Finally, we update the OnChange formula in the app to use these parameters.  Here,

Note that because we added the parameters to the event, the formula’s value in the app will have returned to its default and our earlier customization will have been lost.  This is a bug that we will fix soon (sorry, we’re still experimental).

In this example, the beginning and end dates might be available in this case as output properties.  But there are other cases where there is information that is specific to the moment in time that the event was trigger, that might change by the time the formula reads it.   Using parameters fixes those values for that specific event invocation.

Pure functions

We can use property parameters in input and output properties too.  A good example of this would would be a math utilities library.  We don’t currently offer Excel’s RandBetween function in Power Apps.  But, we can recreate it using the Rand function that we do support.

Let’s start by creating a new MathUtils component with a RandBetween custom property of property type Output and Data type Number:

We’ll add two parameters to this property for the range.  Excel names these parameters Bottom and Top, of type Number.  These are both required parameters in Excel.

And with the same thing done for Top:

Within the component, we’ll define the formula for calculating RandBetween based on these parameters:

If( Top >= Bottom, 
    Round( Rand() * (Top - Bottom) + Bottom, 0 ),
    Blank()
)

Now we can call it like a function from within our app.  We will need to create an instance of this component in our app, with the default name MathUtils_1.  Here two slider controls are used as input and the result is shown in a label control:

As the sliders change, a new random number between the two is calculated.  Note that if Bottom is higher than Top that a Blank value is returned:

Wow, that’s a user defined function written in the Power Apps formula language!   Yes it is and cause for celebration.  But it is only a first step and we are starting to see some of the awkward aspects and limitations:

• RandBetween is a pure function – it does its work based purely on its input parameters.  It can’t read state in the app, such as global variables or data sources.
• RandBetween is a data flow property.  It cannot change state within the component or the app.
• The component had to be instanced.  It is a UX component that has to be placed on the screen, where in fact MathUtils has no UI at all.  It would be better if RandBetween was simply a function in a MathUtils namespace and not object oriented.

We are actively working to build on this foundation, to make this all cleaner, and address the limitations.

Enjoy and please let us know what you think in the Power Apps community forum.