Request for suggestions: Add find, find_index, has, and reject filters to arrays

[karreiro]

Author: Shopify
Expected end date: December 5, 2024

Background

Handling arrays in Liquid is challenging.

Developers often need to iterate over arrays to find items or check for their presence. This pattern results in imperative code and verbose templates, which detract from the simplicity and declarative nature that Liquid aims to promote.

{%- liquid
  assign has_app_block = false

  for block in section.blocks
    if block.type == "@app"
      assign has_app_block = true
    endif
  endfor
-%}

{{ has_app_block }}

⏭️ Upcoming: In a different proposal, we'll tackle improvements to the where filter and its limitation of only filtering based on equality. That's so crucial, we aim to handle that separately.

Proposal

We should introduce new filters to make it easier to perform common tasks such as extracting or checking the presence of an item in an array. This will make Liquid templates simpler, less verbose, and more declarative.

All filters proposed here do not mutate the source object and return a new instance as a result of the operation:

1. find and find_index

The find and find_index filters return, respectively, the item and the index of the item with the specified property value; otherwise, they return nil.

Now	Proposal
{%- liquid assign index = 0 for section_block in section.blocks assign index = index | plus: 1 if block.id == section_block.id break endif endfor %}	{{ section.blocks | find: "id", block.id }} {{ section.blocks | find_index: "id", block.id }}

2. has

Returns true when the array includes an item with the specified property value; otherwise, returns false.

Now	Proposal
{%- liquid assign has_app_block = false for block in section.blocks if block.type == "@app" assign has_app_block = true endif endfor -%} {{ has_app_block }} Source	{{ section.blocks | has: "type", "@app" }}

3. reject

Works almost like the where filter, but returns an array excluding items with the specified property value.

Now	Proposal
{% assign property_value = false %} {% if something != this %} {% assign property_value = true %} {% endif %} {{ array | where: property_name, property_value }} Source	{{ section.blocks | reject: "type", "@app" }}

Call for suggestions

We welcome any feedback or opinions on this proposal. Please share your thoughts by December 5, 2024. Your input is valuable as we prepare to begin active development on this initiative.

[jg-rp]

👍

1. find and find_index

Would some_array | find: prop, value be equivalent to some_array | where: prop, value | first, although potentially more efficient?

Have you considered find_first, find_last, find_first_index and find_last_index, to be consistent with remove_first and replace_last etc.?

[dan-gamble]

Would adding the ability to work with nested keys be a trivial add? i.e.

{{ section.blocks | find: "settings.product.id", product.id }}

[galenking]

I feel like find and find_index make sense and I like @jg-rp’s suggestion for first and last. It would be important, I think, that these are case-insensitive as case-sensitivity causes so many problems with contains (that should be another change!).

IMHO, reject makes no sense. It’s not initially intuitive and would easily be achieved with a more robust where that supports true and false statements.

[efekurnaz]

These all are pretty useful! An addition to boolean support idea of @galenking, comparison filters would also be really useful.

{% assign collections_to_show = collections | where_compare: 'products_count', '>=',  0 %}

or

{% assign collections_to_show = collections | greater: 'products_count',  0 %}
{% assign collections_to_show = collections | greater_or_equal: 'products_count',  0 %}

or

{% assign collections_to_show = collections | where_gt: 'products_count',  0 %}
{% assign collections_to_show = collections | where_gte: 'products_count',  0 %}

[thatecommerceguy]

{{ section.blocks | exclude: "type", "@app" }}
exclude sounds more intuitive then reject

[andershagbard]

Pending PR for reject #1573

[jg-rp]

Upcoming: In a different proposal, we'll tackle improvements to the where filter and its limitation of only filtering based on equality.
That's so crucial, we aim to handle that separately.

Should where and reject/exclude be considered together? Depending on what you have in mind for where, it could influence reject syntax and semantics. Or even make it obsolete.