-
-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setting globals dynamically after opts argument removed from renderFile() #432
Comments
My problem is to find a way to modify The Thanks for your help! |
# [9.29.0](v9.28.6...v9.29.0) (2021-12-11) ### Features * customize globals & strictVariables when calling render, see [#432](#432) ([6801552](6801552))
Hey @PlanetIrata, I think it makes sense to provide render specific options when calling const globals = {} // the globals you need to set for this render call
engine.render(<file>, {}, {globals}) Feel free to post back if there's more problems on this, or that doesn't work for you. Please see this doc for details: https://liquidjs.com/api/classes/liquid_.liquid.html#renderFile |
This is fortuitous because I was looking to do something like this as well. It seems to work for me. Thanks! |
just an FYI. The reason we need this is each customer has different global settings. Currently, we create one engine object per customer which seems wasteful. Being able to pass in customer-specific globals into the render function will allow us to not have to create a liquid engine for each customer! |
Hi @harttle Seems to work perfectly with 9.29.0 Thanks! |
Hi
I juste upgraded my app from LiquidJS 9.25.1 to the latest 9.28.6
I am facing bugs and just find that the
opts
parameter ofrenderFile
has been removed in version 9.26.0 :My app was using this parameter to pass a customized
globals
setting to the rendered file (depending on the file, this is why I don't set theglobals
setting while creating the engine).Is there another way to do this without re-creating an engine before each call to
renderFile
?P.S. as stated in #395 this should have been flagged as a breaking change in 9.26.0
The text was updated successfully, but these errors were encountered: