# User Defined: Functions & Types
So far, we've had named formulas, which are formulas that are given a name and can be used in other formulas. We've also had user-defined functions, which are functions that are defined by the user and can be used in other formulas. We're going to take a look at both of these, then present something else we can now create: user-defined types. User-defined types are structures we define in App.Formulas and can be used in many ways! By the end, you should be excited to add your own types to your canvas Power Apps!
## Table of Contents
- [[#App.Formulas|App.Formulas]]
- [[#Declarative Only Code (nothing imperative)|Declarative Only Code (nothing imperative)]]
- [[#Named Formulas|Named Formulas]]
- [[#User-Defined Functions|User-Defined Functions]]
- [[#User-Defined Types|User-Defined Types]]
## App.Formulas
If you haven't been using App.Formulas, this might all be new to you. Micrsoft gave us this property of the App object so that we can:
1. Move global code out of the OnStart property
2. Define constants without having to use global variables. These are called "named formulas" or "named expressions".
3. Create your own functions called "user-defined functions". Parameters can be passed in and a value can be returned.
4. As of now, create your own types called "user-defined types". With this, you can define your own data structure that can be used in your app.
Because of this, App.Formulas simplifies your code in your canvas Power Apps project and makes it even more maintainable.
## Declarative Only Code (nothing imperative)
App.Formulas may only contain declarative type of code, functions, and expressions and not imperative code. What's the difference? Declarative code is what you can put in almost any control property that **DOES NOT** start with "On". Imperative code is what you can put in the OnStart, OnSelect, OnChange, OnVisible etc. properties of a control or screen. Even Power Apps functions fall into these two categories. ColorValue is declarative, while Navigate is imperative, for example. If there is an *action* that you want to perform, you need to use imperative code. If you want to define a value, you can use declarative code.
**This point is vitally important** when you're about to adopt App.Formulas, you'll want to move much of the code in App.OnStart over to your App. The code you had in App.OnStart will not work in App.Formulas as it was. You'll need to refactor it to be declarative only or move it to a loading screen's OnVisible, or just keep imperative code in App.OnStart. We'll discuss this more below.
## Named Formulas
Here are some examples of named formulas, below. These are called "named expressions" because they are expressions that are given a name. They are used to define constants that can be used in other formulas. They are defined in the App.Formulas property of the App object.
The syntax (rules for a language) for named formulas is simple, as you can see here:
```PowerFx
YOUR-NAME = YOUR-FORMULA;
```
I'd recommend you start everything you define in App.Formulas with an fx prefix. This is a common convention to indicate that it is a named formula. This is not required, but it is a good practice to follow.
The name must be unique and must be a valid identifier. The formula can be any valid formula. The name and formula are separated by an equals sign. The formula is terminated by a semicolon. The name and formula are case-insensitive. The formula is evaluated when the app starts, or when it is needed, and the result is stored in a global variable with the same name as the named formula. The named formula can then be used in other formulas.
```PowerFx
fxLightGray = ColorValue("#e5e5e5");
fxDefaultBorderRadius = 20;
fxGetFirstName = First(Split(User().FullName, " " )).Value;
fxGetLastName = Last(Split(User().FullName, " " )).Value;
```
Collect and ClearCollect are very popular **imperative** functions. To use them in App.Formulas, you would simply name the formula and then return the data you'd like to be included.
```PowerFx
// Instead of this like you may have done in App.OnStart():
ClearCollect(colUsers, Filter(Users, IsActive = true));
// You would do this in App.Formulas:
fxActiveUsers = Filter(Users, IsActive = true);
```
## User-Defined Functions
This really has nothing to do with your users. You're the [developer] user. You're defining functions for yourself to use in your app. Before we can use user-defined functions, we need to turn the feature on in settings. This is true also for user-defined types, so you may as well turn both of them on if you're going to use them.
User-defined functions are a bit like named formulas, but you can define them to take parameters and return a value. This is very useful for reusing code. The syntax for user-defined functions is a bit more complex, but it is still very simple.
```PowerFx
YOUR-FUNCTION(
PARAMETER1-NAME: PARAMETER-TYPE,
PARAMETER2-NAME: PARAMETER-TYPE):RETURN-TYPE = YOUR-FORMULA;
```
Notice that the function name is followed by a set of parentheses. Inside the parentheses are the parameters that the function takes. If you don't want your function to take any parameters, you would express it with empty parameters ("()"). The Power Apps User() function is like this. If there are multiple parameters, they are separated by commas. Each parameter has a name and a type. The function is terminated by a semicolon. The function is evaluated when it is called, and the result is returned to the calling code (in a Button.OnSelect, for example, may call it).
Here are the types we've had access to so far:
- Void
- UntypedObject
- GUID
- DateTime
- Number
- Hyperlink
- Color
- Time
- Date
- Boolean
Here is an example of a user-defined function that takes a DateTime value and returns a Text value in a very particular format:
```PowerFx
fxMyDateFormat(DateTimeValue:DateTime):Text = Upper(
Text(
DateTimeValue, "dd -- mmm -- yyyy"
)
);
```
You can use this function in your app like this:
```YAML
- lblMyDateFormat:
Control: Label
Properties:
Text: =fxMyDateFormat(Now())
```
## User-Defined Types
Once you start using user-defined functions, you'll find that you want to pass in or return values from your function that doesn't fit into the other native types. This is where user-defined types come in. You can define a type that represents a complex object, and then use that type in your user-defined functions. This is very useful for when you have a complex object that you want to pass around in your app. For example, you might have a type that represents a person, and you want to pass that person around in your app. You can define that type like this:
```PowerFx
fxPerson := Type(
{
FirstName: Text,
LastName: Text,
DateOfBirth: Date
}
);
fxAddress := Type(
{
AddressLine1: Text,
AddressLine2: Text,
City: Text,
State: Text,
Zip: Text
}
);
```
These types can be used together, like legos!
```PowerFx
//
// We can have a property that uses another type, like Address
//
fxPerson := Type(
{
FirstName: Text,
LastName: Text,
DateOfBirth: Date,
Address: fxAddress // Here is a type defined within a type!
}
);
//
// Square brackets make a collection!
//
fxPeople := Type([fxPerson]);
```
As you use these user-defined types, you'll start to realize how much power and control they provide. You may want to create a user-defined function that fetches all the active Users, filtered by a particular state that you pass in. Then, at the same time, go do a LookUp for the related Address from the Address table.
```PowerFx
fxGetUsersFromState(FilterState:Text):fxPeople =
AddColumns(
ShowColumns(
Filter(
AppUser,
IsActive = true
And State = FilterState
),
FirstName,
LastName
),
Address,
LookUp(Address, UserID = ThisRecord.ID)
);
```
Once you start using these user-defined types, you will think of other types that would be useful to define in App.Formulas. Some of these types may be stored in a database table, but some may not be. Types that you may want to define that aren't stored in a database table might include:
- A navigational menu item.
- A color palette or styling theme.
- A special custom type that you might want to display in a dropdown or gallery.
As with the modern theming system, there are many colors defined. There is also a name and a font that is also in the definition.
Now, how could we define a type that represents a complete structure like that? Well, let's start with all the color types
```PowerFx
fxColors := Type(
{
Darker10:Color,
Darker20:Color,
Darker30:Color,
Darker40:Color,
Darker50:Color,
Darker60:Color,
Darker70:Color,
Lighter10:Color,
Lighter20:Color,
Lighter30:Color,
Lighter40:Color,
Lighter50:Color,
Lighter60:Color,
Lighter70:Color,
Lighter80:Color,
Primary:Color,
PrimaryForeground:Color
}
);
```
Now we can use this type in a super-set type called fxTheme:
```PowerFx
fxTheme := Type(
{
Colors:fxColors,
Font:Text,
Name:Text
}
);
```
# Conclusion
I hope you can begin to see how powerful user-defined types are. They allow you to define complex objects that can be passed around in your app. They also allow you to define functions that return complex objects. This is a very powerful feature that will allow you to build more complex apps and extend your apps like lego building blocks!
[Code on GitHub](https://github.com/PowerAppsDarren/PowerFxSnippets/blob/main/App.Formulas/user-defined-types.md)