Components |Functions |June Expermental |Breaks Code Libs created using components

[PeterCBell_au]

Creating Canvas Powerapps.

I have a number of components with properties and parameters that interact (eg. date functions specific to my industry) .

I used component output properties to provide functions and those properties used other properties (passing parameters) within the same component. ie. FuncA with parameters a and b may call Func1 and Func2.  (eg. property FuncA returns Self.Func1(a,b) * Self.Func2(b) + Self.Func3(a) etc.)

The new restriction means that a data output doesnt have parameters and may only reference the controls on the component (ie. not suitable for general purpose calculations)  --> Any of my outputs (that were emulating an output function) that referenced other properties in the same component are now broken.

The output functions may only perform calculations using their own parameters and cannot call other functions in the component.

So... How do I build a base library of functions that can be called by other functions?

Previous documentation suggested 'user defined functions' defined in the app formulas section would be coming, and would be of the form... 

                      udfTest(par1:Number , par2:Number, par3:Number):Number=  (par1*par2)/par3

I was hoping that when this was released I could move code out of components and create a number of UDF procedures that were callable from within the app (and by components with app scope) and could call each other.

But trying to enter a udf (using the syntax above) fails. Have UDF's been implemented but using some other syntax??

Related to the above, I dont follow the documentation regarding input functions for components- how do I define a function in the app that has parameters that the input function can make a callback to (ie. a udf as mentioned above)? 

from... "learn.microsoft.com/en-au/power-apps/maker/canvas-apps/component-properties""

"The app could define the function expression to return $"{firstname} {lastname}" or it could choose to define an expression for $"{lastname}, {firstname}". The component can just call the function the app maker has provided, and use the returned string."

[Ramspevi]

Thanks for your in depth answer. 

I understand and I do really appreciate the work and effort you and the whole team is putting into it! It does show. Since I started my journey 2 years ago it's amazing to see how far PowerApps has come.

Thanks for forwarding my feedback.  😊

[qwertyuiop]

Hi JorisdG,

I just saw that the new analysis engine is available in the experimental features. Are we going to see the UDF functionality sooon?

Thanks

[PeterCBell_au]

Hi Joris

 Please excuse this rather long post. I have used canvas for a few years now. I know that as a product develops inconsistencies develop, with the difficulties associated with maintaining backward compatibility.

For me, as apps have become bigger with more screens and components life has become a bit difficult in powerapps. With the ongoing development and pending release of UDF's, might I make some observations and suggestions regarding the coding environment?

#The use of Self and Parent can be confusing, especially in components (eg. Self may refer to a controls properties or to the component controls, data, etc and parent may refer to a controls hosting component or a control container). I can use the explicit component name, but..

Wouldnt it be better to have a reserved word 'component' where the use of component.x refers to a control or property x of the current component and a reserved word 'host' for use when referencing an object hosted by the current screen (eg. host.width instead of parent.width or myscreenname.width)?

#Set used for both global variables and local variables within components. Within components the use of Set(x,..) maintains a property x which is limited to internal use within the component. Especially if app scope is enabled, it can be confusing what the scope of x is...

Perhaps a SetLocal(x,...) function which allows use of x within the component only and references to x requiring Local.x

#UpdateContext and knowing what is or isnt local. Allowing local variables limited to the scope of a screen sees the UpdateContext() function maintaining an internal record of variables local to the screen it is used in (ISR). When variables defined in that record are used it isnt obvious that they are local...

In line with above, allow SetLocal(x,..) to patch the ISR and use Local.x to reference property x within the ISR?

#Components and controls within a screen default to app scope. Allowing processes to reference a controls or components in other screens, it seems to me, should only occur with very specific intent. Personally, I only do that for global components, as a work around for code libraries. It also creates a burden for the formula editor intellisense.

Perhaps controls and components within screens should have an appscope property defaulting to off for newly added objects and on for backward compatibility?

#Formulas. Formulas are, to my mind, a means of maintaining an on demand variable, which would be equivalent to SetOnDemand(x,...),  which recalculates x when used and/or a dependent changes. Having those in app.Formulas means they are all global variables, tends to break the app if there is a single error in that store, and leads to a large app.Formulas section.

I think each screen having its own OnDemand store that manages local OnDemand variables would be an improvement.

#Code Blocks. At the moment, reusable code is often stored in hidden icons/buttons and Select() is used to execute code. In effect, no parameter code blocks.

Apart from being messy and difficult to maintain, it creates problems if the interpreter, in the name of responsiveness, ignores hidden controls until they are visible.

Would it be better for both the app and each screen to have their own CodeBlock stores, containing one or more code blocks- code blocks being able to access local variables, global variables, controls within the current screen (for a screen codeblock), etc. ?

#UDF. A UDF store, to my mind, would store a set of functions that only reference passed parameters.

Again, there could be app.UDF and screen.UDF stores?

Since they are different in concept to on demand formulas, would they be better having their own stores?

#UDF parameter types. I hope that UDF's will accept controls as parameters. eg. UDF: CenterControlX(c as label) as integer;return  (c.parent.width-c.width)/2

#UDF code. I hope UDF's wont simply be power FX with parameters but will allow intermediate calculations with a return type. eg. SetLocal(x,..);SetLocal(y,...);Return x+y

#Discovering table and record variables properties. When a variable is selected in the formula bar it would be useful, along with its current value and data type, to have a link to see its schema (as understood by Power FX at that instant).

#Screen instantiation. There is usually code that ends up being in the screen.OnVisible event that should only be run when a screen is first created. At the moment I usually have a context variable that tracks first visibility, but something like Self.VisibilityCount or Self.Initialised (set to true when onvisible completes the first time) maintained by canvas might be better?

#Navigating code- Jump to. Other editors allow you to jump to code. eg. If code contains Select(myControl) then say, highlight 'Select(myControl)' and hit F2 for the editor to open the formula editor at OnSelect() for myControl, and Shift+F2 to jump back to your original code.

I am sure I could go on 🙂

Thank you for your forbearance and Merry Xmas.

Regards

Peter

[PeterCBell_au]

On reflection, when it comes to improving Set/Context/local/global, perhaps a better framework would be;

• SetGlobal(x,...) which would be synonymous with Set(x,..) and sets property x of a record named 'Global' accessible globally
  • Global.  --> intellisense choose from the properties defined in the Global record.
  • UpdateGlobal({x:..., p:..., q:....}) allows shorthand update of multiple global properties
    • equivalent to multiple Set() statements and logically could also be written as Patch(Global,{....})
• SetContext(x,...) maintains property x of a local record named 'Context' unique to each screen and component
  • Context.  --> intellisense choose from the properties defined in the Context record applicable to the current screen/component.
  • UpdateContext({y:..., z:...}) allows shorthand update of multiple Context (local) record properties
    • equivalent to multiple SetContext() statements and logically could also be written as Patch(Context,{....})

The idea could of course be extended to Global.Codeblock.[blockname]  ,  Global.OnDemand.[ondemandformulaname] , Global.UDF.[UDFName(params)].  Similarly for Context.

Peter

[qwertyuiop]

Hi JorisdG,

Have been experimenting with the udf functionality and it looks great. Is there a plan to add Record and Table data type supports for UDF?

Thanks

[JorisdG]

Yes, there is. There is quite a bit of work to get there, unfortunately. The core issue is the lack of custom type definition. We have some basic support for this in the language today (see open source) but this needs to be expanded and exposed in Power Apps. Essentially, you need a way to e xpress what record or table type your UDF will return of accept as argument (and a way to define those types when they're not coming from a datasource). Adding that type definition support is what we are looking to bring, then enabling that in UDF is trivial. Note this would also bring new features to ParseJSON (cast directly to a custom-defined strong type).

Unfortunately, I don't have a clear picture on a timeline for this yet. We have someone ramping up on the work for type definitions that was done quite a while back, and we're also about to go through another planning round.

[rowza789]

Why is this new UDF functionality so novel? We have had this capability for years by building functions in components.

[JorisdG]

UDFs are a core part of the Power Fx language itself. Using components was a limited workaround specific to Canvas apps only.