@stapes
Yep, understood and the red flags in your statement are "a load of global variables" and "loads of lookup data for dropdown boxes".
All of that should be in its respective controls. You should have limited variables in your app (this is even warned about in the docs):
Once you get rid of overused variables, your formula will get shorter and shorter.
Your Items properties on your dropdown boxes should have the formulas necessary to get their values.
PowerApps is not a development platform, so trying to "initialize" a bunch of variables like you do in a dev environment is not needed.
There are only a handful of things that need such a purpose in the OnStart.
I've written hundreds of app and very complex and complicated apps and the rule I first mentioned has become relevant from experience - if your formula spans more than a single scroll down, then it is too complex and needs to be refactored. Also from experience, once you stop using variables and collections for everything and embrace the concept behind PowerApps, your app will become much simpler to design and will work much better.
Examples:
ClearCollect(colMyDropdownItems, Filter(someData, someCriteria))
can become (demonstrating eliminating the app overhead of a collection):
Set(myDropdownItems, Filter(someData, someCriteria))
which can become:
<intentionally left blank>
Blank because, instead we just move this to the Items property of the dropdown:
Filter(someData, someCriteria)
AND, since I observe that factor of only writing a formula once, I might say to myself...hey, I need that set of results on another dropdown. No problem, this is where a dynamic app variable comes into play. And once you start putting in dynamic app variables (which are datacards in your app), then you have moved even more out of your app OnStart.
dataCardDropdownItems.Update property:
{
DropdownItems_1: Filter(someData, someCrtieria),
DropdownItems_2: Filter(someOtherData, someOtherCrtieria),
DropdownItems_3: Filter(someMoreData, someMoreCrtieria)
}
Then your Items property for a dropdown might be : dataCardDropdownItems.Update.DropdownItems_2
As another example...very common is this type of thing in an OnStart:
Set(varUserName, User().FullName);
Set(varUserEmail, User().Email);
Set(varUserManager, Office365Users.ManagerV2(User().Email).displayName);
Set(varUserManagerEmail, Office365Users.ManagerV2(User().Email).mail);
This can be refactored to:
Set(varUser, User());
Set(varUserManager, Office365Users.ManagerV2(User().Email));
And can be pulled out of the OnStart completely and be placed in a dynamic variable.
aDataCard.Update property:
With({_user:User()},
With({_o365Manager: Office365Users.ManagerV2(User().Email)},
{
User: _user,
UserName: _user.FullName,
UserEmail: _user.Email,
UserManager: _o365Manager,
UserManagerName: _o365Manager.displayName ,
UserManagerEmail: _o365Manager.mail
}
)
)
The possibilities are endless and very little is needed in the OnStart.
I don't know your specific scenario with your OnStart, but I could almost guarantee that I could chop it down using the above concepts.
But still...you asked about functions, and my response was that there is no such thing as a user function in PowerApps at this time, so, the things that I mention are ALL applicable to help reduce the size and complexity of formulas as you mentioned you had.
Anyway...I'm rambling. I have a video on this that is not yet published, but I wish it was done so you could see this in action as it drastically changes the way you do things in PowerApps to be more of "the PowerApps way".
And this post now is almost as long as your OnStart...Lol 😁
