Hi all,
I was directed here to provide some feedback on UDF functionality - apologies if this is in the wrong place!
As a massive UDF fan who has been playing about with them a lot since their release, I have a couple of suggestions that I hope would be considered for the future of UDFs. Please let me know if you agree / disagree with any of the below, or if I'm being a numpty and what I want to be able to achieve is already achievable through the existing features.
1. Optional parameters
I would love to be able to define functions with optional parameters, similar to how the existing Navigate function has the optional parameters of Transition and UpdateContextRecord.
An example where this would be ideal is for encoding SVGs: I have a UDF (in the quote below) that encodes the SVG for the user, but can also replace the phrase "currentColor" with a provided colour value (parDesiredColour). This is useful for SVG icons copied from, for example, Bootstrap, where currentColor is present in the text, but depending on your SVG source, this would not always be the case. And sometimes your SVG might be a complete image, and the concept of a desired colour for the image would no longer make sense.
It would be great to be able to declare parDesiredColour as an optional parameter so that users would not have to add a random colour or pass in Blank( ) just to get their images correctly encoded.
funcEncodeSVG(
parSVGString: Text,
parDesiredColour: Color
) : Text = If(
IsBlank(parDesiredColour),
"data:image/svg+xml;utf8," & EncodeUrl(parSVGString),
With(
{
wthColourAsHex: funcConvertRGBAColourToHexString(parDesiredColour)
},
"data:image/svg+xml;utf8," & EncodeUrl(
Substitute(parSVGString, "currentColor", wthColourAsHex)
)
)
);
2. Non-specific Table / Collection type
It's absolutely fantastic that we can now use UDFs to create and manipulate Collections following the behavioural function update. However, there are still some functionality gaps. In my opinion, it would be fantastic to be able to have some way of passing in non-specific table objects without having to stipulate the exact schema, so that you could create functions that would be able to perform common operations on any given Collection / Table.
For example, one of the first things I tried with UDFs was creating a function that would be able to add an Index column to any passed in Table/ Collection and return the indexed table. However, I found that it was not yet in the realm of possibility. Once User-Defined Types were also added, I tried again, but this time I could not achieve my goal without having to explicitly state the columns for each table. The below works, but is not very re-usable as it will only work for a 'Project Table'. If at some point in future I decide to add another column to my 'Project Table', the whole function will fail. And of course, if I want to use this functionality with multiple collections / tables, I would need to create a new function for each one.
typProjectTable := Type (
[
{
'Project Name': Text,
'Project Start Date': Date,
'Project Length': Number //in weeks
}
]
);
typIndexedProjectTable := Type(
[
{
Index: Number,
'Project Name': Text,
'Project Start Date': Date,
'Project Length': Number //in weeks
}
]
);
funcAddIndexToTable(
parInputTable: typProjectTable
) : typIndexedProjectTable =
//Return
Ungroup(
ForAll(
Sequence(CountRows(parInputTable)),
{
'Raw Data': Table(Index(parInputTable, Value)),
Index: Value
}
),
'Raw Data'
);
Apologies if there is already some way of achieving this and I have just missed it, but the intuitive thing (at least to my mind!) would be to be able to say parInputTable is of type 'Table', and that the function returns something of type 'Table', for example. This would then mean that any table or collection that the user would want to index could be passed in.
3. UDF Libraries
It's currently difficult to share UDFs across multiple apps. You could, of course, use the Power FX Function solution components to store each UDF, but it seems as though that would quickly cause headaches when dealing with large numbers of UDFs and trying to make sure they are correctly added to all new Solutions etc.
Instead, a concept similar to the Component Library would be ideal; the ability to have a centralised location for common UDFs that you want to share in bulk to your organisation. You could have a library for all Time and Date related functions for example, that then another maker could add that library to their app and use the functions held within without having to copy and paste the code directly into their App.Formulas property. Some form of <library name>.<function name>(<parameters>) reference for use would be ideal.
This would make for more maintainable and shareable collections of functions.
Thank you for considering my points!
