Introduce z.dehydrateFile #112
Conversation
There was a problem hiding this comment.
Tested this locally on my machine, both with a function and a simple URL. Confirmed that we no longer hydrate too eagerly during Zap setup, that the default hydrator works, the function version works, and the caching let the editor keep using the same S3 URL.
Big wins!
| } | ||
| }).should.throw( | ||
| 'We could not find your function/array/object anywhere on your App definition.' | ||
| ); |
There was a problem hiding this comment.
Nice improvement on these tests!
| }); | ||
| }; | ||
|
|
||
| const dehydrateFileFromFunc = (func, inputData) => { |
There was a problem hiding this comment.
The fromRequest and fromFunc threw me off a bit on first read cause it made me go "wait, we should be hydrating from a request or a func." I see now that it's communicating "dehydrate, with request as hydration options" or "dehydrate, with func as hydration options", but that doesn't make a very good method name. Unfortunately don't have anything better, so happy to roll with this for now.
Adds
z.dehydrateFileto CLI. Requires https://github.com/zapier/zapier/pull/19954.z.dehydrateFilehas two function signatures:z.dehydrateFile(func, inputData): Nothing different fromz.dehydrate(func, inputData)except that we're annotating the payload with an "it's for a file" tag. So the backend knows not to hydrate it too early in Zap editor.z.dehydrateFile(url, request, meta): We'll runhydrators.zapierDefaultFileHydrator, which is injected at runtime as part of the app initialization.zapierDefaultFileHydratorprovides the default implementation for the most common use cases. It downloads the file from the trigger-side app and uploads it to S3 withz.stashFile.