Part 2 in a series about modeling data for Liquid.
This is a follow up post to Data Modeling For Liquid - Part 1 where you learned what data types are, and how they can be composed to create new data types. This is critical knowledge to understand when working with Liquid as a Designer. However, in reality the application you’re working with for Liquid has already done the work of defining the data types that are available.
For many applications, this involves doing some homework by researching their documentation. Let’s take a look at Shopify for example. You can see how they have modeled their “Customer” object for liquid here.
Looking over this Object, many of the data types can be inferred by the descriptions (although this is not always obvious and sometimes requires interpretation). Here’s an example of how Shopify has modeled “Customers”:
Scanning over the object, you can see where they are nesting two levels deep (by using dot notation). You can infer we are “digging” into a second Object in this case. For example, take a look at these attributes on Customer:
As you can see, every attribute name starts with “customer.defaultAddress.”. This is because we’re accessing a second “Address” object model. In other words, you could simplify this modeling to look like this:
Shopify has defined an “Address” Object model as well as Customer. The Address model Object looks like this:
Understanding how the Object modeling works is key to understanding that you don’t necessarily need to refer to Shopify’s exact documentation every time you want to access something on the “defaultAddress” for a Customer object in Liquid. As you’re writing your Liquid expression, you should always think about what data type your expression will “return”. Here are some examples:
Once you understand how the application you’re working with has modeled their data, you can use “dot notation” to traverse that model in any way you would like and free yourself from their static documentation.
Liquid dot notation is an extremely powerful feature, but requires some research to use correctly. Since every application is different, you must read over each application’s documentation to understand how that application has modeled their data before using Liquid.
Dropkiq eliminates the need for this research. With Dropkiq, simply type {{ }} and a menu will instantly pop up showing the user all of the data they have access to. Each time you dig into another object, a new menu pops open showing all the new data you have access to.
This is just one of the ways that Dropkiq enables anyone to write Liquid instantly while skipping the research homework.
