Core Concepts
Techniques
Previews
A task uses its preview to demonstrate what actions the task intends to generate. Among other purposes (see below), this is also how tasks request the Shopify permissions they require.
Mechanic generates a task preview by rendering the task code using a preview event, which resembles a live event that the task may see. The task is then responsible for rendering preview actions in response to the preview event, actions which are visually presented to the user and are analyzed by the platform, but are never actually performed.
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.For live events, the
preview attribute does not exist. This means that event.preview == false is not a valid way to detect a live event. Instead, use event.preview != true, or event.preview == nil.Task code
1
{% if event.preview %}
2
{% log "This is a preview event, generated by Mechanic." %}
3
{% else %}
4
{% log "This is a live event, received by Shopify." %}
5
{% endif %}
6
7
{% if event.preview != true %}
8
{% log "This is a live event, received by Shopify." %}
9
{% else %}
10
{% log "This is a preview event, generated by Mechanic." %}
11
{% endif %}
Copied!
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.
Task code
Subscriptions
1
{% if event.preview %}
2
{% action "shopify" %}
3
mutation {
4
tagsAdd(id: "gid://shopify/Order/1234567890", tags: "web") {
5
userErrors { field, message }
6
}
7
}
8
{% endaction %}
9
{% elsif order.source_name == "web" %}
10
{% action "shopify" %}
11
mutation {
12
tagsAdd(id: {{ order.admin_graphql_api_id | json }}, tags: "web") {
13
userErrors { field, message }
14
}
15
}
16
{% endaction %}
17
{% endif %}
Copied!
1
shopify/orders/create
Copied!
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.)
Task code
Subscriptions
1
{% if event.preview %}
2
{% assign order = hash %}
3
{% assign order["source_name"] = "web" %}
4
{% assign order["admin_graphql_api_id"] = "gid://shopify/Order/1234567890" %}
5
{% endif %}
6
7
{% if order.source_name == "web" %}
8
{% action "shopify" %}
9
mutation {
10
tagsAdd(id: {{ order.admin_graphql_api_id | json }}, tags: "web") {
11
userErrors { field, message }
12
}
13
}
14
{% endaction %}
15
{% endif %}
Copied!
1
shopify/orders/create
Copied!
The stub data in this example includes an ID for the order in order to generate a realistic tagsAdd mutation during preview mode. Realistic preview actions are important for users and developers, but there's a functional importance for tagsAdd mutations in particular: in preview mode, Mechanic looks at the
id argument in order to determine what kind of resource will be tagged, in order to determine what permissions this particular mutation requires.Last modified 6mo ago