Power Platform Snippets
As with any kind of development or scripting, I’ve always liked to keep a collection of little snippets that I might reuse again sometime. I like the challenge of puzzling my way through some development…the first time. But it’s much less fun to reinvent the wheel, especially for simple problems.
Often this has been some kind of OneNote, or text file, that I would share with others on my team. It’s a great approach that adds minimal overhead to the process.
As an early adopter of many Power Platform tools, I’ve found myself sharing these snippets a lot more broadly. OneNote and text files aren’t particularly good for that. I decided to use GitHub because:
- It’s a good intended fit for sample code and related documentation
- I could make the repository Public by default
- It includes a way to get ideas and updates from others (more on that later)
- It offered an excuse to apply some of my GitHub and Markdown skills
I landed on a simple structure
My goal was to keep the repository as simple and approachable as a OneNote file, and I think I’ve succeeded for the most part.
- A set of files written in Markdown, one file aligning to the key technology (Power Fx, Power Apps, Power Automate, etc.)
- Within each file, I add the snippets, each with a title, description, and code
- A folder for Solutions (packaged/deployable samples)
The list contents have grown over time. The Power Fx snippets mostly started out on the Power Apps file. As Power Fx has grown as a language, beyond the walls of its canvas apps origin, I decided to segment that out with its own dedicated file. I expect the pendulum will swing on this as there are more tool-specific snippets.
E.g. I expect that there will be some tool-agnostic PowerFx samples, like manipulating text strings and setting variables, but also some tool-specific things like Screen properties which wouldn’t apply to
Looking for contributors
I’ve always envisioned this repository as being better with more contributors. I only run into so many things (and document a subset of those).
Open an Issue - This has the lowest barrier to entry. Just use the Issues tab on the GitHub repository and include the details for your submission. Anyone will be able to see the submission in the issues list.
Submit a Pull Request - If you’re familiar with Git workflow (or are looking for a low-barrier way to get your feet wet), you can create a Pull Request on GitHub. Effectively, you propose the updates by editing a copy of the repository, then request these to be merged.