What Not to Do in Power Apps

There are lots of cool blogs telling you tips on how to build good Power Apps, so I thought I would take a different approach and talk about what you shouldn't be doing. Couple of call outs:

• This is based on a ALM app (Dev, Test, Prod) not Default app
• Its an opinion, so feel free to disagree
• I've also done a Power Automate one here

So with that all said, lets dive in to my top 7:

1. Use The Default Text Formatter
2. Duplicate Your Code
3. Use Groups
4. Always Use Containers
5. Multiple Variables
6. Hard Code Values
7. Use Booleans for Multiple Visible Components

1. Use The Default Text Formatter

We all want nice easy to read code, and tools in vs code like Prettier are excellent. But Microsoft must have a different idea of what pretty is, as the formatter in Power Apps is awful. It just puts every comma on a new line.

Just look at RGB:

Having everything on a new line does not make the code easy to read. There is a sweet spot where you want new lines for different parts of the expression.

So a Set() would be on a new line, an If() would also be one line if it was just returning a value, but if it had expressions inside then it should be 3 (condition, true expression, false expression)

ClearCollect(colTest,
    {
        name:"David",
        Title:"Engineer",
        Area:"Power Automate"
    }
)
//
Set(vbTest,false);
//
If(vbTest,
    Filter(colTest,Name="David")
,
    AddColumns(colTest,
        Status,"active"
    ,
        PowerPlatform,Area="PowerAutomate" Or Area="PowerAutomate"
    )
)

2. Duplicate Your Code

I see this far to often, you want run a block of code in multiple places. So the code is copied to multiple 'OnSelect' actions. Every time you update that code you have to update it multiple times.

What you should be doing is using the Select function.

The select function will trigger the 'OnSelect' code on any component on that screen. So simply add a button with all of your code, set the buttons visibility to false and then trigger the code in any location by typing

Select(hiddenButtonName);

Now you have just one location to update the code.

3. Use Groups

In my opinion groups only exist because containers didn't at the time. The only advantage I can see (I'm sure there are more but anyway) is that it is one less component on screens that may have too many components.

The reasons to use containers instead are:

• Positioning is relative, so you can position components inside it and others consistently
• Components have their own valid parameters like Height and Width, so you can use its position to set other components.
• Adding more components to containers is a lot easier
• Moving Groups is finicky compared to moving containers

4. Always Use Containers

While on the subject of containers, don't use them by default. I see far to often them used for creating menus and title bars. There is no reason to use containers for positioning components in areas of the screen. It Adds unnecessary components (slows down screen) and nesting, which makes it harder to read.

Containers should only be used for positioning when you want a responsive app. So if you want your app to work on desktop, tablet, mobile, then yes definitely use them. But if you plan to just use it on a laptop, don't. Position components by simple X,Y or relative (X is another components X + 20)

5. Multiple Variables

Variables impact the load and performance of your app (very marginally I admit), so we should not be over using them. Like wise from a readability side having loads of variables can make understanding the app significantly harder. So if you have groups of variables, don't set them individually, use an object variable.

A object variable is simply a record/row. So it can have multiple values saved in one variable.

Set(vsName,"David");
Set(vsTitle,"Engineer");
Set(vaNvsAreaame,"Power Automate");

vs

Set(voUser,
    {
        Name:"David",
        Title:"Engineer",
        Area:"Power Automate"
    }
)

6. Hard Code Values

I see this all of the time, Outlook connectors in apps emailing a hardcoded email address or a reference block of text simple text within a label.

We all use environment variables for SharePoint/Dataverse data connections, so why are we not using it for environment variables and other values.

The obvious reason is accessing environment variables in apps is not a simple as in flows, and it requires a premium license. But that doesn't mean we should not set them as an "environment variable".

There are 2 simple alternatives if you want a non-premium environment variable.

Use a flow, that's right if flows do it well and for non-premium, call a flow and get the variable that way 😎

Second if you want non-premium then you know where to go.... SharePoint. That's right create a config/variable list that you store you variables in. The simply get them through a lookup.

7. Booleans for Multiple Visible Components

The default approach to showing a component like a popup is to set the visible parameter to a Boolean variable, and then change that on a Set() variable.

But lets say you have multiple popups on a screen, and you only ever want one showing. You would not only set one variable to true, but also have to set all the other popup variables to false. This is a obviously a pain to develop, and even worst if you add new popups (as you will have to add the new variable to every other action that shows the popup).

So here's how to do it right, use one string variable and change that to the popup name to show it.

Thank you @george_t for this tip

There are plenty more, but I will save them for later/comments 😎