Data Modeling For Liquid - Part 2

Part 2 in a series about modeling data for Liquid.

Adam Darrah
Feb 21, 2020 9:30 AM
Data Modeling For Liquid - Part 2

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

AttributeData Type

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:

Attribute Data Type
customer.defaultAddress.address1 String
customer.defaultAddress.address2 String String String

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:

AttributeData Type

Shopify has defined an “Address” Object model as well as Customer. The Address model Object looks like this:

AttributeData Type

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:

  • The expression {{ customer }} returns a Customer Object
  • The expression {{ customer.displayName }} returns a String
  • The expression {{ customer.defaultAddress }} returns an Address Object
  • The expression {{ customer.defaultAddress.address1 }} returns a String

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.

Dropkiq Is Here to Help

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.

You might also like...

Explore how Dropkiq can help improve your user experience.

Writing Liquid expressions is hard. Let Dropkiq help you make it easier.