Skip to main content

Hello, We're trying to add async await functions to our scripts.
I need help from developers.
Is it possible to add async await functions to legacy web builder script?
If not we tried to move our application from legacy web builder to zapier CLI and even if everything is remained same, we faced with an error. Is there a way to transfer existing app from web builder to CLI?

Great question. Technically yes, the code in the legacy scripting.js file is run from the same node executor as the “native” platform code, and async/await will work.

However all the libraries used when running that code are not promise aware. They’re synchronous. 

Further if you’re going to make major changes to your code I’d recommend starting to port your code out of the legacy scripting.js and into the current platform context.  

To do this, first move your project work to the CLI tool so you’ll have access to all code and configuration. Instructions are here. Sounds like you might have done this already. 

Once you’ve done that, you’ll find a javascript file for each trigger and action. The perform method will include a call to z.legacyScripting.run(). Comment this out and replace it using the current request library. If you had custom code in the legacy scripting.js you can use that as a staring point, noting a few differences in the environments. 

  • The current SDK generally, and the z.request library in particular returns promises. 
  • Libraries like lodash were available in the legacy scripting environment are not automatically included in the current platform. You can use npm to import them. Oftentimes you can replace functionality with an ES6 equivalent. JS has come a long way since the legacy Web Builder was introduced!
  • There are a few naming differences in bundle variables. 

An example of a create action before and after

 

Once that’s working, you can remove the associated entries from the legacy section in the index, and remove those functions from scripting.js to clean up. 

Unfortunately we can’t make this process automatic, and to modernize a converted legacy project requires a bit of effort. Not too difficult once you’re familiar with how the new SDK works, and there’s a ton of power and flexibility here once you’ve made that transition. We’re discussing tools to better scaffold up a version of your project without any legacy references to help folks looking to make a clean start. And we also should be introducing a more exhaustive guide or tutorial to detail this “de-web-builder-ization” procedure in the meantime. 


Hi @Zane ,
My client requested to stay in legacy web builder. Is there a way of promising a request, so we want to use, the data coming from the first request, at the second request.
Thanks for your help.
All Best,
Barış


@Barış Yıldırım  Would you mind DM-ing me your app id and which trigger or action you’re looking to add the behavior to? I’ll have a look and see what the best way is to do that and keep you in the UI tool.  

My client requested to stay in legacy web builder

The legacy web builder is turned off, so the project is already running on the current platform in the new UI. It’s just that for projects that were converted from the legacy tool we “shimmed” the code so that we could run it from within the new environment.  I’m interpreting this as your client wishing to keep their work in the UI rather than moving to the CLI tool. Just wanted to clarify that for others that read this.