Referencia de variables líquidas

Liquid es un lenguaje de plantillas que puedes usar en Looker para crear contenido más dinámico. Por ejemplo, puedes crear URLs 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 de un usuario.

Las instrucciones líquidas se crean a partir de variables, filtros y etiquetas. Las variables contienen información que desea utilizar, y las variables que proporciona Looker se describen en esta página. Puedes modificar esos valores aún más con filtros y etiquetas, que puedes leer en esta guía sobre líquidos.

En LookML, puede usar varios líquidos, como los siguientes:

• 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 usos 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 el líquido en Looker. En este método, encierra la variable líquida entre dos llaves. Por ejemplo: {{ value }}
2. Sintaxis de la etiqueta: Por lo general, este tipo de uso no inserta texto, sino para comparaciones lógicas y otras operaciones líquidas. En este método, encierra la variable líquida en 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 está insertando 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.altostrat.com/product_images/{{ value }}.jpg" /> ;;
}

En este ejemplo de uso de una URL, se inserta un nombre de artista en una URL para generar una búsqueda de Google de 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 según los campos que elige el usuario. La sintaxis usa una estructura if, de lo contrario, (se indica 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 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 obtener ejemplos de uso adicionales, consulta la página de parámetros de LookML individual que te interesa.

Cómo acceder 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 de 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 la variable líquida {{ field_name._value }}, el campo referenciado se agrega a la cláusula SELECT de la consulta en 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 provocar resultados inesperados en las medidas agregadas. Para obtener más información, consulta la sección sobre 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. En la columna Uso, se indica con qué parámetros de LookML se puede usar cada variable líquida, y se incluyen 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 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, incluidos los parámetros label, view_label, group_label y group_item_label, pero no funcionará con parámetros de etiqueta a nivel de modelo, Explorar, vista o línea de 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 al valor de un 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 hacer referencia a la sintaxis de formato de fechas en rendered_value, como se muestra en la página Easy date format with Liquid Best Pratices. 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 que tiene el formato adecuado para usarse como filtro en una URL de Looker. Por ejemplo, cuando filtras un valor de string que incluye una coma como “Altostrat, Inc”, la variable value mostrará dos strings diferentes: “Inc” y “Altostrat”. La variable filterable_value corrige este problema escapando caracteres especiales y mostrando una sola string, en este ejemplo, "Altostrat, 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 un vínculo predeterminado, por lo que requieren la 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 aplicaron al campo que solicitaste 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. El uso de _filters['view_name.field_name'] en un parámetro sql de tabla derivada requiere el filtro de líquido sql_quote.	A DE H LA LI	NO NULOS
{% date_start date_filter_name %}	Es la fecha de inicio de 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
{% date_end date_filter_name %}	Es 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 a sql_or_lookml_reference como SQL. Esta variable se usa con filtros con plantilla y uniones condicionales.	S	Consulta la página de documentación de Filtros con plantilla y la sección Uniones condicionales de la página de documentación de sql_on para ver ejemplos.
{% parameter parameter_name %}	El valor del filtro de parámetro que solicitas con parameter_name.	DE LA S	Consulta la página de documentación del parámetro parameter para ver ejemplos.
parameter_name._parameter_value	Inserta 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 del parámetro parameter para obtener detalles y ejemplos importantes.
Atributos de usuario
_user_attributes['name_of_attribute']	El valor del atributo del usuario que solicitas con name_of_attribute para el usuario específico que ejecuta la consulta, si se usan estos atributos. 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 del usuario era "región") Consulte la página Prácticas recomendadas para usar la inserción de nombres de tablas y esquemas dinámicos a fin de obtener un ejemplo adicional.
_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	aspecto
_view._name	El nombre de la vista para este campo.	A DE H LA LI S	orders
_explore._name	El nombre de Explorar para este campo.	A DE H LA LI S	pedidos_artículos
_explore._dashboard_url	ADDED 22.12 La URL relativa del panel actual.	H LI S	/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
Consultas
_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	verdadero
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	verdadero
view_name.field_name._is_selected	Muestra true si el campo que pides con view_name.field_name aparece en la tabla de datos de la consulta.	DE LA LI S	verdadero
view_name.field_name._is_filtered	Muestra true si el campo que pides con view_name.field_name se incluye en un filtro para la consulta.	DE LA LI S	verdadero

Uso de date_start y date_end

Las variables líquidas date_start y date_end son muy útiles para los dialectos de las 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 una exploración en new_filter_test mediante 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, tanto {% date_start date_filter %} como {% 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 usamos example, en Explorar un usuario establece new_filter_test en antes del 7 de junio de 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 del 7 de junio de 2022, el resultado {% date_end date_filter %} será NULL.

En cualquiera de estas situaciones en las que la salida líquida pueda mostrar un resultado de NULL, asegúrate de incluir una función de 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 la página de prácticas recomendadas sobre el uso de date_start y date_end a fin de obtener una explicación detallada de cómo usar las variables líquidas date_start y date_end para trabajar con tablas particionadas por fecha.

Consulta la publicación de Comunidad sobre el período flexible entre períodos de Analytic Block para ver un ejemplo del uso de 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. Por lo tanto, es importante elegir el tipo adecuado de referencia de variable líquida.

Si deseas determinar si se incluyó o no algo en tu consulta y, luego, insertar cierto texto según eso, debes usar un patrón como el siguiente:

{% 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 "verdadero" o "falso", usa un patrón como este:

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

Se aplican los mismos patrones 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 su apariencia en el selector de campos y en las visualizaciones. Consulta la sección Tabla en esta página para ver qué variables líquidas funcionarán con el parámetro label.

Las variables líquidas funcionan con parámetros de etiqueta a nivel de campo, incluidos los parámetros label, view_label, group_label y group_item_label, pero no funcionan con parámetros de etiqueta a nivel de modelo, Explorar, vista o línea de referencia, ni con etiquetas como subparámetro de link.

Las siguientes variables se pueden usar con label para modificar el selector de campos, los encabezados de columnas 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 se pasa 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 de campo. No funcionarán con el parámetro description a nivel de Explorar.

Las siguientes variables se pueden usar con description para modificar el selector de campos, 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 que requieren que una consulta se ejecute antes de que se pueda determinar el valor de la variable (como in_query) no cambiarán la descripción en el selector de campos o en la sección de datos de Explorar. Estas variables líquidas solo afectarán la descripción que se muestra cuando un usuario coloca el cursor sobre el encabezado de columna del campo en 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 yesno campos

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

Cómo usar operadores lógicos con variables líquidas

Puedes usar los operadores lógicos and, or y not con variables líquidas. En Liquid, 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 not found"

Es posible que veas este error en Liquid si usas {{ }} y {% %} al mismo tiempo, como se muestra a continuación:

{% 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 usa un filtro con plantilla, compruebe si hace referencia a un nombre de tabla que no ingresó en la tabla derivada.

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

Si hay un campo con el nombre value, este se incluirá en la cláusula GROUP BY de una consulta de Explorar cada vez 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

A fin de evitar este comportamiento de agrupación, asegúrate de definir el alcance de la variable value con el nombre del campo para hacer referencia a él de manera explícita:

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 alguna 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 variable líquida:

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

y

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

Esta es una tabla derivada de ejemplo en la que se 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 se necesita el filtro líquido sql_quote para asegurarse de que el SQL de salida esté entre comillas simples. En la herramienta Explorar resultante, cuando un usuario especifica el nombre de una ciudad como un 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 función del valor de la 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 agregas | 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 array:

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

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

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

Con esta sintaxis, el resultado de Liquid tendrá comillas alrededor de cada valor individual ('value1','value2','value3'), en lugar de tener comillas alrededor de la lista completa ('value1, value2, value3').

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

Cuando usas la sintaxis {{ view_name.field_name._value }} o {{ field_name._value }} en los parámetros link o html de una medida para hacer referencia a un valor de otro campo, Looker extrae ese campo en la consulta en SQL para tomar el valor del campo. Debido a esto, el líquido puede afectar la manera en que se generan las consultas de SQL y la cantidad de columnas que usa la cláusula GROUP BY, lo que puede causar un comportamiento inesperado cuando trabajas 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 por 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 contar cada mes en la consulta, usted 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 pueda recuperar su valor. Además, 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 en 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 funciona solo si el campo está seleccionado o incluido en la consulta por otros medios.

Para resumir, 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ú correspondiente.