Theming: What’s the purpose of style templates other than default?

[vnys]

Hi 👋  I’m a frontend developer currently implementing my company’s design system in Power Apps. I’m aware of the brilliant work by @iAm_ManCat and Michael Wright based on using global variables, but I want to understand the thinking behind the Themes.json file, so I’m taking a slightly different approach by converting Themes.json to yaml using yq to be able to use anchors (variables) with design tokens before converting back to json. I’ve unpacked a CanvasApp with PASopa but looking at the styles field in Themes.json there are quite a lot of templates that seem superfluous. For example, for the button control there is “defaultButtonStyle”, “cancelButtonStyle”, “rezervedOkButtonStyle” and “rezervedCancelButtonStyle” – but are any of these in use somewhere apart from the “defaultButtonStyle”? I can’t find any references in the .msapp or anywhere in the portal where you can choose between them. Can I just delete them to reduce file size without any consequences? Does anybody know? 🤔

[iAm_ManCat · Accepted solution]

HI @vnys 

Yeah, I know 🙂

I was the first person to open up the canvas app and then find that you could use variables. At the time I was trying to set them all to text values so that I could do conditional logic if the text value was "xyz" then use ourBrand.ThemeColour1, and when I imported the file I found that it treated plaintext as variables), then I shared that to the community and spoke with the Power Apps team (who then created the CoE theming solution based on my concept), then some time after that Michael also used my concept to create his version of a theming template (and I hope that many more do!).

So to answer your question - yes, most of those additional styles are used, not in the insertion of new controls, but in the insertion of new screens - this was their solution for how to have buttons and styles of different types in the new screens without hard-coding it into the editor.

There are some you could probably remove as I couldn't find any reference to them even in the new screens, butt its a scant few.

So, in conclusion, if you intend to use the New Screen options or have your clients use them, then yes you will need those, otherwise no, you could remove those 😺

(PS: new version of the template is pretty close to complete)

Cheers,

Sancho

[vnys]

Thank you @iAm_ManCat, that’s very interesting – both the part about the screens and that the CoE theming solution was based on your idea. We have a lot of design tokens in our design system, so my concern is that it will be too heavy to have all of those as OnStart variables. And another thing is that to make the Power Apps controls look as much as possible like the React components without having to rely (too much) on code components, we would have to change the styles too, not just the palette. Then again all that work may be a waste of time when the Fluent UI controls become available in the portal 🤷

May I ask what the biggest change in the next version of your template is?

[iAm_ManCat]

The biggest change in the next version is that it has control-level overrides - so instead of just being able to edit the simple palette, you can define each specific property's default colour, i.e InputBorderColor, InputFill, InputHoverFill etc etc

To get around using too many variables, I set a parent styles variable with a table of values that include all of the other properties. This is akin to creating a stylesheet that can use the base theme's colours (or any random override of colours if needs be).

Having had a look at your design tokens, to replicate these I personally would (rather than set the defaults for standard buttons etc) create Power Apps canvas components for each style, and pass the table of theme colour values as an input to them. Or, as you say that might become redundant when Fluent UI is available in the portal..

Cheers,

Sancho

[vnys]

Control-level overrides is exactly what I'm trying to achieve with using yaml and anchors, that's very interesting! I don't suppose it would be possible to get a sneak peek just to learn how you've solved that and also give you some feedback if you're interested?

Creating canvas components in a library is definitely something I've considered, but there are a couple of things lacking in the maker experience department - like being able to define categories and icons to make it easier for the makers to find and use the components. If you make an app in Teams and export it in a solution and then import that into the makers portal you get a new menu item called "modern controls", it would be nice to be able to do something similar to that as well.

And OnReset seems a bit unpredictable if you have a component with a fill colour that's declared in a variable in the OnReset property. I've found if I have a custom "trigger" property with "Raise OnReset when value changes" ticked off I don't get the black background you normally get where the component is used, as long as the property type is Date, Screen, Image, Video or audio, Record, or Table. It needs a value, so {} for example for record or Now() for Date. And weirdly enough if I call the notify function in the OnReset property as well as defining the variables, that only gets called if I use the Screen Type, but the variables are still initialized with the other types as well. And I still need a hidden button that calls Reset(MyComponent) inside the component to initialize the variables while working on the component.

But I digress, I appreciate your work, I haven't really found a lot of people who focus on the design aspect of Power Apps so this is very inspiring 😊 

[vnys]

So if I understand you correctly, you first define a set of base styles – like the colour palette – and then you have a table with one record for every property of every control that refer to these styles? Doesn’t that result in a humongous table in the OnStart property? Or do you use a dataverse table similarly to the CoE Theming Solution?

[iAm_ManCat]

Yes unfortunately it results in a large table, but I keep it datasource-agnostic on purpose, so you can use it as a standalone and then if you wanted to you could store the data in Dataverse, Sharepoint, SQL etc and have it pull the table during OnVisible/OnStart 😺