Unified syntax for tag arguments [RFC]

[pushrax]

Tags are currently implemented as an arbitrary syntax defined in their #initialize or #parse method. Some of them use a combination of Liquid's regexes to do parsing, but not in a consistent way. This makes updating the language difficult – in particular, phasing out the lax parser.

Filters, on the other hand, are simply passed an array (positional arguments) and hash (keyword arguments), and have no say in how they were parsed. This decoupling is a huge advantage, allowing fixes and improvements to affect all filters without breaking them.

So, the idea is automatically parse tags in a certain format, for example:

arg = id colon expr | expr
tag = id (arg (comma arg)*)?

Then, the tag can access the resulting arguments (i.e. values returned from Expression.parse).

Since we do still want certain tags to have custom syntax, we can't 100% separate parsing from the tag definition. Some kind of way to extend the default will be necessary. However, since most tags don't need this (maybe none outside of the core tags?), it still allows most of the parsing logic to be decoupled.

Tags that need partially custom syntax could still take advantage of the argument parsing, e.g. the for tag:

for foo in bar reversed, limit: 4, offset: 5

Does this make sense? @Shopify/liquid @parkr

[nickpearson]

👍 This will make implementing and maintaining custom tags a lot easier, and will make it easier for new template developers. It would also make it easier for tag developers to keep things consistent and not have to deal with parsing arguments, leaving that to Liquid.

Regarding the need for core tags to have custom parsing, like the reversed keyword in the for loop you showed, what if HTML-style boolean/no-value keywords were supported? (Like nowrap in <b nowrap class="x">.)

Valueless keywords could be set to true. So in your example, the resulting arguments hash of the for tag would be:

{ "reversed" => true, "limit" => 4, "offset" => 5 }

I'm going off of memory here for the core tags, so sorry if this idea doesn't apply to some others.

[pushrax]

I think having the positional arguments be treated as expressions would be the more common case (like in filters). Then many tags like {% section 'foo' %} are trivial to implement, and also automatically work with variables or more complicated expressions.

[fw42]

seems reasonable to me

[parkr]

Hi, chiming in very late. I like this idea a lot. We do a lot of very weird parsing and have so far settled on key=value. If Liquid gave us the arguments as a Hash if they were key: value and still allowed us to transform raw arguments (that don't fit the key: value grammar) for backwards-compatibility, then I'd be super down. This would make our lives easier!

[asbjornu]

Having just implemented a few custom tags with argument syntax invented and implemented on the spot, this would be a very welcome change. Seeing how this issue is nearly 8 years old, however, doesn't make me optimistic about its fate. What is the current status?