Futures

For the most part, it doesn't matter if Mechanic's tasks are somewhat delayed sometimes. However, when building tasks that directly interact with the shop's storefront, it becomes much more important that the task run as soon as possible, if not immediately. Taking into account good practices of letting the customer know that they need to wait for the task to complete, it would also be helpful if there was a way to prioritize tasks like this. Tasks with prioritization would be pushed to the top of the task queue (after any other prioritized tasks), allowing less time-sensitive tasks to run afterwards. The level of granularity to this prioritization is up to debate, but it should probably be kept simple so as not to get confusing or hard to manage.

A way to group my shop's tasks in order to more easily view them.

Google's APIs require OAuth, which isn't really a feasible thing for the "http" action. Let's figure out how to do this properly.

Character limit (min/max) Format or Masking Radio buttons Labels or Placeholder text Select box (dropdown)

Having access to performance data on our tasks would help us to optimize our tasks, especially when a) writing tasks for the task library, and b) writing storefront-interactive tasks that need quick response times. Data I can see being useful: Shopify API Usage - Is my task eating up my API rate limit? Could it be optimized by using GraphQL instead of REST/external liquid objects? Mechanic Usage How long is my task taking to complete? Is my logic placing a heavy performance burden on Mechanic? Should I try to simplify that 5-layers-deep nested for-loop?

Usability would be greatly improved if the browser titlebar changed as the user navigated within the Mechanic app. This can be accomplished through the use of the TitleBar action in Mechanic's frontend code. Having the titlebar update to identify which page the user is on is especially important in the cases of a) having multiple tabs open, and b) identifying pages in ones browser history.

Having task options field types that exposed object pickers (product, variant, etc.) would be a nice feature for merchant configuration of tasks.

Shopify (currently) only allows for a single bulk op to be running per app, per store. Would be great if Mechanic could automatically handle a few retries.

Currently, to use a webhook in a task, the process is to: Leave the task to create a webhook Copy the webhook url and webhook topic to your clipboard (if you have multiple clipboard item support), or copy to a text document for reference. Return to your task and paste the two options into the task. It would be great if there was a task option which created a populated dropdown list of existing webhooks in the store. This would be especially useful in reducing the friction of setting up library tasks which require webhooks. (PS - Even better would be if the webhook could be created right from the task creation page, but that's an additional enhancement I'll leave for later)

Currently, formatting a phone number into a human readable format takes quite a bit of work. You have to strip out any non-digit characters, and then split the remaining digits into individual characters and output them one by one. It’s also prone to errors, as you can only support one phone number format this way. The e164 filter is useful for getting the phone number into a standard machine-readable format, but it’s not great for user-facing tasks like invoice generation. Implementing something like number_to_phone in Rails would make this kind of user-friendly formatting far easier.