Tutorial 6 - Variables

adding variables to your query allows you to filter results based on user interaction and re use queries dynamically introduction so far, we've set up queries which return the same set of results each time variables allow you to make queries which can be re used in different situations can search, sort, filter and change page based on user interaction can show information which a particular user has permission to access there are three main steps to setting up variables in a query define the variables replace hard coded values in the query with variables pass in values for the variables there is no set order in which to follow these steps, as you'll need to follow all three before the query works as expected our example in this article, we'll use the following query as an example query find items with category { records( per page 2000, filter { deleted at {exists false} properties \[ { name "category array", value in "98486" } ] } ) { results { id properties } } } as you might have guessed, this query aims to find webapp or module items with a particular category assigned to them as it stands, the query is not very useful or repeatable we want to be able to pass in the category we're interested in as a variable this would allow different pages to use the same query to view different categories or allow the user to choose which category they wish to view using variables inside the query normally in programming you would define the variables before you use them the benefit of adding the variable where you'll use it first is that the error message will tell you information about which type of data the variable will need to be in our example query, we'll remove the hardcoded category id and replace it with the name of our new variable $category code query find items with category { records( per page 2000, filter { deleted at {exists false} properties \[ { name "category array", value in $category } ] } ) { results { id properties } } } notes all variables inside the query itself must be preceded with a dollar $ sign this query will currently fail, because we still need to define the variable explorer sorry, explorer does not currently support arrays or variables, so no demo is available this time defining variables next, we'll define the variables we will use these definitions will be entered as arguments on the top level of the query each variable you define has two parts a name e g $category a data type e g string here's what just the top level looks like with the newly added argument query find items with category($category string) { } here's the whole query query find items with category($category string) { records( per page 2000, filter { deleted at {exists false} properties \[ { name "category array", value in $category } ] } ) { results { id properties } } } notes the variable name is again preceded with a dollar sign $ a colon and an title case keyword are used to set the type see below for more information on types we've deliberately made a mistake with the type of the variable we'll discuss this below explorer sorry, explorer does not currently support arrays or variables, so no demo is available this time using the correct type a variable's type is really important and an error will be thrown if you use the wrong one for example, running our query now gives the following error { "errors" \[ { "message" "list dimension mismatch on variable $category and argument value in (string / \[string!])", we can use the error message to find the type we need in this case it's \[string!] not string this indicates that an array of strings is expected, which makes sense because "value in" is for filtering array fields you can also check in the documentation panel we'll fix this in our query query find items with category($category \[string!]) { records( per page 2000, filter { deleted at {exists false} properties \[ { name "category array", value in $category } ] } ) { results { id properties } } } what's important is the type of data that a particular graphql property expects as its value, not the type of data you were intending to pass in in fact, you may have to modify the type of your variable with liquid beforehand, so that it is acceptable to graphql mandatory variable types an exclamation mark after a type e g string! means that this variable will be mandatory the query will not run without it this is useful when that variable is used to control sensitive information terminating the query if you can't be sure which data you need to return however, it's important to make sure ordinary user behaviour can't cause this to happen, because the error message can be bad for ux array variable types square brackets around a value, indicate that it should be an array (which may have any length) e g \[string] examples of using liquid to modify data types if you require any other conversions, please request them on intercom and we'll try and include them in the list string to int apply an integer filter {% assign original string = "123" %} {% assign new int = original string | plus 0 %} string to float {% assign original string = "123" %} {% assign new float = original string | plus 0 00 %} string to \[string] {% assign original string = "123,456" %} {% assign new array = original string | split "," %} string to boolean {% assign original string = "true" %} {% if original string == "true" %} {% assign new boolean == true %} {% elsif original string == "false" %} {% assign new boolean == false %} {% endif %} boolean to string {% assign original boolean = true %} {% assign new string = original boolean | downcase %} int to string {% assign original int = 123 %} {% assign new string = original int | downcase %} float to string {% assign original float = 123 %} {% assign new string = original float | downcase %} literal json object to hash object (needed for advanced variables only like passing an array of properties objects into a filter) you can also use the parse json tag to create any of the above types; if you can write the variable in a type that's supported by json, the tag will convert that to a variable in the hash format that can be passed into graph as a variable value {% parse json properties object %} \[ { "name" "properties webapp field 1 1", exists true }, { "name" "properties webapp field 1 2", exists true } ] {% endparse json %} passing in variables using the sandbox (testing) you can test by entering values in json format in the panel in the bottom left the panel may be hidden, in which case you'll need to click and drag it up firstly, open a new json object next, define the key of your property { "category" } and finally, define the value of your category make sure the data is in the type you defined earlier here are some examples string `"hello"` int 3 float 3 2 boolean true \[string] (array of strings) \["hello", "hi"] in our example, we will need an array of strings { "category" \[ "98486" ] } notes this time, you won't need to use a dollar sign $ that's because this panel represents the input and is not part of the graphql query it doesn't use graphql syntax, instead it uses json syntax our query is now finished explorer sorry, explorer does not currently support arrays or variables, so no demo is available this time passing in variables using liquid okay, so now you can use the graphiql sandbox to test your queries with variables, but the really useful bit is to be able to use liquid to pass variables in this will unlock the ability to fetch data dynamically with graphql step 1) add parameters to the graphql tag for each variable you've defined in the query here, we'll continue with our example and add category {% graphql my results = "find items with category", category %} notes we will add the value of the category variable in the next step you don't need to use a dollar sign $ before the name of your variable you can add new lines to the inside of the tag to keep it tidy, or write the tag on one line, it's up to you step 2) next, add the value of the parameter you can either hardcode the value {% graphql my results = "find items with category", category "98486" %} or, you can use a liquid variable which you defined earlier {% assign current category array = "" | split "," %} {% assign current category array = current category array | add to array "98486" | add to array "98487" %} {% graphql my results = "find items with category", category current category array %} or, you can use data from siteglide that's already stored in a liquid variable in this case, let's say we're in an item liquid file for a product we already have access to the categories that this product is assigned to luckily, the data is already a liquid array let's use that data to find other records in the same category {% graphql my results = "find items with category", category this category array %} challenge using page as a variable challenge objective for this week's challenge, we'd like you to set up your own simple pagination controls this will combine everything you've learned so far as usual, don't worry if you need to check the answers before completing it on a new page you create, the user should be able to see the first two items in the gallery webapp then, when they press the page 2 button, the page should refresh and they should see the second page of results see the gif above for a demonstration in the tips section, we'll give you the html and liquid you need to get started, your challenge is to build the graphql query which will power the functionality tips here are some snippets of code you can use to help you user interaction you can use anchors to allow the user to refresh the page and change the page parameter in the url 1 2 3 reading url parameters you can use liquid to read the page parameter in the url you'll then need to work out how to feed this variable into your graphql query {% assign page = context params page | default 1 | plus 0 %} by the way we're using the filters | default and | plus 0 to make sure the page defaults to 1 if no parameter exists, and that the data is converted to an integer remembering pagination in graphql you may need to refer to tutorial 2 , to refresh your understanding of pagination next time we'll look over the answers to our toughest challenge yet let's go!