MyField value : {{MyField}}
[object]
[object]
[object]
```
We are almost there, the above code is rendering an `[object]` because the Content Query web part offers 3 different ways to render a field value:
Property | Description
---------|---------------
`{{MyField.textValue}}` | Renders the text value of the field, a more readable end-user value to use for display.
`{{MyField.htmlValue}}` | Renders the HTML value of the field. For example, a *Link* field HTML value would render something like `My Link Field`
`{{MyField.rawValue}}` | Returns the raw value of the field. For example, a *Taxonomy* field raw value would return an object which contains the term `wssId` and its label
`{{MyField.jsonValue}}` | Returns a JSON object value of the field. For example, an *Image* field JSON value would return a JSON object which contains the `serverRelativeUrl` property
`{{MyField.personValue}}` | Returns an object value of a person field. The `personValue` property provides `email`, `displayName` and `image` properties. The `image` property contains `small`, `medium`, and `large` properties, each of which pointing to the profile image URL for the small, medium, and large profile images.
##### Handlebars
```handlebars
{{#each items}}
MyField text value : {{MyField.textValue}}
MyField html value : {{MyField.htmlValue}}
MyField raw value : {{MyField.rawValue}}
MyImageField JSON value : {{MyImageField.jsonValue}}
MyPersonField person value : {{MyPersonField.personValue}}
MyField text value : Simon-Pierre Plante
MyField html value : Simon-Pierre Plante
MyField raw value : 26
MyImageField JSON value: [Object]
MyPersonField person value: [Object]
```
### Including your own external scripts and/or block helpers
#### Including basic library files
For including JavaScript files within the web part, file URLs must be added to the **External Scripts** parameter available in the tool pane.
Each file URL must be on its own line, and placed in the desired order. The scripts will be loaded asynchronously, but in a sequential fashion, which means that the web part will wait until a script is completely loaded before proceeding to load the next one.
#### Including custom logic files
If you need custom logic files that can interact precisely **before** or **after** the rendering of the HTML generated by the *Handlebars* template, you must follow the pattern below in order for the web part to recognize the endpoints and call them when needed :
```javascript
ReactContentQuery.ExternalScripts.MyScriptFile = {
onPreRender: function(wpContext, handlebarsContext) {
// Do something before rendering (ie: adding a custom block helper)
},
onPostRender: function(wpContext, handlebarsContext) {
// Do something after rendering (ie: calling a plugin on the generated HTML)
}
}
```
Looking at this example, here are the key things that needs to be respected in order for the file to work :
#### Namespace
* The script uses a namespace which starts by `ReactContentQuery.ExternalScripts.`, followed by the name of its own file
* The name of the file has to be written without its `.js` extension, and without any characters that aren't letters or numbers
* The name of the file needs to respect the same casing as in it's URL
Examples :
##### MyScript.js
```javascript
ReactContentQuery.ExternalScripts.MyScript {
...
}
```
##### _My-Funky*named*Script_.js
```javascript
ReactContentQuery.ExternalScripts.MyFunkynamedScript {
...
}
```
#### Functions
* The script implements the `onPreRender` function for code that has to be executed before rendering
* The scripts implements the `onPostRender` function for code that has to be executed after rendering
Both functions provide the following parameters:
Parameter | Description
----------------------|-------------
`wpContext` | Represents the context of the web part that called the function, which exposes all kinds of useful information such as `wpContext.
`domElement` | Represents the HTML element on which the current web part is being rendered.
`handlebarsContext` | Represents the handlebars context used for generating the template of the current web part. Can be used for adding handlebar block helpers in the `onPreRender` function for example.
#### Including custom block helpers
Custom *block helpers* that can be used directly within the *Handlebars* template can be added simply by using a custom logic script file that implements the `onPreRender` function.
Example:
##### MyCustomBlockHelper.js
```javascript
ReactContentQuery.ExternalScripts.MyCustomBlockHelper = {
onPreRender: function(wpContext, handlebarsContext) {
// Adds the "testHelper"
handlebarsContext.registerHelper('testHelper', function(param, options) {
return "Output from testHelper : " + param;
});
}
}
```
### Using Microsoft Graph Toolkit
The Content Query Web Part provides support for [Microsoft Graph Toolkit](https://learn.microsoft.com/graph/toolkit/overview) (MGT) integration to easily query the [Microsoft Graph](https://learn.microsoft.com/graph/overview) within your handlebars templates.
You can use any of the MGT components without additional steps, although the MGT integration was designed specifically with [Person](https://learn.microsoft.com/graph/toolkit/components/person), [People](https://learn.microsoft.com/graph/toolkit/components/people), and [Person card](https://learn.microsoft.com/graph/toolkit/components/person-card) components.
#### Using MGT with a person field
If you have a SharePoint list containing a user field (like a **Created By** or **Modified By** field) or a person field, you can pass the `email` property from field's the `personValue` to the MGT component's `person-query` attribute.
For example, to use the `mgt-person` component with a person field called `MyPersonField`, you would use the following template:
```handlebars
{{ person.displayName }}
[[ person.displayName ]]