YAML in Power Apps (part 2): Refactoring Power Apps Canvas App Control Names


This post explores a simple application I’ve developed to streamline control name refactoring within Power Apps Canvas Apps code that save a bunch of time renaming duplicated controls in Power Apps Studio


🤦‍♂️ Lots of Controls to rename‍

Recently I got into a project were a “legacy” Canvas Power Apps. I appropriated the term here, but just to point out that the maturity of development of the app was low and don’t used any least good practices. No kidding, in some cases we got a control replicated n times, just like this:

Reproduction of replicated control

This turned into a huge problem in our refactoring/modernization task, even to discover the current APP.

So, as I was already excited about YAML serialization possibilities I notice that at this point a cool use of it will be awesome! ✍️(◔◡◔)

🍲 Implementation

Refactoring Goals and Logic:

The primary objective is to modify control names ending in the suffix “_2,_5,_100….” (e.g., Icon5_2). The script aims to achieve this by adhering to the following naming convention:

Standard desirable after Refactoring

The control type prefix, I’m following Matthew Devaney2024 Power Apps Coding Standards For Canvas Apps

  • {control type prefix}: This is derived from the control_prefixes dictionary (coding Standards).
  • {context/purpose}: Extracted from the control’s Text or Tooltip property (priority given to Text).
  • {container/group}: Determined by the control’s indentation level within the code.
  • {screen}: Retrieved from the first line of the YAML file (screen where the control is).

Example:

Understanding the Code Structure:

The script relies on a YAML file that defines the Power Apps Canvas App code schema. Additionally, I’ve established a dictionary named control_prefixes that maps control types (e.g., button) to their corresponding prefixes (e.g., btn).

Key Script Steps:

  1. Line Reading and Control Information Extraction:
  • The script reads each line of the YAML code.
  • It extracts the screen name and constructs the control hierarchy based on indentation levels.
  • It identifies controls with names ending that are eligible for refactoring (_2, _5,…_100…)
  • Control type (e.g., label) is determined.

1.1 Context/Purpose Derivation:

  • The script prioritizes extracting context from the Text property.
  • If Text is unavailable, it attempts to use the Tooltip property

2. Refactoring and Renaming:

  • If the control name qualifies for refactoring, a new name is constructed using the defined format.
  • Both the original and new names are stored.

3. Reference Update:

  • The script iterates through the code again, searching for references to the renamed controls (using the original names).
  • These references are updated to reflect the new control names.

👨‍💻The Code





🤓 Usage

For now, the usage is for mid-level users:

1. The user must follow the unpack/pack process mentioned in last article to be able to unpack the msapp (through CLI canvas pack/unpack) and copy the screen YAML file from Src directory

2. In application directory, paste the copied YAML file and run the script:

Refactor directory of the containing the executable file

As output, we get refactored_{filename}.yaml. Now just copy this into Src directory of unpacked APP, exclude the “old” file and rename the refactored file

3. Pack the APP with PAC canvas pack

4. I really don’t know if there is another way to do this, but to open the msapp in my environment (without importing as a zip) is opening any APP in Power Apps Studio and open the refactored msapp:

Import file msapp file

🚑 Bumps in the road

Now, i need to put some testimonials here about the process of developing this application.

As a concept I intended that the application to be user friendly, with a user interface, etc.…
So, I’ve used Cursor AI code editor to transcript the code to C# and wrap it in a bigger solution with Windows Forms with every beauty charming UI, but got stuck trying to wrap the pack/unpack process into solution.

I got even more excited knowing some amazing tools in Power Apps Tooling repo, one these tools just seem to fit perfectly into my problem, that is the Legacy Source File Pack and Unpack Utility (PASopa). I ended up ruining everything and decided to keep it simple for me and my team usage

🏁 Conclusion

Well, after all, I solved this huge problem that i have and maybe in the near future we can improve it to refactor some other cases. 
For now, a container of a group is suggested for the naming and if there is absolutely no context the renaming still serves it proposes giving the minimal refactored name possible (the control type and screen name at the end). Even using LLM’s sometimes is impossible to get some context of the Control (trust me, I tried)

🐞Known Bugs:
– Screen Names with a space add a ‘ to the refactored controls, and this breaks when trying to pack to .msapp

jean.dosher@gmail.com Avatar

Leave a Reply

Your email address will not be published. Required fields are marked *