So it's LowCode, why would we need a code review.... It's probably what you have heard, lets just push these apps straight to prod. But that's a mistake, and let me tell you why.
What is a code review, well a general definition is:
A Process for someone who isn't the developer to review the process/app so that looking for potential bugs and that it meets Best Standard Practices
The question is why, the obvious one is spotting bugs, but to me that's not the main reason, the main reason is Best Standard Practices.
Best Standard Process aka BSP or SOP (Standard Operating Processes) are professional procedures that are accepted or prescribed as being correct or most effective.
These have 2 main benefits:
- Readability
- Optimization
Readability
Readability is what you expect, how easy it is to read your code, understand the app. Its particularly important for citizen developers, as they are often transient (career path maybe different from development) and documentation is often poor.
Power Apps are built with same approach as Excel, expression based language. This is great for the build for terrible for reviewing code. It reminds me of the CSS approach, separate CSS source files vs inline CSS. No surprise ProCode is pushing source files (VS Code flags inline CSS) while LowCode adds the code to the component/action.
Optimization
For optimization is often an afterthought for most, but particularly for citizen developers. A learn by doing approach does not focus on efficiency and optimization, add in there is often little incentive for LowCode platforms to be efficient (more Power Platform API calls / Dataverse storage is great for Microsoft).
Add in the higher chance for bugs (inexperience developers, poor ALM & short delivery times) then you can see the value of code reviews.
So what Best Standard Practices do I recommend to help code quality in Power Apps:
- Naming Conventions
- Code Formatting
- Consistency
- Optimization
- ALM (Application LifeCycle Management)
1. Naming Conventions
Naming Conventions are key to readability (remember code is read more often then it is written).
I've done a full blog on Power Apps Naming Conventions here, but there is no one way to do naming conventions, it just needs to be easy to remember, readable and consistent.
2. Code Formatting
This is another subjective one, with no right way, as long as its consistent and easy to read.
Personally I'm not a fan of the auto formatter in Power Apps, it splits code into new lines far to much, making it almost hard as no formatting to read.
No Formatting
Auto Formatting
As you can see, auto formatting splits at every bracket and comma. I prefer a middle ground, where simple expressions stay on one line, and more complex split out the key info.
3. Consistency
Consistency overlaps with naming conventions and code format, but extends to include functions and components.
Update, Collect and Patch have lots of overlap (See here), the developer should have consistency in which function they use e.g. When adding to a collection in one action using Collect, and another Patch)
Component wise I look for consistency with inputs, this is particularly around dropdown and combo boxes, and camera and add media. Each have their use cases, but there is a lot of overlap, so in an app it is expected to be consistent across same use cases.
The last thing to look at is half consistency, half bugs. And that's for consistency in traces and other app processes (e.g. resetting inactivity timers). Inconsistency will most likely manifest later as a bug so should be flagged.
4. Optimization
This could be a whole blog in itself, but there are a few key ones.
Cache to collection
All api calls getting data should be cached to a collection, then used by the components. Linking components like galleries data source to a external data source forces the app to download data every interaction, which is slow and inefficient.
App.Formulas
The new App.Formulas parameter (has to be turned on in experimental features) does what App.StartScreen did for dynamic start screens, but for setting variables.
vs
It looks small, but it allows Power Apps to split the app loading and show the start screen early (Microsoft shows up to 80% improvement in load time)
Named Formulas
Named formulas are used to split complex nested functions. As long as the variable/formula is declared on the App.Formulas parameter we can use the same syntax anywhere, allowing us to split out the nested function.
Named formulas are evaluated only when their values are needed, speeding up the app (and making it easier to read).
Create Reusable Function
As I mentioned, all code in Power Apps is stored inline with the component, so we can't reuse code, or can we. With the Select function we can create a nice workaround. The Select function can trigger a OnSelect action on another button component, so if we add our reusable code to a button, make the button invisible, we could then trigger the code anywhere with a Select.
Miss-use of ForAll
I often see ForAll used to update fields in a collection, a quicker approach can be to use the AddColumn function, as creating a new calculated field is quicker. I've also seen it used for Patching, when an UpdateIf or even the Patch function can do it one line of code and a lot quicker.
Show/DropColumns
When getting data its easy to just get everything, this not only includes all the fields you might not need, but also all the metadata (created by, created, url, etc, just checkout a SharePoint Collection). By using Show/DropColumns (as long as it doesn't impact your delegated filtering) can decrease the api response size, speeding up the response and your app.
5. ALM (Application LifeCycle Management)
It's easy to forget Apps don't need to be moved, hard coding links to data sources and key app configurations. Yet all good apps will need to be moved, they will require ALM, with constant updates and bug fixes mean you want different environments. The standard is Dev, Test and Prod. And if you have the same for yout data (which you should) then you will need to configure environment variables.
Environment variables enable you to set different config in environments without having to edit them. I will always check that data is set to environment variables, along with other things like timeouts (easy to check with shorter time span) and key settings.
As you can see, there are lots of benfits to enforcing code reivew on your Power Apps.
Further Reading
Top comments (1)
The enhanced component properties (still experimental) are a fantastic alternative for the approach presented in "Create Reusable Function", allowing for function, action and event properties.
I see this post is older than the announcement, so it's reasonable these props are not mentioned, but let's keep an eye on this topic =)