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. To provide tasks with relevant sample data during preview, developers can define preview events (to construct relevant scenarios at the event level) or use stub data (to swap in predefined values for
event, or for the results of Shopify API data).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
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.
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.
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.Some GraphQL mutations have multiple potential scope requirements, like tagsAdd or metafieldsSet. Because the requirements of these mutations hinge on their arguments, make sure that your preview actions are rendered with realistic ID strings (e.g.
id: "gid://shopify/Product/12345"). Mechanic will look for these IDs to determine what scopes to request.Previews are generated using synthetic, temporary, non-persisted events – at least one for each event topic that the task subscribes to. These events are sourced from one of three places, in order of priority:
- 1.If the task defines its own preview event for a given topic, the preview will use the defined event;
- 2.Or, if the Mechanic account has a recent event with a matching topic on file, the preview will use data from that event;
- 3.Or, if the event topic is standard and known to Mechanic (i.e. not a part of the User domain), the preview will use illustrative example event data defined by the Mechanic platform.
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
{% 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.)
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.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
{% 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
A dynamic preview action is the natural result of exercising a task's code as completely as possible, without adding any business logic that responds to
event.preview. Put another way, the idea is to make the preview (that appears during task editing) look as similar to a live event as possible.Example
{% if some_evaluated_condition %}
{% action "shopify" %}
mutation {
tagsAdd(id: {{ order.admin_graphql_api_id | json }}, tags: "web") {
userErrors { field, message }
}
}
{% endaction %}
{% endif %}
There are two techniques available for "steering" the task towards desired outcomes during preview.
- 1.Use defined preview events to control preview event data, without ever having to add preview-related code to the task itself. This is the cleanest way to control data provided by the event during preview.
- 2.Use stub data to dynamically swap in preview-friendly values. This is generally not necessary for preview event data, but may be necessary when querying Shopify for data during a task: because the Shopify API is disabled during preview, using stub data can be useful for swapping in realistic values that would be returned during a live run.
Last modified 13d ago