Referência de variável líquida

Liquid é uma linguagem de modelo que pode ser usada no Looker para criar conteúdo mais dinâmico. Por exemplo, você pode criar URLs para ferramentas externas com base nos resultados de uma consulta ou alterar a tabela do banco de dados que é consultada com base na seleção de um usuário.

As instruções líquidas são criadas a partir de variáveis, filtros e tags. As variáveis contêm as informações que você quer usar, e as variáveis fornecidas pelo Looker estão descritas nesta página. Você pode modificar ainda mais esses valores usando filtros e tags, sobre os quais pode ler neste Guia de líquidos.

Há vários lugares em LookML que você pode usar o Liquid:

• O parâmetro action
• O parâmetro description de um campo (mas não de uma exploração)
• O parâmetro html
• Parâmetros de rótulos no nível do campo, incluindo label, view_label, group_label e group_item_label
• O parâmetro link
• Parâmetros que começam com sql (como sql e sql_on)
• O parâmetro de filtro do painel default_value
• O parâmetro do elemento do painel filters

Como usar variáveis Liquid

O uso básico de variáveis Liquid é simples. Depois de identificar a variável que deseja usar (consulte a lista a seguir), basta inseri-la em um parâmetro LookML válido. As variáveis Liquid específicas que você pode usar em parâmetros LookML específicos são definidas a seguir.

Dois tipos de uso líquido

Há duas maneiras de usar uma variável Liquid:

1. Sintaxe de saída: esse tipo de uso pode inserir texto e é provavelmente a maneira mais comum de usar o Liquid no Looker. Neste método, coloque a variável Liquid em duas chaves. Por exemplo: {{ value }}
2. Sintaxe da tag: esse tipo de uso geralmente não insere texto. Em vez disso, ele serve para comparações lógicas e outras operações de líquidos. Neste método, coloque a variável Liquid em uma chave e em um único sinal de porcentagem. Por exemplo: {% dynamic if value > 10000 %}

Exemplos básicos

Neste exemplo de uso de HTML, um ID de produto está sendo inserido em uma tag <img> para gerar imagens do produto:

dimension: product_image {
  sql: ${product_id} ;;
  html: <img src="https://www.altostrat.com/product_images/{{ value }}.jpg" /> ;;
}

Neste exemplo de uso de URL, um nome de artista está sendo inserido em um URL para produzir uma pesquisa do Google sobre esse artista.

dimension: artist_name {
  sql: ${TABLE}.artist_name ;;
  link: {
    label: "Google"
    url: "https://www.google.com/search?q={{ value }}"
    icon_url: "https://google.com/favicon.ico"
  }
}

Neste exemplo de uso do SQL, a tabela do banco de dados está sendo determinada de acordo com os campos que o usuário escolhe. A sintaxe usa uma estrutura if, em caso contrário (se indicado como elsif), else para verificar e reagir aos campos incluídos na consulta.

sql_table_name:
  {% dynamic if event.created_date._in_query %}
    event_by_day
  {% elsif event.created_week._in_query %}
    event_by_week
  {% dynamic else %}
    event
  {% dynamic endif %} ;;

Neste exemplo de uso de rótulo, a dimensão email muda o valor label, dependendo do nome do modelo LookML. Isso mudará dinamicamente o nome do campo no seletor de campo e em qualquer resultado de consulta que inclua a dimensão email:

dimension: email {
  label: "{% dynamic if _model._name == 'thelook' %} Looker Registered Email Address {% dynamic else %} External Email Address {% dynamic endif %}"
  type: string
  sql: ${TABLE}.email ;;
}

Para ver mais exemplos de uso, consulte a página individual do parâmetro LookML em que você tem interesse.

Como acessar variáveis a partir de outros campos

As variáveis líquidas geralmente se baseiam no campo em que estão sendo usadas. No entanto, você também pode acessar valores de outros campos, se necessário.

Use o formato {{ view_name.field_name._liquid-variable-name }} para acessar outros campos da mesma linha no resultado da consulta. Substitua _liquid-variable-name por qualquer uma das variáveis Liquid do Looker. O nome da variável precisa ser precedido por um sublinhado se não for normal, desta forma:

• {{ view_name.field_name._value }}
• {{ view_name.field_name._rendered_value }}
• {{ view_name.field_name._model._name }}

Este exemplo mostra esse tipo de uso para acessar o URL de um site em um campo diferente:

dimension: linked_name {
  sql: ${name} ;;
  html: <a href="{{ website.url._value }}" target="_blank">{{ value }}</a> ;;
}

Quando você faz referência a outro campo com a sintaxe de variável {{ field_name._value }}, o campo referenciado é adicionado à cláusula SELECT da consulta SQL e como uma coluna adicional na cláusula GROUP BY. Isso é necessário para recuperar corretamente os valores no campo referenciado. No entanto, isso pode causar resultados inesperados em medidas agregadas. Para mais informações, consulte a seção sobre como usar variáveis líquidas em medidas agregadas nesta página.

Definições de variáveis líquidas

A tabela a seguir descreve as variáveis Liquid que podem ser usadas com o LookML. A coluna Uso indica com quais parâmetros LookML cada variável Liquid pode ser usada e inclui as seguintes opções:

A = funciona com o parâmetro action.

DV = funciona com o parâmetro default_value (para painéis).

DE = funciona com o parâmetro description no nível do campo, mas não funciona com description no nível de exploração.

F = funciona com o parâmetro filters (para elementos do painel).

H = funciona com o parâmetro html.

LA = Funciona com os parâmetros de rótulo no nível do campo, incluindo os parâmetros label, view_label, group_label e group_item_label, mas não funciona com parâmetros de rótulo no nível de modelo, Explorar, visualização ou referência, ou com label como um subparâmetro de link.

LI = funciona com o parâmetro link.

S = Funciona com todos os parâmetros LookML que começam com sql (por exemplo, sql, sql_on e sql_table_name).

Variável	Definição	Uso	Exemplo de saída
Valores de campo
value	O valor bruto do campo retornado pela consulta do banco de dados. Pode se referir ao valor de um campo dinâmico. Além dos parâmetros mostrados na coluna Uso, value é compatível com o subparâmetro label dos parâmetros action e link.	A H LI	8521935
rendered_value	O valor do campo com a formatação padrão do Looker. Você pode consultar a sintaxe de formatação de datas em rendered_value, como mostrado na página Formatação de data fácil com as práticas recomendadas de líquido. Além dos parâmetros mostrados na coluna Uso, rendered_value é compatível com o subparâmetro label dos parâmetros action e link.	A H LI	US$ 8.521.935,00
filterable_value	O valor do campo formatado para uso como filtro em um URL do Looker. Por exemplo, ao filtrar um valor de string que inclui uma vírgula como "Altostrat, Inc", a variável value retorna duas strings diferentes, "Altostrat" e "Inc". A variável filterable_value corrige isso escapando dos caracteres especiais e retornando uma única string, neste exemplo, "Altostrat, Inc".	A H LI	8521935
Links
link	O URL para o link de detalhamento padrão do Looker. Observe que alguns campos não terão nenhum link padrão.	A H LI S	/explore/thelook/orders?fields=orders.order_amount&limit=500
linked_value	O valor do campo com formatação e vinculação padrão do Looker. As medidas não têm vinculação padrão. Por isso, elas exigem a configuração do parâmetro drill_fields para funcionar com linked_value.	A H LI	US$8.521.935,00
Filtros
_filters['view_name.field_name']	Os filtros de usuário aplicados ao campo solicitado com view_name.field_name. _filters['view_name.field_name'] também é compatível com o parâmetro sql de uma tabela derivada, mas não é compatível com outros parâmetros sql. O uso de _filters['view_name.field_name'] em um parâmetro sql da tabela derivada requer o filtro sql_quote líquido.	A DE H LA LI	NÃO NULOS
{% date_start date_filter_name %}	A data de início em um filtro de data que você solicitar com date_filter_name. Consulte a seção Uso de date_start e date_end para mais informações.	S	2017-01-01
{% date_end date_filter_name %}	A data de término de um filtro de data que você solicitar com date_filter_name. Consulte a seção Uso de date_start e date_end para mais informações.	S	2017-01-01
{% condition filter_name %} sql_or_lookml_reference {% endcondition %}	O valor do filtro solicitado com filter_name aplicado ao sql_or_lookml_reference como SQL. Essa variável é usada com filtros modelo e mesclagens condicionais.	S	Para ver exemplos, consulte a página de documentação dos Filtros com modelo e a seção Junções condicionais da página sql_on.
{% parameter parameter_name %}	O valor do filtro de parâmetro que você pede com parameter_name.	DE LA S	Consulte a página de documentação do parâmetro parameter para ver exemplos.
parameter_name._parameter_value	Injeta o valor do filtro de parâmetro que você solicitou com parameter_name em uma instrução lógica.	DE H LA LI S	Consulte a página de documentação do parâmetro parameter para ver detalhes e exemplos importantes.
Atributos do usuário
_user_attributes['name_of_attribute']	O valor do atributo do usuário que você pede com name_of_attribute, para o usuário específico que está executando a consulta, se os atributos do usuário estiverem sendo usados. A variável _user_attributes['name_of_attribute'] também pode ser usada na sintaxe do filtro avançado.	A DE H LA LI S DV F	nordeste (se, por exemplo, o atributo do usuário for "região") Consulte a página Como usar atributos do usuário para esquema dinâmico e injeção de nome de tabela para ver mais exemplos.
_localization['localization_key']	Retorna o valor associado a uma chave de localização definida no arquivo de strings de um modelo, com base na localidade de um usuário.	DV F	Consulte a página de documentação Como localizar seu modelo do LookML para ver um exemplo.
Objetos LookML
_model._name	O nome do modelo para este campo.	A DE H LA LI S	a aparência
_view._name	O nome da visualização deste campo.	A DE H LA LI S	pedidos
_explore._name	O nome da exploração para esse campo.	A DE H LA LI S	pedido_itens
_explore._dashboard_url	ADDED 22.12 O URL relativo do painel atual.	H LI S	/dashboards/5
_field._name	O nome do próprio campo, no formato view_name.field_name.	A DE H LA LI S	pedidos.total_order_amount
Consultas
_query._query_timezone	O fuso horário em que a consulta foi executada.	A DE H LA LI S	America/Los_Angeles
view_name._in_query	Retorna true se algum campo da visualização estiver incluído na consulta.	DE LA LI S	verdadeiro
view_name.field_name._in_query	Retorna true se o campo solicitado com view_name.field_name aparecer na tabela de dados de consulta, estiver incluído em um filtro para uma consulta ou estiver incluído em uma consulta por meio do parâmetro required_fields.	DE LA LI S	verdadeiro
view_name.field_name._is_selected	Retorna true se o campo solicitado com view_name.field_name aparece na tabela de dados de consulta.	DE LA LI S	verdadeiro
view_name.field_name._is_filtered	Retorna true se o campo solicitado com view_name.field_name estiver incluído em um filtro para a consulta.	DE LA LI S	verdadeiro

Uso de date_start e date_end

As variáveis Liquid date_start e date_end são muito úteis para dialetos de banco de dados que particionam dados em várias tabelas por data, como o BigQuery. Use a sintaxe de tag {% date_start date_filter_name %} ou {% date_end date_filter_name %}. Não é possível usar a sintaxe de saída {{ date_start date_filter_name }} ou {{ date_end date_filter_name }}, mesmo que essa sintaxe normalmente seja usada para gerar texto.

Por exemplo, é possível criar esses campos em uma visualização:

filter: new_filter_test{
  type: date
}

dimension: filter_start{
  type: date
  sql: {% date_start new_filter_test %} ;;
}

dimension: filter_end{
  type: date
  sql: {% date_end new_filter_test %} ;;
}

Se você filtrar um "Explorar" no new_filter_test usando o período de 1o de abril de 2022 a 25 de maio de 2022, a dimensão filter_start vai ser avaliada como 1o de abril de 2022, e a filter_end vai ser avaliada como 25 de maio de 2022.

Observe o seguinte sobre date_start e date_end:

• Se o usuário não filtrar a consulta usando o filtro especificado na parte date_filter da variável Liquid, {% date_start date_filter %} e {% date_end date_filter %} serão avaliados como NULL.

• Se o usuário filtrar a consulta com um intervalo aberto no filtro especificado na parte date_filter da variável Liquid, a extremidade aberta do intervalo será resolvida como NULL. Por exemplo, usando o exemplo, se, em "Explorar", um usuário definir new_filter_test como antes de 2022-06-07, a saída {% date_start date_filter %} será NULL, já que o usuário especificou um intervalo com data de término, mas sem data de início. Se um usuário definir o new_filter_test como após 2022-06-07, a saída {% date_end date_filter %} será NULL.

Em qualquer um desses cenários em que a saída do Liquid pode mostrar um resultado NULL, inclua uma função SQL no parâmetro sql para contabilizar valores NULL, como IFNULL ou COALESCE, dependendo do dialeto do seu banco de dados.

Consulte a página Práticas recomendadas para usar date_start e date_end e veja uma explicação detalhada sobre como usar as variáveis Liquid date_start e date_end para lidar com tabelas particionadas por data.

Consulte a postagem da comunidade Análise flexível de um período para o outro para ver um exemplo de uso de date_start e date_end para uma análise flexível de cada período.

Uso de _in_query, _is_selected e _is_filtered

As variáveis _in_query, _is_selected e _is_filtered fornecem um valor verdadeiro ou falso, conforme mostrado neste exemplo. Consequentemente, é importante escolher o tipo apropriado de referência de variável Liquid.

Se você quiser determinar se algo está incluído em sua consulta e, em seguida, inserir determinado texto com base nisso, use um padrão como este:

{% dynamic if view_name.field_name._in_query %}
  something to insert if true
{% dynamic else %}
  something to insert if false
{% dynamic endif %}

Se você quiser inserir literalmente a palavra "true" ou "false", use um padrão como este:

{{ view_name.field_name._in_query }}

Alguns dialetos SQL não aceitam as palavras literais "verdadeiro" e "falso". Nesse caso, é possível adicionar o filtro sql_boolean para receber os valores verdadeiros e falsos necessários:

{{ view_name.field_name._in_query | sql_boolean }}

Os mesmos padrões se aplicam às variáveis _is_selected e _is_filtered.

Uso de variáveis Liquid com o parâmetro label

Você pode usar variáveis Liquid no parâmetro label de um campo para alterar dinamicamente a aparência do campo no seletor de campo e nas visualizações. Consulte a seção Tabela nesta página para ver quais variáveis Liquid funcionam com o parâmetro label.

As variáveis líquidas funcionam com parâmetros de rótulo no nível do campo, incluindo os parâmetros label, view_label, group_label e group_item_label, mas não funcionam com parâmetros de rótulo no nível de modelo, exploração, visualização ou referência ou com rótulo como um subparâmetro de link.

As variáveis a seguir podem ser usadas com label para afetar o seletor de campo, os cabeçalhos de coluna na seção de dados de uma exploração e as visualizações:

• _model._name
• _view._name
• _explore._name
• _field._name
• _user_attributes['name_of_attribute']

As outras variáveis Liquid marcadas com LA na tabela acima, como aquelas que retornam um valor com base em um filtro (como _filters) ou que exigem que uma consulta seja executada antes que o valor da variável possa ser determinado (como in_query), não alteram o nome do campo no seletor de campo. Nesses casos, o nome do campo só será alterado na visualização resultante.

Ao usar a variável Liquid parameter com label, label transmite o valor do subparâmetro value.

Uso de variáveis Liquid com o parâmetro description

Você pode usar variáveis Liquid com o parâmetro description para alterar dinamicamente a descrição de um campo. Essa descrição aparece quando os usuários passam o cursor sobre o ícone de informações do campo no seletor de campo, o nome da coluna do campo na seção de dados do Explorar ou o nome da coluna do campo em um gráfico de tabela. Consulte a tabela na seção Definições de variáveis líquidas nesta página para ver quais variáveis funcionam com o parâmetro description.

As variáveis líquidas funcionam com o parâmetro description somente no nível do campo. Eles não funcionarão com o parâmetro description no nível de exploração.

As variáveis a seguir podem ser usadas com description para afetar o seletor de campo, a seção de dados de uma exploração e o cabeçalho da coluna em um gráfico de tabela:

• _model._name
• _view._name
• _explore._name
• _field._name
• _user_attributes['name_of_attribute']

As outras variáveis Liquid marcadas com DE na tabela acima, como as variáveis Liquid que retornam um valor baseado em um filtro (como _filters) ou que exigem que uma consulta executada antes do valor da variável ser determinado (como in_query) não alteram a descrição no seletor de campo ou na seção de dados de uma exploração. Essas variáveis só afetam a descrição exibida quando um usuário passa o cursor sobre o cabeçalho da coluna do campo em um gráfico de tabela.

Para ver exemplos de como usar o Liquid no parâmetro description, consulte a página de documentação do parâmetro description.

Informações importantes

Referência a campos yesno

Para referenciar o valor de um campo yesno, ele diferencia maiúsculas de minúsculas. Use Yes ou No. Exemplo:

{% dynamic if value == 'Yes' %}

Como usar operadores lógicos com variáveis Liquid

É possível usar os operadores lógicos and, or e not com variáveis Liquid. Os operadores lógicos no Liquid diferenciam maiúsculas de minúsculas e devem ser escritos em letras minúsculas. Exemplo:

{% dynamic if value == "Shirt" or value == "Shoes" %}
  This is a shirt or shoes.
{% dynamic endif %}

Erro "Variável não encontrada"

Um dos motivos pelos quais você pode receber esse erro em Liquid é usar {{ }} e {% %} ao mesmo tempo, como este:

{% if value > {{ search_latency_top_hr.limit_95._value }} %}

Em vez disso, faça o seguinte:

{% dynamic if value > search_latency_top_hr.limit_95._value %}

Se você estiver usando um filtro de modelo, verifique se está referenciando um nome de tabela que não se uniu à tabela derivada.

As convenções de nomenclatura podem afetar o agrupamento de consultas

Se houver um campo com o nome value, ele será incluído na cláusula GROUP BY de uma consulta "Explorar" sempre que a variável value "Liquid" for referenciada em outro campo na mesma visualização.

Exemplo:

dimension: id {
  primary_key: true
  type: number
  sql: ${TABLE}.id ;;
  html:
    {% dynamic if value > 10 %}
      <font color="darkgreen">{{ rendered_value }}</font>
    {% elsif value > 11 %}
      <font color="goldenrod">{{ rendered_value }}</font>
    {% dynamic else %}
      <font color="darkred">{{ rendered_value }}</font>
    {% dynamic endif %} ;;
}

dimension: value {
  sql: ${TABLE}.status ;;
  type: string
}

Isso gerará o seguinte SQL quando apenas id for selecionado em uma exploração:

SELECT
orders.id AS orders.id,
orders.status AS orders.value
FROM order_items
LEFT JOIN orders ON order_items.order_id = orders.id

GROUP BY 1,2
ORDER BY orders.id
LIMIT 500

Para evitar esse comportamento de agrupamento, defina o escopo da variável value com o nome do campo para fazer referência explícita a ele:

dimension: id {
  primary_key: true
  type: number
  sql: ${TABLE}.id ;;
  html:
    {% dynamic if value > 10 %}
      <font color="darkgreen">{{ id._rendered_value }}</font>
    {% elsif value > 11 %}
      <font color="goldenrod">{{ id._rendered_value }}</font>
    {% dynamic else %}
      <font color="darkred">{{ id._rendered_value }}</font>
    {% dynamic endif %} ;;
}

O uso de _filters['view_name.field_name'] em uma tabela derivada requer sql_quote

Ao definir uma tabela derivada baseada em SQL, se você usar a variável Liquid _filters['view_name.field_name'] em que o valor é renderizado em SQL e o filtro retornar um valor de string, será necessário colocar aspas simples ao redor da saída. Para fazer isso, inclua o filtro sql_quote líquido.

Por exemplo, se você estiver usando uma destas variáveis Liquid no parâmetro sql de um derived_table:

{{ _filters['view_name.field_name'] }}

ou

{% assign foo = _filters['view_name.field_name']  %} foo

É possível anexar o filtro | sql_quote líquido à declaração da variável Liquid:

{{ _filters['view_name.field_name'] | sql_quote }}

e

{% assign foo = _filters['view_name.field_name'] | sql_quote %} foo

Veja um exemplo de tabela derivada que usa a variável _filters['view_name.field_name']:

view: users_sql_based_dt {
  derived_table: {
    sql:
    SELECT
      users.id AS id,
          (DATE(users.created_at)) AS created_date,
      users.city AS city,
      COUNT(*) AS user_count
    FROM
        public.users AS users
    {% dynamic if users_sql_based_dt.city._is_filtered %}
      WHERE
        users.city = {{ _filters['users_sql_based_dt.city'] | sql_quote  }}
    {% dynamic endif %}
    GROUP BY
        1,
        2,
        3
    ORDER BY
        2 DESC
      ;;
  }

O campo city é uma string que será enviada ao SQL. Portanto, o filtro "Liquid" sql_quote é necessário para garantir que o SQL de saída esteja entre aspas simples. Na guia "Explorar", resultante, quando um usuário especifica um nome de cidade como filtro, o Looker coloca a string de nome da cidade entre aspas. O Looker enviará esse SQL ao banco de dados se um usuário filtrar a consulta "Explorar" com o valor de cidade New York:

WHERE
    users.city = 'New York'

Se você estiver usando a variável Liquid _filters['view_name.field_name'] para um campo de string em uma tabela derivada em que o valor é renderizado em SQL, você receberá o seguinte alerta LookML se não anexar | sql_quote à variável Liquid:

Using "_filters[]" in Derived Table SQL without "sql_quote" is discouraged.

Também é possível usar sql_quote com esta sintaxe para citar vários valores em uma matriz:

{{ _filters['view_name.field_name'] | split:"," | sql_quote | join:"," }}

Veja um exemplo em que a saída Liquid está sendo usada como entrada para uma instrução IN:

 WHERE
    users.city IN({{ _filters['users_sql_based_dt.city'] | split:"," | sql_quote | join:"," }})

Com essa sintaxe, a saída líquida terá aspas ao redor de cada valor individual ('value1','value2','value3') em vez de aspas na lista completa ('value1, value2, value3').

As variáveis líquidas em medidas agregadas afetam o agrupamento

Quando você usa a sintaxe {{ view_name.field_name._value }} ou {{ field_name._value }} no parâmetro link ou html de uma medida para fazer referência a um valor de outro campo, o Looker extrai esse campo na consulta SQL para capturar o valor dele. Por isso, o Liquid pode afetar como as consultas SQL são geradas e quantas colunas a cláusula GROUP BY usa, o que pode causar um comportamento inesperado quando você está trabalhando com medidas agregadas, como medidas de type: count.

Por exemplo, suponha que você tenha as duas medidas a seguir:

measure: count_without_liquid {
  type: count
}

measure: count_with_liquid {
  type: count
  link: {
    label: "Status Count"
    url: "https://www.google.com/search?q={{ status._value }}"
  }
}

Quando você gera uma consulta usando a medida count_without_liquid, consegue os seguintes resultados:

Nesse caso, a consulta retorna uma única contagem para cada mês. O SQL gerado para os resultados anteriores é mostrado a seguir:

SELECT
  TO_CHAR(DATE_TRUNC('month', order_items.created_at ), 'YYYY-MM') AS "order_items.created_month",
  COUNT(*) AS "order_items.count_without_liquid"
FROM order_items AS order_items

GROUP BY DATE_TRUNC('month', order_items.created_at )
ORDER BY 1 DESC
LIMIT 500

No entanto, ao gerar uma consulta usando a medida count_with_liquid, você recebe os seguintes resultados:

Este exemplo mostra que, em vez de uma contagem para cada mês na consulta, você recebe uma contagem para cada mês e para cada status. Isso ocorre porque, no SQL gerado, o campo status foi adicionado à consulta para que o valor possa ser recuperado. Como ele foi adicionado à consulta, também foi adicionado à cláusula GROUP BY:

SELECT
  TO_CHAR(DATE_TRUNC('month', order_items.created_at ), 'YYYY-MM') AS "order_items.created_month",
    order_items.status AS "order_items.status",
    COUNT(*) AS "order_items.count_without_liquid"
FROM order_items AS order_items

GROUP BY DATE_TRUNC('month', order_items.created_at ),2
ORDER BY 1 DESC
LIMIT 500

Uma opção para impedir que isso aconteça é usar a função row[] com a variável Liquid, que extrai o valor dos resultados renderizados no navegador e, portanto, não adiciona o campo referenciado à consulta SQL:

  link: {
    label: "{% dynamic if row['view_name.field_name'] %} some_label {% dynamic endif %}"
    url: "https://www.google.com/search?q={{ row['view_name.field_name'] }}"
  }

Ao usar essa sintaxe, o parâmetro link funcionará somente se o campo for selecionado ou incluído na consulta por outros meios.

Resumindo, o uso da sintaxe row[] não fará com que o campo seja adicionado à consulta como {{ field_name._value }} faz. O rótulo dinâmico fará com que o link não tenha rótulo se o campo não estiver disponível. Isso fará com que o link desapareça do menu de links.