Data Variables
Data Variables enable the definition and use of a value throughout the page.
Last updated
Was this helpful?
Data Variables enable the definition and use of a value throughout the page.
Last updated
Was this helpful?
Data Variables are defined on any instance in the navigator such as Global Root, Body, or Heading. Variables can be found on the right panel in the settings tab.
Variables are available within the instance they are defined on and any of its children. They are not available in the parent.
If you define a variable on the Global Root, it will be available on all pages and can be used within Slots.
System variable is a unique variable in that it exists by default, while all other variables are added by the user.
System variable contains the following:
Params – Key/value pairs that are defined in Dynamic Page URLs.
Search – Key/value pairs of query parameters that may exist in the URL.
Origin – The URL of the current site. It will display whatever the actual URL is, so in the builder, it will be the internal wstd.io domain, but on the published site, it will be the current origin, likely a custom domain.
A String variable holds text data, which can be used for content like titles, descriptions, and labels.
A Number variable stores numeric values, including integers and decimals. It's useful for calculations, counters, and any numeric data that components might need to display or use in logic.
A Boolean variable represents a true or false value. It is ideal for toggling states, such as visibility.
A JSON variable allows for structured data in JSON format. It is ideal for creating simple data structures used with Collections to iterate over each item, such as creating a dynamic gallery.
A Resource variable gets its value from a fetch request, allowing data from a remote system to be used within Webstudio. For example, Resource can be used to interact with a REST API. While it can also be used to interact with a GraphQL API, it’s recommended to use the GraphQL Resource instead.
The are several fields available to configure the fetch request.
URL – Where the resource is located.
Method – A request method. Refer to the third-party API docs to find the suitable method.
Headers – Key/value pairs such Content-Type application/json. Refer to Request Headers for more info.
Once the Resource fetches data, you'll use the Expression Editor to bind data from the response to your website. See Binding for more information.
You may be wondering whether every visit to your blog results in an API call to your CMS or if the content is cached in Webstudio.
When you configure a Resource, the data is fetched using Cloudflare Workers, which has a built-in caching system.
Several factors determine what gets cached and for how long, but one of the primary factors is what the origin system instructs the requesting entity to cache. In other words, the headless CMS tells Cloudflare Workers what can be cached, if anything, and for how long.
Webstudio sees approximately 45% of sub-requests (i.e., fetches from Cloudflare Workers) served from the cache. This means that, on average, roughly half of the time someone visits a page that uses Resources, such as a blog post, the request will go through to the origin/CMS.
A GraphQL Resource variable gets its value from a GraphQL API, allowing data from a remote system to be used within Webstudio. While similar to Resource, it’s unique in that the available fields are specifically designed for interacting with GraphQL APIs.
The are several fields available to configure the fetch request.
URL – Where the resource is located.
Query – A GraphQL query.
Variables – A JavaScript object containing variables that will be passed into the request. This is commonly used to pass in parameters in a URL within a Dynamic Page. For example { slug: system.params.slug } See System Variable for more info.
A System Resource variable gets its value from internal data.
For example, there is a Sitemap inside the System Resource. It contains the data about the static pages on the website, which is commonly used to build a custom sitemap that combines dynamic data with static data. Refer to the XML Node component for more info.
The requests, including any sensitive secrets like API keys, are handled on the backend and are never exposed to the client.
The requests, including any sensitive secrets like API keys, are handled on the backend and are never exposed to the client.