Can I function without LAMBDA?
Yes, you most certainly can! In Tines you can get very far with actions, action templates, the story library, and a variety of functions.
LAMBDA is typically the spot in our automation journey where we need to go farther into the data.
Let's take a step back though and think about LAMBDA in how it can provide value.
What is LAMBDA?
LAMBDA is a way to create variables and run them through expressions. At Tines we focus our efforts on no code / low code.
Variables are one of those coding principles that we've adopted to provide a bridge for advanced users as well as a means for new users to delve deeper into the product. In LAMBDA we will "declare" our variables. Essentially telling our function what we want to call them. It could be something simple like "i" or something more specific like "users". Just like how when we do an explode action and determine what each individual item is going to be exploded as (individual_item is the default in explode).
When we talk about expressions or arguments, this essentially means doing calculations. It can be some form of simple math like 2 + 100, or something that leverages a type of function like INCLUDES
. If we continue with INCLUDES
as our example this function only looks at one object and asks for what value to see. If it happens to see that value in there it will return a true, if it doesn't it will return a false.
In this example we have a super simple payload of John Smith: "kickoff":"John Smith"
When I use INCLUDES to check for Smith it'd look like INCLUDES(Kickoff,"Smith")
.
The results of this action running would be "includes_example":"true"
.
Again, these are just the concepts of naming variables and running some form of calculations. Let's continue to unpack LAMBDA.
Flavors of LAMBDA
There are two flavors of LAMBDA within Tines. There is LAMBDA as a standalone function that can be nested in other actions or used standalone to run through expressions, or there are some functions that have LAMBDA as a requirement like FILTER.
Let's take a quick look at a high level of what the functions look like of LAMBDA vs LAMBDA within a function.
LAMBDA function
LAMBDA([parameter1, parameter2, …,] calculation)
FILTER function
FILTER(array | object, values_to_keep | LAMBDA(item, [expr]))
The primary difference here is that the FILTER function is going through each item in the array and is using LAMBDA to run the calculations. So we're looking at the primary array, creating a variable to reference as we loop through the array, then we are using LAMBDA to determine how we filter.
When and Why!
The best time to get the LAMBDA hammer 🔨 out is when you have nested arrays and need to extract, filter, or modify. Typically we can leverage a series of actions like explode, event transform with modifiers and implode to work through an array to get whatever data set.
LAMBDA lets us boil down some of that building into 1 action, which can be very advantageous as we level our building skills.
LAMBDA is typically not the answer to building if you can pull in 1 action to get the job done. It is designed to be something to dig deeper into your data set and apply dynamic calculations. It can typically be seen as the last step in a builder's journey - hence it being at the end of the chapter! Enough of that, though, let's dive into a quick example.
Example
Here we have an example array from an action called "kickoff". Inside the array, we'll see there is email, name, and IP. By using FILTER
, we can refine our array to only be users with the last name Smith.
{
"kickoff": [
{
"email": "johndoe@example.com",
"name": "John Doe",
"ip": "192.168.1.1"
},
{
"email": "lousmith@example.com",
"name": "Lou Smith",
"ip": "192.168.1.2"
},
{
"email": "mike@example.com",
"name": "Mike Smith",
"ip": "192.168.1.3"
},
{
"email": "franklinthomas@example.com",
"name": "Franklin Thomas",
"ip": "192.168.1.4"
},
{
"email": "janedoe@example.com",
"name": "Jane Doe",
"ip": "192.168.1.5"
},
{
"email": "gerg@example.com",
"name": "Greg Smith",
"ip": "192.168.1.6"
}
]
}
The function would be FILTER(kickoff, LAMBDA(i,INCLUDES(i.name,"Smith")))
. In naming the variable, you see I use "i". This could be called anything we want. Then I use the function of INCLUDES, which asks me for a value to check and what I want to check for. I end up using i.name because as we loop through the array the object we are looking for is called "name". So we are able to go down our JSON path just like we would reference a value in the following actions. Then lastly, telling it to look for any time there is "Smith" in the name.
The results would look like this:
[
{
"email": "lousmith@example.com",
"name": "Lou Smith",
"ip": "192.168.1.2"
},
{
"email": "mike@example.com",
"name": "Mike Smith",
"ip": "192.168.1.3"
},
{
"email": "gerg@example.com",
"name": "Greg Smith",
"ip": "192.168.1.6"
}
]
Jumping from functions to functions with LAMBDAs
Earlier in our examples, we looked at using MAP
with an array where we refine our array to one object. If we look at our functions we also have a MAP_LAMBDA
which gives us a slightly different variation of MAP
. The original MAP
is more about extracting a portion of the array, where MAP_LAMBDA
is the result of calling LAMBDA with each element of the input array.
This makes it so we can do more than extract some data, we can apply a variety of logic on top.
MAP_LAMBDA(
kickoff,
LAMBDA(
elem,
OBJECT(
"User",
elem
)
)
)
In this expression, we loop through and add a parent object of "User".
[
{
"User": {
"email": "johndoe@example.com",
"name": "John Doe",
"ip": "192.168.1.1"
}
},
{
"User": {
"email": "lousmith@example.com",
"name": "Lou Smith",
"ip": "192.168.1.2"
}
},
{
"User": {
"email": "mike@example.com",
"name": "Mike Smith",
"ip": "192.168.1.3"
}
},
{
"User": {
"email": "franklinthomas@example.com",
"name": "Franklin Thomas",
"ip": "192.168.1.4"
}
},
{
"User": {
"email": "janedoe@example.com",
"name": "Jane Doe",
"ip": "192.168.1.5"
}
},
{
"User": {
"email": "gerg@example.com",
"name": "Greg Smith",
"ip": "192.168.1.6"
}
}
]
Additional callouts:
LAMBDA within functions can only use 1 variable
Examples:
FILTER
,FIND
,MAP_LAMBDA
LAMBDA as a standalone function can use as many variables as you want
WHERE
vsFILTER
WHERE
is great when you know what key you're looking forFILTER
is great when you have dynamic values, like doing > or < in your expression. It's also great if you need to make complex comparisons.
FILTER
/MAP
/WHERE
- most effective for story buildingFunctions with LAMBDA: https://www.tines.com/docs/formulas/functions#lambdas
LAMBDA function : https://www.tines.com/docs/formulas/functions/lambda