George Lambert
b4150c8250
Compose-ready workspace: packages/zappier (rate card, portal, Stripe), packages/verae-zapier-middleware (timestamp + NATS), packages/verae-zapier (CLI app), vendor/zapier-platform, and research/zapier vendor corpus. Gate 0 structure checks pass. Product code and research are not yet wired.
79 lines
2.7 KiB
JavaScript
79 lines
2.7 KiB
JavaScript
const listRecipes = async (z, bundle) => {
|
|
// `z.console.log()` is similar to `console.log()`.
|
|
z.console.log('console says hello world!');
|
|
|
|
const params = {};
|
|
if (bundle.inputData.style) {
|
|
params.style = bundle.inputData.style;
|
|
}
|
|
|
|
// You can build requests and our client will helpfully inject all the variables
|
|
// you need to complete. You can also register middleware to control this.
|
|
const requestOptions = {
|
|
url: 'https://auth-json-server.zapier-staging.com/recipes',
|
|
params: params,
|
|
};
|
|
|
|
// z.request() returns an HTTP Response Object https://github.com/zapier/zapier-platform/tree/main/packages/cli#http-response-object
|
|
const response = await z.request(requestOptions);
|
|
|
|
return response.data;
|
|
};
|
|
|
|
// We recommend writing your triggers separate like this and rolling them
|
|
// into the App definition at the end.
|
|
module.exports = {
|
|
key: 'recipe',
|
|
|
|
// You'll want to provide some helpful display labels and descriptions
|
|
// for users. Zapier will put them into the UX.
|
|
noun: 'Recipe',
|
|
display: {
|
|
label: 'New Recipe',
|
|
description: 'Triggers when a new recipe is added.',
|
|
},
|
|
|
|
// `operation` is where the business logic goes.
|
|
operation: {
|
|
// `inputFields` can define the fields a user could provide,
|
|
// we'll pass them in as `bundle.inputData` later.
|
|
inputFields: [
|
|
{
|
|
key: 'style',
|
|
type: 'string',
|
|
helpText: 'Which styles of cuisine this should trigger on.',
|
|
},
|
|
],
|
|
|
|
perform: listRecipes,
|
|
|
|
// In cases where Zapier needs to show an example record to the user, but we are unable to get a live example
|
|
// from the API, Zapier will fallback to this hard-coded sample. It should reflect the data structure of
|
|
// returned records, and have obviously dummy values that we can show to any user.
|
|
sample: {
|
|
id: 1,
|
|
createdAt: 1472069465,
|
|
name: 'Best Spagetti Ever',
|
|
authorId: 1,
|
|
directions: '1. Boil Noodles\n2.Serve with sauce',
|
|
style: 'italian',
|
|
},
|
|
|
|
// If the resource can have fields that are custom on a per-user basis, define a function to fetch the custom
|
|
// field definitions. The result will be used to augment the sample.
|
|
// outputFields: [
|
|
// () => { return []; }
|
|
// ]
|
|
// For a more complete example of using dynamic fields see
|
|
// https://github.com/zapier/zapier-platform/tree/main/packages/cli#customdynamic-fields.
|
|
// Alternatively, a static field definition should be provided, to specify labels for the fields
|
|
outputFields: [
|
|
{ key: 'id', label: 'ID' },
|
|
{ key: 'createdAt', label: 'Created At' },
|
|
{ key: 'name', label: 'Name' },
|
|
{ key: 'directions', label: 'Directions' },
|
|
{ key: 'authorId', label: 'Author ID' },
|
|
{ key: 'style', label: 'Style' },
|
|
],
|
|
},
|
|
};
|