`UndefinedObject` incorrectly flagging image data-attributes

[ConduciveMammal]

Using the new image_tag filters, theme-check is flagging data-attributes as UndefinedObject.

{{ media | image_url: width: 900 | image_tag: sizes: '180, 360, 540, 720, 980, 1080, 1296, 1512, 1728, 2048', loading: 'lazy', preload: true, class: 'product-single__photo__img js-pswp-img', data-pswp-src: master_url, data-pswp-height: media.height, data-pswp-width: media.width, data-media-id: media.id }}

I thought they might need quoting, although the docs don't specify this, but they also render as expected on the frontend without quotes.

Quoting causes another issue: Expected end_of_string but found colon.

Working frontend example

Documentation sans data-attributes https://shopify.dev/api/liquid/filters/html-filters#additional-attributes

[charlespwd]

Hmm there must be a discrepancy between how we parse the arguments somewhere. Definitely a bug.

[charlespwd]

Some notes (to self or someone else):

• Shopify/liquid does indeed parse this thing kind of weird. Instead of parsing these as kwargs, they are parsed as VariableLookup arguments to the filter. Reason being the - character is not part of the \w regex that we use, so the expression is somehow parsed as a VariableLookup.

=> #<Liquid::Variable:0x0000000140358e28
 @filters=
  [["image_url", [], {"width"=>900}],
   ["image_tag",
    [#<Liquid::VariableLookup:0x0000000140379150 @command_flags=0, @lookups=["master_url"], @name="data-pswp-src">,
     #<Liquid::VariableLookup:0x000000014038aea0 @command_flags=0, @lookups=["media", "height"], @name="data-pswp-height">,
     #<Liquid::VariableLookup:0x00000001403905a8 @command_flags=0, @lookups=["media", "width"], @name="data-pswp-width">,
     #<Liquid::VariableLookup:0x00000001403900f8 @command_flags=0, @lookups=["media", "id"], @name="data-media-id">],
    {"sizes"=>"180, 360, 540, 720, 980, 1080, 1296, 1512, 1728, 2048", "loading"=>"lazy", "preload"=>true, "class"=>"product-single__photo__img js-pswp-img"}]],

• It looks like we're doing weird shenanigans after the fact and turning them back into key/values. But I didn't quite grok what the code does or where we're doing that. TagHelper.tag_option is the thing we call on the args and it magically undoes the weird parsing.

[charlespwd]

Wow. Really questioned my sanity with this one.

Turns out it's indeed a liquid bug! It works in production because of a difference between the liquid-c and the liquid implementation of how we parse filters. Liquid-C will parse tag arguments with dashes in them as tag names, whereas Liquid won't because of the \w regex.

I'm making a PR to liquid to fix this difference.

[ConduciveMammal]

Damn, that's crazy!

Perhaps a more JS/React style would be preferred? {% render 'snippet', dataPswpHeight: 15 %}

[charlespwd]

Nono, we handle them in liquid-c and I think that's a feature. I'll just fix liquid :D

[charlespwd]

(Blocked b/c waiting for a new release of liquid)