Welcome back to AppSheet’s Feature Friday where we showcase new and favorite features. This quick guide will help you build your apps faster so you can focus on what matters.
In no-code, expressions are one way to enrich the performance and end user experience of your applications. The proper expression can display different information for different users, perform advanced actions or perform calculations based on data points. Our recent Office Hours covered some of the fundamentals of working with expressions, but we wanted to dive a little deeper into a particular area of the expression family with the engineer who built it,
Read my chat with Natalie, a software engineer who's showing some major love to our expression offerings.
Jennifer: Recently you’ve been working on a rather large project related to derefs. Before we dive too deep into the details, can you explain what a “Ref” is and how it differs from a “deref”
Natalie: A "Ref" (short for "reference") is a possible type for a data column. If a column is a Ref, that means that it holds a key to a row in another table. Refs are essential for connecting tables with related information. For example, we could have tables for Rooms and Buildings, where a Building has many Rooms. If we wanted a Room to record which Building it is in, the Room would have a Ref column to hold the key of a row in Buildings.
A "deref" (short for "dereference") is an expression you can use with Refs. It allows you to access columns of a row in another table. Let's say the Buildings table has another column called "Address". If a row in the Rooms table wanted to compute the Address value, and it had a Ref column called "RefToBuilding", we can use the deref expression "[RefToBuilding].[Address]". Pretty cool, right?
Jennifer: Very cool! There's already a lot of value in the refs we provide, why did we make the decision to invest in this engineering area? What benefit does it provide Creators or their end users?
Natalie: Before, it was hard to create Refs, since the AppSheet server often wouldn't produce Refs as the output type of an expression. By removing this barrier, it is easier for app Creators to do more with their data through derefs or other expressions that use Refs. Refs are also useful for the end user, who can use Refs to open or edit the referenced row without having to do anything with the raw key value.
Jennifer: What changes will app Creators see?
Natalie: The main changes focus on more expressions producing Ref as the output type. This is currently in rollout, but all users should see this change by the end of this month. These include:
To prevent breaking existing apps, I added the ability for expressions that expect a certain type to automatically convert Refs to the expected type.
I also expanded derefs to work with Enums of base type Ref and list dereferences to work with EnumLists of base type Ref.
Jennifer: With so many changes, do you have a personal favorite or change that you find really helpful?
Natalie: My favorite is the change for Ref column value expressions to produce Ref. It's an issue that is personal to me, since the previous behavior kinda bamboozled me when I was a first-time user. So, driving the change felt like a personal milestone!
Jennifer: That's amazing! Before we close out our conversation, are there any closing thoughts you'd like to share?
Natalie: Just feeling proud to be part of a supportive team and tackling a fun and challenging problem. :)
Thank you again to Natalie from our incredible engineering team for your contributions to this week's post. Be sure to follow along in the AppSheet Creator Community for additional updates and get started building your next app today.