[ 𝗣𝗿𝗼𝗽𝗼𝘀𝗮𝗹 ] Multiline filters & parameters in liquid blocks

Online Store and Theme Development
1

Related GitHub issue : Multiline Filters · Issue #1703 · Shopify/liquid · GitHub

Filters & parameters should be usable in
multiline scenarios in liquid blocks the
same as they do in standalone statements.


Multiline Filters

Standalone ( Works )

{%- assign value =  'this-is-a-test'
    | split : '-'
    | uniq
    | sort_natural
    | join : ' '
-%}

Liquid block ( Doesn’t Work )

{%- liquid

    assign value = 'this-is-a-test'
        | split : '-'
        | uniq
        | sort_natural
        | join : ' '

-%}

Multiline Parameters

Standalone ( Works )

{%- render 'Snippet'
    , a : a
    , b : b
    , c : c
-%}

Liquid block ( Doesn’t Work )

{%- liquid

    render 'Snippet'
        , a : a
        , b : b
        , c : c

-%}


Btw I think the liquid tag description in the welcome post is wrong
( liquid: Use this tag for questions and discussions specifically about migrating from REST to GraphQL. )
( Welcome to the Online Store and Theme Development Board! )

3 Likes
2

This would improve the readability a lot.
Add the ability to use filters and tags when sending parameters and boom, much less assigns and readability.

{%- liquid
    # ...
      render 'image', 
      imageClass: 'object-cover ' | append: section.settings.height 
-%}
3 Likes
3

I am also +1 for this, but I think this confuses a little bit, :roll_eyes:
For example, in this case, append filter would be applied on imageClass or the result of render?

{%- liquid
    # ...
      render 'image', 
      imageClass: 'object-cover ' | append: section.settings.height 
-%}
1 Like
4

Indeed, a delimiter would be needed in here and it’ll probably introduce more headaches. I see Liquid is getting more attention by Shopify lately, so why not? The main concern would be rendering performance I guess as it can get out of control easily.

{%- liquid
    # ...
    render 'wrapper', 
    content: { 
      render 'image' with imageClass: { 'object-cover ' | append: section.settings.height },
      render 'text' with textAlign: 'left' and content: { section.blocks | where: 'type', 'text' | map: 'settings.text' }
    }
-%}
2 Likes
5

Yep, That’s a good idea @efe. I would +1 that.
Let’s see what’s the narrative on this from Shopify. :face_with_hand_over_mouth:

1 Like
6

@efe Interesting , I’d suggest opening a dedicated topic for that ,
after all it’s a standalone proposal that is only indirectly affected by this one.

I want to focus this proposal solely on the multiline support itself~

Btw personally I think assignments are fine & a great way of
recontextualizing processed information via it’s new variable name.

7

@panoply maybe this can be done via syncify + vscode-liquid?

The data is transformed to the shopify required format during build.
I’m not the biggest fan of this code pattern, I think it leaves room for errors, but if it were to be done I think vscode-liquid + syncify is the right setup for it

8

While I understand the drive for something like this, it opens the door to inconsistencies. Introducing punctuation syntactics like commas, for chained associations outside of arguments/parameter contexts, or singleton braces to achieve scope like isolation are a bit hectic imo and only solving nuances encountered within Liquid blocks tags….

Line breaks within Liquid blocks is something I’d like to see as long the structures stay within grammar bounds and are token bound (i.e, filters and/or tag arguments, parameters and keyword conditional operators).

I suppose most of this will be improved and less obtrusive once they iron out ternary expressions.

In terms of making something like that possible in my tools, I mean… I guess if devs like that type of style. However, I’d rather just expose beautification workarounds like word wrap exceptions or similar via Æsthetic.

9

Adding additional build tools is not an option for
most people , this should be out of the box behavior.

Being bound to another vendor doesn’t make life easier.

10

I assume you are solely talking about efe’s comment in the first paragraph?

11

Correct.

Your proposal is what makes the most sense imo.

1 Like
12

Yes I shouldn’t have complicate the topic. Mine is not a thoroughly thought proposal anyway, was just brainstorming.

1 Like