[MUSIC PLAYING]
YULAN LIN: Hi my name is Yulan Lin,
and I'm a developer advocate for Data Studio.
Data Studio Community visualizations
allow you to create custom components that
integrate seamlessly with your Data Studio dashboards.
In this video, we're going to talk
about how the visualization config maps
to the message containing information
that Data Studio sends to the component.
A quick note on vocabulary.
In this video, I'll refer to the overall package of information
that Data Studio provides a community visualization
as a message.
So the config and the message are related
because the configuration is the contract that
defines how much the report editor can configure things,
whether it's in the data, or what style options are
available, or whether or not the visualization
can act as a chart filter.
So the config then determines the structure
of the message provided, and the report editor's solutions
determine the content of the message.
In other words, the message is the structure
dictated by the configuration plus the report editor's
selections that fill in that structure.
And this is really important because consistency
of structure allows a single visualization
to work across multiple data sets.
Let's take a look at each of the keys in the message
that Data Studio sends and map it
to the keys in the config file.
So for each of these slides, part of the config
will be on the left, and the corresponding part
of the message will be on the right side.
For clarity and space, there's a bunch
of places where I've truncated objects and lists,
so ellipses and empty objects and empty lists
are often stand ins for there's information,
but I wanted to make it easier to follow.
Let's jump in by looking at the parts of the message associated
with the data config.
First, the field's property.
So fields is an object where each key corresponds
to the idea of a data element.
Each data element ID is associated
with a list of fields, whether there
are none, one, or multiple fields associated
with each data element.
So, for example, here I have a data element
in the config whose ID is source ID
and so will show up in fields with a source ID key,
and those will correspond to the fields
that the report editor has selected in the property panel.
Next, the tables object.
So this is generally the core of information to be visualized.
The library supports two different data formats,
and I'm only going to talk about the default data table here.
So in the table format, headers is a flattened list
of field objects, and the rows are
a row of rows corresponding to the data,
so imagine a table of your data.
The header field objects here have an extra config ID
field to preserve the relationship between data
element and data because both in headers and in rows,
things have been flattened so you can no longer directly
associate them with the config ID they came from.
In the object format, there is no heading.
Each row is an object, and each row object
contains keys that map to the data
element keys with an array of the values in that row that
correspond to the information in that data
element similar in structure to how fields are structured.
Let's look at style now.
In the style object, each key corresponds
to the ID of a style element.
Each style element ID is associated with the report
editor selected value, and if present,
the default value for that particular style element.
Again, the style sections have no bearing
on the organization of the style part of the message.
So in interactions, the key, if present,
corresponds to the ID of the interaction element.
So here, the interaction element has an ID of on click,
and that's going to be a property of the message
interaction section.
And that information corresponds to whether or not
the chart is configured as a chart filter
and whether or not it is currently acting as a filter.
So just to summarize, in this video,
we've talked about how the config maps to the message
and you see how the data config maps
to fields and tables, the style config maps style,
and the interactions config maps to interactions.
The IDs for data elements, style elements, and interaction
elements are all really important to keep
track of because that's how you'll
access relevant parts of the message from Data Studio
to use in your visualization.
To learn more about community visualizations,
visit developers.googl e.com/datastudio/visualization
and connect with us on social media using the hashtag
datastudiodevs.