Referencia de variable líquida

Liquid es un lenguaje de plantillas que puedes usar en Looker para crear contenido más dinámico. Por ejemplo, puedes crear URL para herramientas externas basadas en los resultados de una consulta o cambiar la tabla de la base de datos que se consulta en función de la selección del usuario.

Las declaraciones líquidas se crean a partir de variables, filtros y etiquetas. Las variables contienen la información que desea utilizar, y las variables que proporciona Looker se describen en esta página. Puede modificar aún más esos valores mediante filtros y etiquetas, que puede obtener más información en esta Guía sobre líquidos.

Existen varios lugares en LookML en los que puede usar líquidos:

• El parámetro action
• El parámetro description de un campo (pero no de Explorar)
• El parámetro html
• Parámetros de etiquetas a nivel de campo, incluidos los parámetros label, view_label, group_label y group_item_label
• El parámetro link
• Parámetros que comienzan con sql (como sql y sql_on)
• El parámetro de filtro del panel default_value
• El parámetro del elemento del panel filters

Usa variables líquidas

El uso básico de variables líquidas es sencillo. Una vez que haya identificado la variable que desea utilizar (consulte la siguiente lista), simplemente insértela en un parámetro de LookML válido. A continuación, se definen las variables líquidas específicas que puede usar en parámetros específicos de LookML.

Dos tipos de uso de líquidos

Existen dos maneras de usar una variable líquida:

1. Sintaxis de salida: Este tipo de uso puede insertar texto y es, probablemente, la forma más común de usar líquido en Looker. En este método, encierra la variable líquida entre llaves. Por ejemplo: {{ value }}
2. Sintaxis de etiquetas: Por lo general, este tipo de uso no inserta texto; en cambio, es para comparaciones lógicas y otras operaciones de Líquido. En este método, encierra la variable líquida con una llave y un signo de porcentaje único. Por ejemplo: {% dynamic if value > 10000 %}

Ejemplos básicos

En este ejemplo de uso de HTML, se inserta un ID de producto en una etiqueta <img> para generar imágenes del producto:

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

En este ejemplo de uso de URL, se inserta un nombre de artista en una URL para generar una búsqueda de Google para ese 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"
  }
}

En este ejemplo de uso de SQL, la tabla de la base de datos se determina en función de los campos que elige el usuario. La sintaxis usa una estructura if, de lo contrario, (denotada como elsif), else, para verificar y reaccionar a los campos incluidos en la 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 %} ;;

En este ejemplo de uso de la etiqueta, la dimensión email cambia su valor label según el nombre del modelo de LookML. Esto cambiará de forma dinámica el nombre del campo en el selector de campos y en cualquier resultado de consulta que incluya la dimensión 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 más ejemplos de uso, consulta la página de parámetros individuales de LookML que te interesa.

Accede a variables desde otros campos

Por lo general, las variables líquidas se basan en el campo en el que se usan. Sin embargo, también puedes acceder a los valores de otros campos si es necesario.

Usa el formato {{ view_name.field_name._liquid-variable-name }} para acceder a otros campos desde la misma fila en el resultado de la consulta. Reemplaza _liquid-variable-name por cualquiera de las variables líquidas de Looker. Asegúrate de que el nombre de la variable esté precedido por un guion bajo si no es normal, como se muestra a continuación:

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

En este ejemplo, se muestra este tipo de uso para acceder a una URL del sitio web desde un campo diferente:

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

Cuando haces referencia a otro campo con la sintaxis de variable líquida {{ field_name._value }}, el campo al que se hace referencia se agrega a la cláusula SELECT de la consulta de SQL y se agrega como una columna adicional en la cláusula GROUP BY. Esto es necesario para recuperar correctamente los valores en el campo al que se hace referencia. Sin embargo, puede generar resultados inesperados en las medidas agregadas. Para obtener más información, consulte la sección Cómo usar variables líquidas en medidas agregadas en esta página.

Definiciones de las variables líquidas

En la siguiente tabla, se describen las variables líquidas que puedes usar con LookML. La columna Uso indica con qué parámetros de LookML se puede usar cada variable líquida y, además, incluye las siguientes opciones:

A = Funciona con el parámetro action

DV = Funciona con el parámetro default_value (para paneles)

DE = Funciona con el parámetro description a nivel de campo, pero no funcionará con description a nivel de Explorar.

F = Funciona con el parámetro filters (para elementos del panel)

H = Funciona con el parámetro html

LA = Funciona con los parámetros de etiqueta a nivel de campo, incluido el parámetro label, el parámetro view_label, el parámetro group_label y el parámetro group_item_label, pero no funcionará con los parámetros de etiqueta a nivel del modelo, Explorar, Ver o hacer referencia, o con label como subparámetro de link

LI = Funciona con el parámetro link

S = Funciona con todos los parámetros de LookML que comienzan con sql (p. ej., sql, sql_on y sql_table_name).

Variable	Definición	Uso	Resultado de ejemplo
Valores de campo
value	El valor sin procesar del campo que muestra la consulta de la base de datos. Puede hacer referencia a un valor de campo dinámico. Además de los parámetros que se muestran en la columna Uso, se admite value en el subparámetro label de los parámetros action y link.	A H LI	8521935
rendered_value	El valor del campo con el formato predeterminado de Looker. Puedes consultar la sintaxis de formato de fecha en rendered_value, como se muestra en el artículo Formato de fecha sencillo con Liquid del Centro de ayuda. Además de los parámetros que se muestran en la columna Uso, rendered_value es compatible con el subparámetro label de los parámetros action y link.	A H LI	USD 8,521,935.00
filterable_value	El valor del campo con formato para usar como filtro en una URL de Looker. Por ejemplo, cuando filtras por un valor de string que incluye una coma como “Periaptly, Inc”, la variable value muestra dos strings diferentes, “Periaptly” y “Inc”. Para corregir esto, la variable filterable_value escapa caracteres especiales y muestra una sola string, en este ejemplo, "Periaptly, Inc".	A H LI	8521935
Vínculos
link	La URL al vínculo del taladro predeterminado de Looker. Ten en cuenta que algunos campos no tendrán ningún vínculo predeterminado.	A H LI S	/explore/thelook/orders?fields=orders.order_amount&limit=500
linked_value	El valor del campo con el formato y la vinculación predeterminados de Looker. Las medidas no tienen vinculaciones predeterminadas, por lo que requieren una configuración del parámetro drill_fields para funcionar con linked_value.	A H LI	USD 8,521,935.00
Filtros
_filters['view_name.field_name']	Los filtros de usuario que se aplican al campo que solicitas con view_name.field_name. _filters['view_name.field_name'] también es compatible con el parámetro sql de una tabla derivada, pero no es compatible con otros parámetros sql. Para usar _filters['view_name.field_name'] en una tabla derivada, el parámetro sql requiere el filtro líquido sql_quote.	A DE H LA LI	NO NULOS
{% date_start date_filter_name %}	La fecha de inicio de un filtro de fecha que solicites con date_filter_name. Consulta la sección Uso de date_start y date_end para obtener más información.	S	2017-01-01
{% date_end date_filter_name %}	La fecha de finalización en un filtro de fechas que solicitas con date_filter_name. Consulta la sección Uso de date_start y date_end para obtener más información.	S	2017-01-01
{% condition filter_name %} sql_or_lookml_reference {% endcondition %}	El valor del filtro que solicitas con filter_name aplicado al sql_or_lookml_reference como SQL. Esta variable se usa con filtros de plantilla y uniones condicionales.	S	Consulta la página de documentación Filtros de plantilla y la sección Uniones condicionales de la página de documentación sql_on para ver ejemplos.
{% parameter parameter_name %}	El valor del filtro de parámetros que solicitas con parameter_name.	DE LA S	Consulta la página de documentación de parámetros de parameter para ver ejemplos.
parameter_name._parameter_value	Incorpora el valor del filtro de parámetro que solicitas con parameter_name en una instrucción lógica.	DE H LA LI S	Consulta la página de documentación de parámetros de parameter para obtener detalles y ejemplos importantes.
Atributos de usuario
_user_attributes['name_of_attribute']	El valor del atributo de usuario que solicitas con name_of_attribute para el usuario específico que ejecuta la consulta, si se usan atributos de usuario. La variable _user_attributes['name_of_attribute'] también se puede usar en la sintaxis de filtro avanzado.	A DE H LA LI S DV F	noreste (si, por ejemplo, el atributo de usuario era "region") Consulte el artículo del Centro de ayuda Cómo usar los atributos de usuario para la inserción dinámica de nombres de tablas y esquemas.
_localization['localization_key']	Muestra el valor asociado a la clave de localización definida en el archivo de strings del modelo según la configuración regional del usuario.	DV F	Consulta la página de documentación Localiza tu modelo de LookML para ver un ejemplo.
Objetos de LookML
_model._name	El nombre del modelo para este campo.	A DE H LA LI S	el estilo
_view._name	El nombre de la vista para este campo.	A DE H LA LI S	orders
_explore._name	El nombre de la sección Explorar de este campo.	A DE H LA LI S	pedido_artículos
_explore._dashboard_url	ADDED 22.12 La URL relativa para el panel actual.	H LI	/dashboards/5
_field._name	El nombre del campo en sí, en formato view_name.field_name.	A DE H LA LI S	pedidos.total_order_amount
Queries
_query._query_timezone	La zona horaria en la que se ejecutó la consulta.	A DE H LA LI S	America/Los_Angeles
view_name._in_query	Muestra true si se incluye algún campo de la vista en la consulta.	DE LA LI S	true
view_name.field_name._in_query	Muestra true si el campo que solicitas con view_name.field_name aparece en la tabla de datos de la consulta, se incluye en un filtro para una consulta o se incluye en una consulta a través del parámetro required_fields.	DE LA LI S	true
view_name.field_name._is_selected	Muestra true si el campo que solicitas con view_name.field_name aparece en la tabla de datos de consulta.	DE LA LI S	true
view_name.field_name._is_filtered	Muestra true si el campo que solicitas con view_name.field_name se incluye en un filtro para la consulta.	DE LA LI S	true

Uso de date_start y date_end

Las variables líquidas date_start y date_end son muy útiles para dialectos de bases de datos que particionan datos en varias tablas por fecha, como BigQuery. Ten en cuenta que debes usar la sintaxis de la etiqueta {% date_start date_filter_name %} o {% date_end date_filter_name %}. No puedes usar la sintaxis de salida {{ date_start date_filter_name }} o {{ date_end date_filter_name }}, aunque esta sintaxis se suele usar para generar texto.

Por ejemplo, puedes crear estos campos en una vista:

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 %} ;;
}

Si filtras por un elemento new_filter_test el período del 1 de abril de 2022 al 25 de mayo de 2022, la dimensión filter_start se evaluaría como 1 de abril de 2022; la filter_end se evaluaría como 25 de mayo de 2022.

Ten en cuenta lo siguiente sobre date_start y date_end:

• Si el usuario no filtra la consulta con el filtro que se especifica en la parte date_filter de la variable líquida, {% date_start date_filter %} y {% date_end date_filter %} se evaluarán como NULL.

• Si el usuario filtra la consulta con un rango abierto en el filtro que se especifica en la parte date_filter de la variable líquida, el extremo abierto del rango se resolverá en NULL. Por ejemplo, si usas el ejemplo, si en la sección Explorar un usuario establece new_filter_test en antes del 07/06/2022, el resultado de {% date_start date_filter %} será NULL, ya que el usuario especificó un rango que tiene una fecha de finalización, pero no una fecha de inicio. Si un usuario establece new_filter_test en después de 7/06/2022, el resultado de {% date_end date_filter %} será NULL.

En cualquiera de estos casos en los que la salida líquida pueda mostrar un resultado de NULL, asegúrate de incluir una función SQL en el parámetro sql para tener en cuenta los valores NULL, como IFNULL o COALESCE, según el dialecto de tu base de datos.

Consulta el tema Cómo usar date_start y date_end de la comunidad de Looker para obtener una explicación detallada sobre cómo usar las variables líquidas date_start y date_end a fin de tratar con tablas particionadas por fecha.

Consulte el artículo del Centro de ayuda sobre el Análisis flexible entre períodos del bloque de estadísticas para ver un ejemplo de cómo usar date_start y date_end para el análisis flexible entre períodos.

Uso de _in_query, _is_selected y _is_filtered

Ten en cuenta que las variables _in_query, _is_selected y _is_filtered proporcionan un valor verdadero o falso, como se muestra en este ejemplo. En consecuencia, es importante elegir el tipo adecuado de referencia de variable líquida.

Si desea determinar si se incluye o no algún elemento en su consulta, y luego insertar cierto texto basado en eso, debería usar un patrón como este:

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

Si deseas insertar literalmente la palabra "true" o "false", usa un patrón como el siguiente:

{{ view_name.field_name._in_query }}

Algunos dialectos de SQL no admiten las palabras literales "true" y "false". En ese caso, puedes agregar el filtro sql_boolean para obtener los valores verdaderos y falsos que necesitas:

{{ view_name.field_name._in_query | sql_boolean }}

Los mismos patrones se aplican a las variables _is_selected y _is_filtered.

Uso de variables líquidas con el parámetro label

Puedes usar variables líquidas en el parámetro label de un campo para cambiar dinámicamente la apariencia del campo en el selector de campo y en las visualizaciones. Consulta la sección tabla de esta página para ver qué variables líquidas funcionan con el parámetro label.

Las variables líquidas funcionan con parámetros de etiqueta a nivel de campo, incluido el parámetro label, el parámetro view_label, el parámetro group_label y el parámetro group_item_label, pero no funcionarán con los parámetros de etiqueta a nivel del modelo, Explorar, ver o hacer referencia, ni con la etiqueta como subparámetro de link.

Las siguientes variables se pueden usar con label para afectar el selector de campo, los encabezados de columna en la sección de datos de Explorar y las visualizaciones:

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

Las otras variables líquidas marcadas con LA en la tabla anterior, como las que muestran un valor basado en un filtro (como _filters) o requieren que se ejecute una consulta antes de que se pueda determinar el valor de la variable (como in_query), no cambiarán el nombre del campo en el selector de campos. En esos casos, el nombre del campo solo se cambiará en la visualización resultante.

Cuando usas la variable líquida parameter con label, label recibe el valor del subparámetro value.

Uso de variables líquidas con el parámetro description

Puedes usar variables líquidas con el parámetro description para cambiar de forma dinámica la descripción de un campo. Esta descripción aparece cuando los usuarios se desplazan sobre el ícono de información del campo en el selector de campo, el nombre de columna del campo en la sección de datos de Explorar o el nombre de columna del campo en un gráfico de tabla. Consulta la tabla en la sección Definiciones de las variables líquidas de esta página para ver qué variables líquidas funcionan con el parámetro description.

Las variables líquidas funcionan con el parámetro description solo a nivel del campo. No funcionarán con el parámetro description en el nivel Explorar.

Las siguientes variables se pueden usar con description para afectar el selector de campo, la sección de datos de Explorar y el encabezado de columna en un gráfico de tabla:

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

Las otras variables líquidas marcadas con DE en la tabla anterior, como las variables líquidas que muestran un valor basado en un filtro (como _filters) o requieren que una consulta se ejecute antes de que se pueda determinar el valor de la variable (como in_query), no se modificará la descripción en el selector de campos ni en la sección de datos de Explorar. Estas variables líquidas solo afectan la descripción que se muestra cuando un usuario se desplaza sobre el encabezado de columna del campo de un gráfico de tabla.

Para ver ejemplos de cómo usar líquido en el parámetro description, consulta la página de documentación del parámetro description.

Aspectos para tener en cuenta

Haz referencia a campos yesno

Para hacer referencia al valor de un campo yesno, este distingue entre mayúsculas y minúsculas. Usa Yes o No Por ejemplo:

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

Usa operadores lógicos con variables líquidas

Puedes usar los operadores lógicos and, or y not con variables líquidas. En Líquido, los operadores lógicos distinguen mayúsculas de minúsculas y deben escribirse en minúsculas. Por ejemplo:

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

Cómo obtener el error "Variable no encontrada"

Uno de los motivos por los que puedes recibir este error en Liquid es si usas {{ }} y {% %} al mismo tiempo, de la siguiente manera:

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

En su lugar, haz lo siguiente:

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

Si utiliza un filtro con plantilla, verifique si hace referencia a un nombre de tabla que no haya unido a la tabla derivada.

Las convenciones de nombres pueden afectar la agrupación de consultas

Si hay un campo con el nombre value, este campo se incluirá en la cláusula GROUP BY de una consulta de exploración siempre que se haga referencia a la variable líquida value en otro campo dentro de la misma vista.

Por ejemplo:

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
}

Esto generará el siguiente SQL cuando solo se seleccione id en Explorar:

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 este comportamiento de agrupación, asegúrate de definir el alcance de la variable value con el nombre del campo que haga referencia explícita al 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 %} ;;
}

El uso de _filters['view_name.field_name'] en una tabla derivada requiere sql_quote

Cuando defines una tabla derivada basada en SQL, si usas la variable líquida _filters['view_name.field_name'] en la que el valor se renderiza en SQL y el filtro muestra un valor de string, debes agregar comillas simples alrededor del resultado. Para ello, incluye el filtro de líquido sql_quote.

Por ejemplo, si usas cualquiera de estas variables líquidas en el parámetro sql de un parámetro derived_table:

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

o

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

Puedes agregar el filtro de líquido | sql_quote a la declaración de la variable líquida:

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

y

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

A continuación, se muestra una tabla derivada de ejemplo que usa la variable _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
      ;;
  }

El campo city es una string que se enviará a SQL, por lo que el filtro líquido sql_quote es necesario para asegurarse de que el resultado de SQL esté entre comillas simples. En la Explorar resultante, cuando un usuario especifica el nombre de una ciudad como filtro, Looker encierra la string del nombre de la ciudad entre comillas. Looker envía este SQL a la base de datos si un usuario filtra la consulta Explorar en el valor de ciudad New York:

WHERE
    users.city = 'New York'

Si usas la variable líquida _filters['view_name.field_name'] para un campo de string en una tabla derivada en la que el valor se renderiza en SQL, recibirás la siguiente advertencia de LookML si no anexas | sql_quote a la variable líquida:

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

También puedes usar sql_quote con esta sintaxis para citar varios valores en un arreglo:

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

En este ejemplo, se usa la salida líquida como entrada para una declaración IN:

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

Con esta sintaxis, la salida Líquida tendrá comillas alrededor de cada valor individual ('value1','value2','value3') en lugar de comillas alrededor de la lista completa ('value1, value2, value3').

Las variables líquidas en las mediciones agregadas afectan la agrupación

Cuando usas la sintaxis {{ view_name.field_name._value }} o {{ field_name._value }} en el parámetro link o html de una medida para hacer referencia a un valor de otro campo, Looker extrae ese campo en la consulta de SQL para tomar el valor del campo. Debido a esto, Líquido puede afectar cómo se generan las consultas de SQL y cuántas columnas usa la cláusula GROUP BY, lo que puede causar un comportamiento inesperado cuando se trabaja con medidas agregadas, como las de type: count.

Por ejemplo, supongamos que tienes las dos medidas siguientes:

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 }}"
  }
}

Cuando generas una consulta con la medida count_without_liquid, obtienes los siguientes resultados:

En este caso, la consulta muestra un solo recuento para cada mes. A continuación, se muestra el SQL que se genera para los resultados anteriores:

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

Sin embargo, cuando generas una consulta con la medida count_with_liquid, obtienes los siguientes resultados:

En este ejemplo, se muestra que en lugar de un recuento por cada mes de la consulta, se recibe un recuento por cada mes y por cada estado. Esto se debe a que, en el SQL generado, se agregó el campo status a la consulta para que se pudiera recuperar su valor. Y, como se agregó a la consulta, también se agregó a la 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

Una opción para evitar que esto suceda es usar la función row[] con la variable líquida, que extrae su valor de los resultados procesados en el navegador y, por lo tanto, no agrega el campo al que se hace referencia en la consulta de 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'] }}"
  }

Cuando uses esta sintaxis, ten en cuenta que el parámetro link solo funciona si el campo está seleccionado o incluido en la consulta por otros medios.

En resumen, el uso de la sintaxis row[] no hará que el campo se agregue a la consulta como lo hace {{ field_name._value }}. La etiqueta dinámica hará que el vínculo no tenga ninguna etiqueta si el campo no está disponible, lo que hace que el vínculo desaparezca del menú de vínculos.