Access the list of render errors

[bbugh]

Hi! 👋 This seems like a great library.

We're using liquid-ruby for our customers to be able to customize some of their templates. We want to use liquidjs to do client-side previews and error parsing, so we can give the customers fast feedback while avoiding a round-trip to our server's precious resources.

In Ruby liquid, when rendering a template, an array of the errors is available afterwards, which can be used to display to the client. I've looked through the docs/repo, and liquidjs seems to behave very differently from liquid-ruby in this way.

Ruby example:

options = options = { strict_variables: true, strict_filters: true }
template = Liquid::Template.parse(markup)
result = template.render(context, options)

# Lots of errors to look at here
template.errors.each do |error|
  puts error
end

With the same markup and options as the Ruby version, liquidjs throws one error and quits.

const engine = new Liquid()
const template = engine.parse(markup)

// This throws a single error
const result = engine.renderSync(template, {}, { strictFilters: true, strictVariables: true })

I'm surprised this doesn't exist yet, but I'm guessing liquidjs is used more for server templates?

Is this possible to do with liquidjs or are we out of luck? Thanks!

[harttle]

Both of the parse and render process are sequential, which means previous errors imply the following templates can be parsed/rendered incorrectly. In other words, only the first error can be guaranteed to be correct so it's thrown directly in the current implementation.

It requires an error recovery mechanism to allow detecting all errors without termination. There's no such plan currently but I'll keep this issue open to see how many people are looking for it.

[bbugh]

Thank you for the reply! If I understand what you're saying correctly, that's also how I understand liquid-ruby to work: the parse errors (like malformed tags) are fatal and you only get , while render errors are not fatal, and are collected in an array you can access after. I incorrectly added "parse errors" to the title, which I fixed now, sorry for the confusion.

The list of errors we're looking for are the render-specific ones, where an object or function are missing for example. Presently liquidjs handles this by outputting nothing (just like liquid-ruby) but it looks like there's no way to access these "output nothing" errors, and that's what we're looking for.

Given this:

{{ bad_object }}
{{ another_bad_object }}

liquid-ruby would have an error array, like this psuedo-example:

[
  "Liquid error (line 1): undefined variable 'bad_object'", 
  "Liquid error (line 2): undefined variable 'another_bad_object'"
]

Does that clear it up? Is this presently possible and/or plausible?

[harttle]

Missing variables and filters will render to empty by default, you'll need to set strictFilters and strictVariables options to catch these errors.

Again, it's not a list and will throw upon the first error. LiquidJS does not distinguish fatal or non-fatal errors for now.

[bbugh]

Great, thank you for confirming my assumptions. If we decide to move forward with the client-side approach, I will see about a PR. It looks like handling errors happens in renderTemplates. It seems like that could return an object instead of a string, like { result: string, errors: LiquidError[] }. So as not to break the end-user API, the render function could still return a string, but keep the errors in engine. Does that seem plausible or am I way off?

[harttle]

An additional method or a catchAllErrors defaults false or failFast defaults true argument will be better, or this feature will be a breaking change.

[georgemanius]

Hello, @harttle ! We've also encountered the need to have all the missing parameters within the template returned and logged. Do you still have a plan for implementing this by any chance? Or maybe there's an existing API to retrieve all the variables within the template?

[harttle]

Yes, the list of errors is planned. Thank you for calling out this again so we have better understanding of what’s most needed.

For list of variables please go #707