Referência de variável líquida

O líquido é uma linguagem de modelo que pode ser usada no Looker para criar conteúdo mais dinâmico. Por exemplo, é possível criar URLs para ferramentas externas com base nos resultados de uma consulta ou mudar qual tabela de banco de dados é consultada com base na seleção do usuário.

Extratos líquidos são criados com base em variáveis, filtros e tags. As variáveis contêm as informações que você quer usar, e as variáveis fornecidas pelo Looker são descritas nesta página. Para modificar ainda mais esses valores, use filtros e tags. Leia este guia do Liquid.

Existem vários lugares em LookML que podem ser usados como líquido:

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

Como usar variáveis líquidas

O uso básico das variáveis Liquid é simples. Depois de identificar a variável que você quer 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 de líquidos

Há duas maneiras de usar uma variável líquida:

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

Exemplos básicos

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

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

Neste exemplo de uso de URL, um nome de artista é 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 quais campos o usuário escolhe. A sintaxe usa um if, caso contrário (identificado como elsif), estrutura 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 vai mudar dinamicamente o nome do campo no seletor de campo e em todos os resultados de consulta que incluam 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 de outros campos

As variáveis líquidas geralmente são baseadas no campo em que estão sendo usadas. No entanto, também é possível 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 líquidas do Looker. O nome da variável precisa ser precedido por um sublinhado se não for normal, como neste exemplo:

• {{ 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> ;;
}

Ao referenciar outro campo com a sintaxe de variável líquida {{ field_name._value }}, o campo referenciado é adicionado à cláusula SELECT da consulta SQL e adicionado 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 o uso de 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 líquidas que você pode usar com o LookML. A coluna Uso indica com quais parâmetros do 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 do Explorar

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ótulos no nível do campo, incluindo label, view_label, group_label e group_item_label, mas não funciona com parâmetros de rótulo no nível de modelo, exploração, 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 a um valor dinâmico de 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	Valor do campo com a formatação padrão do Looker. Faça referência à sintaxe da formatação de datas em rendered_value, conforme mostrado no artigo da Central de Ajuda Formatação fácil de data com líquido. Além dos parâmetros exibidos 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 "Periaptly, Inc", a variável value retorna duas strings diferentes, "Periaptly" e "Inc". A variável filterable_value corrige isso fazendo o escape de caracteres especiais e retornando uma única string, neste exemplo, "Periaptly, Inc".	A H LI	8521935
Links
link	O URL para o link de detalhamento padrão do Looker. Alguns campos não têm link padrão.	A H LI S	/explore/thelook/orders?fields=orders.order_amount&limit=500
linked_value	Valor do campo com formatação padrão e vinculação padrão do Looker. As medidas não têm vinculação padrão. Portanto, elas precisam de 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. Para usar o _filters['view_name.field_name'] em um parâmetro do sql da tabela derivada, é preciso usar o filtro de líquido sql_quote.	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ê solicita com date_filter_name. Consulte a seção Uso dos date_start e do date_end para ver mais informações.	S	2017-01-01
{% date_end date_filter_name %}	A data de término no filtro de data que você solicita com date_filter_name. Consulte a seção Uso dos date_start e do date_end para ver mais informações.	S	2017-01-01
{% condition filter_name %} sql_or_lookml_reference {% endcondition %}	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 JOINs condicionais da página de documentação sql_on.
{% parameter parameter_name %}	O valor do filtro de parâmetro que você pede com parameter_name.	DE LA S	Veja exemplos na página de documentação de parâmetros parameter.
parameter_name._parameter_value	Injeta o valor do filtro de parâmetro solicitado com parameter_name em uma instrução lógica.	DE H LA LI S	Consulte a página de documentação dos parâmetros do 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ê solicita com name_of_attribute, para o usuário específico que executa 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 de filtro avançado.	A DE H LA LI S DV F	nordeste (se, por exemplo, o atributo do usuário for "region") Consulte o artigo da Central de Ajuda Como usar atributos do usuário para esquema dinâmico e injeção de nome de tabela para mais um exemplo.
_localization['localization_key']	Retorna o valor associado a uma chave de localização definida em um arquivo de strings do modelo com base na localidade do usuário.	DV F	Consulte a página de documentação Como localizar seu modelo LookML para ver um exemplo.
Objetos LookML
_model._name	O nome do modelo para este campo.	A DE H LA LI S	o visual
_view._name	Nome da visualização deste campo.	A DE H LA LI S	pedidos
_explore._name	O nome do recurso "Explorar" para este campo.	A DE H LA LI S	order_items
_explore._dashboard_url	ADDED 22.12 O URL relativo do painel atual.	H LI	/dashboards/5
_field._name	É o nome do próprio campo no formato view_name.field_name.	A DE H LA LI S	Orders.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 qualquer campo da visualização for 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 ou estiver incluído em um filtro de 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 aparecer 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 líquidas date_start e date_end são muito úteis para dialetos de bancos de dados que particionam dados em várias tabelas por data, como o BigQuery. É preciso usar 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, você pode 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 Explore em new_filter_test usando o período de 1° de abril de 2022 a 25 de maio de 2022, a dimensão filter_start será avaliada como 1o de abril de 2022, e o filter_end será avaliado 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, o final aberto do intervalo será resolvido 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, porque o usuário especificou um intervalo com data de término, mas não data de início. Se um usuário definir o new_filter_test como após 2022-06-07, a saída de {% date_end date_filter %} será NULL.

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

Consulte o tópico Como usar date_start e date_end da comunidade do Looker para uma explicação detalhada sobre como usar as variáveis líquidas date_start e date_end para lidar com tabelas particionadas por data.

Consulte o artigo Análise flexível de um período da Central de Ajuda do bloco analítico para ver um exemplo de como usar o date_start e o date_end para uma análise flexível de um período a outro.

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, como mostrado neste exemplo. Consequentemente, é importante escolher o tipo apropriado de referência de variável líquida.

Se quiser determinar se algo será incluído na consulta, insira um texto específico 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 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 suportam as palavras literais "quot;true" e "false". 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 líquidas com o parâmetro label

É possível usar variáveis líquidas no parâmetro label de um campo para mudar dinamicamente a aparência de um campo no seletor de campo e nas visualizações. Consulte a seção Tabela nesta página para ver quais variáveis líquidas funcionarão 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 colunas 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 líquidas 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 mudam 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 líquida parameter com label, label é transmitido ao valor do subparâmetro value.

Uso de variáveis líquidas com o parâmetro description

É possível usar variáveis líquidas 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 da guia "Explorar" ou o nome da coluna do campo em um gráfico de tabelas. Consulte a tabela na seção Definições de variáveis líquidas nesta página para ver quais variáveis líquidas funcionam com o parâmetro description.

As variáveis líquidas funcionam com o parâmetro description apenas no nível do campo. Elas não funcionarão com o parâmetro description no nível "Explorar".

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 tabelas:

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

As outras variáveis líquidas marcadas com DE na tabela acima, como variáveis líquidas 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 determinada (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 líquidas só afetam a descrição mostrada quando um usuário passa o cursor sobre o cabeçalho da coluna do campo em um gráfico de tabelas.

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

Considerações

Referência a campos yesno

Para referenciar um valor do 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 em líquido são sensíveis a maiúsculas e minúsculas e precisam ser escritos em letras minúsculas. Exemplo:

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

O erro de "variável não encontrada"

Um dos motivos para você receber esse erro no Liquid é se você usar {{ }} e {% %} ao mesmo tempo, desta forma:

{% 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 uniu à tabela derivada.

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

Se houver um campo com o nome value, esse campo será incluído na cláusula GROUP BY de uma consulta "Explorar" sempre que a variável líquida value 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 um Explore:

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 referenciar explicitamente o campo:

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 líquida _filters['view_name.field_name'] em que o valor é renderizado no SQL e o filtro retornar um valor de string, será necessário adicionar aspas simples na saída. Para fazer isso, inclua o filtro de líquido sql_quote.

Por exemplo, se você estiver usando uma destas variáveis líquidas 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 de líquido | sql_quote à declaração de variável de líquido:

{{ _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 de líquido sql_quote é necessário para garantir que o SQL de saída esteja entre aspas simples. No Explorar resultante, quando um usuário especifica o nome de uma cidade como um filtro, o Looker coloca a string de nome de cidade entre aspas. O Looker envia esse SQL ao banco de dados se um usuário filtrar a consulta"Explorar"pelo valor da cidade New York:

WHERE
    users.city = 'New York'

Se você estiver usando a variável líquida _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 líquida:

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

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

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

Veja aqui um exemplo em que a saída do líquido 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 do Fluid terá aspas em torno 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 a sintaxe {{ 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 do campo. 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ê estiver trabalhando com medidas agregadas, como medidas de type: count.

Por exemplo, imagine que você tem 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 }}"
  }
}

Ao gerar uma consulta usando a medida count_without_liquid, você tem 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 com a medida count_with_liquid, você tem 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 status. Isso acontece porque, no SQL gerado, o campo status foi adicionado à consulta para que o valor dela possa ser recuperado. E, como foi adicionado à consulta, ele 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, por isso, não adiciona o campo referenciado na 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 só funcionará 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 }}. O marcador dinâmico fará com que o link não tenha rótulo se o campo não estiver disponível, o que faz com que o link desapareça do menu de links.