As apart of the Microsoft Ignite event today, it was announced that the next chapter for low-code development over the next 24 months will position Power FX as the standard language for Power Platform. Thus streamlining the platform to utilize a single syntax for Canvas application-based development. Standardizing the “code” language of Power Platform not only allows for individuals to transition from Excel gurus to Power Platform developers easily, reducing the burden initially when diving into its applications and providing a quicker ROI for organizations. The inclusion of Power FX into the Power Platform will not replace M or DAX languages but will serve as a complementary tool where each will have a place in the architecture. As Microsoft stated in their announcement, “M and DAX focus on reading, shaping, joining, and summarizing large amounts of data while Power Fx focuses on reading and writing smaller sets of relational data.”
The table below provides some insights into the existing Power Fx’s functions, with a number of them having almost identical syntax to that of the existing Excel formula.
The benefits provided by Microsoft have been broken down below:
- All data operations in Power Fx are asynchronous. The maker doesn’t need to specify this, nor does the maker need to synchronize after the call is over. Most importantly, the maker doesn’t need to be aware of this concept at all. They don’t need to know what a promise or lambda function is.
- Local and remote. Power Fx uses the same syntax and functions for local in-memory and remote data in a database or service. The user need not think about this distinction. Power Fx automatically delegates what it can to the server to process filters and sorts there more efficiently.
- Relational data. Orders and Customers are two different tables, related through a many-to-one relationship. The OData query requires an “$expand” with knowledge of the foreign key, similar to a Join in SQL. The formula has none of this. In fact database, keys are another concept the maker doesn’t need to know about. The maker can use simple dot notation to access the entire graph of relationships from a record.
- Retrieve only what is needed. In this example, the LookUp function implies that only one record should be retrieved, and that is all the is brought back. If more records are requested by using the Filter function, for which thousands of records may qualify, only a single page of data is brought back at a time, on the order of a hundred records. The user must gesture through a gallery or data table to see the additional data, and it is automatically brought in for them. The maker can reason about large data sets without needing to think about limiting data requests to reasonable chunks.
- Runs only when it is needed. We defined the formula for the Text property of the label control. As the variable Selected changes, the LookUp is automatically recalculated and the label updated. The maker did not need to write an OnChange handler for Selection, remembering that this label depends on it.
- Excel syntax translation. Excel is used by hundreds of millions of users, most of which know that “&” is used for string concatenation.
Reference Material:
