Add parameter to not throw error when can't parse string

[RomanKuzo]

trafficstars

Hey

I'm using this package to interpolate string and insert some data into it.

Example:

I have a string like this: "Hi, this is {{user.first_name}} {{user.last_name}}". And the object of values:

const defaultValues = {
  user: {
    email: '{{user.email}}',
    first_name: '{{user.first_name}}',
    fullname: '{{user.fullname}}',
    last_name: '{{user.last_name}}',
    phone: '{{user.phone}}',
};

It works as expected when everything is okay. But when there is a mistake in a variable it throws me an error (it's also good). My request is to add an option to skip variables in case of a parsing error and just return this string.

Example:

If I have a string like this: "Hi, this is {{user.first_name} {{user.last_name}}" it should return me a string like this: "Hi, this is {{user.first_name} Kuzo".

Please, let me know if it's possible.

Thanks

Roman Kuzo

[harttle]

Hi @RomanKuzo ,

There's multiple errors LiquidJS can throw, apart from unmatched {{. Like unmatched {%, invalid filter syntax, etc. Not sure if skipping this one error works for you.

A general advice would be try parse and render, then fallback to a default string, in case of template not trusted.

[mohas]

I generally advice against this as it will introduce unnoticed mistakes and headaches. if you have data entry process and fear that users might not be advanced enough to enter correct format you can run the template through a sample data and show the result and also prevent user from saving until successful compilation

[BornAgainCoder7]

Hi there. I am a new contributor. I am more than willing to work on this issue (#751): "Add parameter to not throw error when can’t parse string."

Proposed Approach: Add a new engine option, example: ignoreParsingErrors: boolean. If ignoreParsingErrors is true, parsing errors (unmatched tags) will be ignored and return a fallback string instead of throwing. Maintain default behavior (throw error) when the option is not set. Add test coverage for both scenarios. Update documentation to include the new option and how it is used. If you could let me know if this approach works, that would be cool. Thanks.