A task uses its preview to communicate what actions the task can be expected to generate. Mechanic generates a preview by rendering the task code with a preview event, which resembles live events that the task may see. The task is responsible for rendering preview actions in response to the preview event, actions which are visually presented to the user, but are never run.

During a preview, access to the Shopify API is disabled. In most cases, this means that the task must detect and react to preview events intentionally, using stub data in place of live event data or Shopify API data, in order to generate the appropriate preview actions.

Purposes

A preview has three critical purposes:

1. Showing the user that the task will do what they expect it to do

2. Showing the task developer that the task code is functioning as intended

3. Showing the Mechanic platform what permissions the task requires

For users

Core to the design of Mechanic is the idea that we can make it easy to make it easy – in this case, making it easy for developers to show their users what a Mechanic task can be expected to do.

By rendering preview actions, a task can prove to the user that it is interpreting their configuration as they intended. For example, by rendering a preview Email action, a task can show the user that their configured email content is appearing as expected inside the email body. This increases trust in the task, and allows users confidence in the task's outcome, even before the task processes a live event.

For developers

Developers may think of previews as a sort of test, using preview actions to prove that their task code is functioning as intended. A quality task will exercise all of its code in response to a preview event; doing so gives the developer instant feedback on task results, without actually having to run the task with a live event.

For Mechanic

At the platform level, Mechanic uses previews to determine what permissions a task requires.

Mechanic gets this information from the actions that a task generates during preview, as well as from analysis of the Liquid lookups and GraphQL queries that a task uses during runtime.

For example, if a task renders a Shopify action containing a customerCreate mutation, Mechanic will prompt the user to grant access to the write_customers Shopify OAuth scope. If Mechanic observes a task using shop.customers, or observes the shopify filter receiving a customer-related GraphQL query, it will prompt for the read_customers scope.

Detecting preview events

A preview event is identical to a live event in all respects but one: it contains a preview attribute, set to true, identifying it as a preview event.

{% if event.preview %}
  {% log "This is a preview event, generated by Mechanic." %}
{% else %}
  {% log "This is a live event, received by Shopify." %}
{% endif %}
​
{% if event.preview != true %}
  {% log "This is a live event, received by Shopify." %}
{% else %}
  {% log "This is a preview event, generated by Mechanic." %}
{% endif %}

A preview event's data is taken from the Mechanic account's event history, providing a realistic sample of the data a task can expect to see. (If the account history has no events for a given topic just yet, Mechanic will attempt to use anonymous sample event data of its own.)

Rendering preview actions

A developer can choose between rendering static and dynamic preview actions. Static preview actions are hard-coded, written to appear whenever event.preview is true. Dynamic preview actions are the result of the task code running normally, using event data in preview in the same way that it would use that event data with a live event. Because dynamic preview actions are the result of meaningfully exercising the task's code, they can provide a good indicator of how the task will behave with a live event. By contrast, static preview actions do not provide useful feedback on how a task is coded.

Static preview actions

A static preview action is rendered in direct response to event.preview. In general, it's better to use dynamic preview actions, but an understanding of both techniques is useful.

In the following example, a static preview action demonstrates that the task intends to tag incoming orders with "web". In actuality, the task's intent is to only tag orders that arrive via the Online Store channel; because the task can't be sure whether or not the preview event will contain such an order, a static preview action is used to ensure that a preview event always results in a tagging action.

Branching a task like this has two problems:

1. The actual condition of the task is not exercised during preview. The task will need to be tested with live orders from multiple channels, in order to verify that the task works properly.

2. Duplicating code makes it easier for one copy of the code to fall out of date. By using completely different code for the preview and live actions, it becomes easier for developers to forget to keep the two copies in sync as the task evolves.

{% if event.preview %}
  {% action "shopify" %}
    mutation {
      tagsAdd(id: "gid://shopify/Order/1234567890", tags: "web") {
        userErrors { field, message }
      }
    }
  {% endaction %}
{% elsif order.source_name == "web" %}
  {% action "shopify" %}
    mutation {
      tagsAdd(id: {{ order.admin_graphql_api_id | json }}, tags: "web") {
        userErrors { field, message }
      }
    }
  {% endaction %}
{% endif %}

shopify/orders/create

Dynamic preview actions

A dynamic preview action is the natural result of exercising a task's code as completely as possible.

In the following example, the task code uses event.preview to construct a brand new order variable, one that is guaranteed to resemble an order from the Online Store sales channel. This synthetic variable is an example of stub data.

This technique has several advantages:

1. Constructing stub data allows the rest of the task to proceed without any special knowledge of the preview event.

2. The preview actions generated are an excellent indicator of how the task will behave when given a live event.

3. The developer is able to test their code instantly, by changing the values of the stub data. (In the example below, they can prove that the condition on line 7 works by experimenting with the order's source name on line 3.)

{% if event.preview %}
  {% assign order = hash %}
  {% assign order["source_name"] = "web" %}
  {% assign order["admin_graphql_api_id"] = "gid://shopify/Order/1234567890" %}
{% endif %}
​
{% if order.source_name == "web" %}
  {% action "shopify" %}
    mutation {
      tagsAdd(id: {{ order.admin_graphql_api_id | json }}, tags: "web") {
        userErrors { field, message }
      }
    }
  {% endaction %}
{% endif %}

shopify/orders/create