Lists, Sets, and Dictionaries are different types of collections you might use in Flow.
What Is a List?
Lists are the most common collection type in Flow. You can think of a list as a single row of values stored in an ordered sequence, one after the other.
Suppose you want to store a list of your favorite animals:
Giraffe | Rhino | Hippo | Tiger | Impala |
In JSON, you use straight braces [ ] to bound a list.
You would write this list of favorite animals in JSON as:
[ "Giraffe", "Rhino", "Hippo", "Tiger", "Impala" ]
Ordering
Because the order matters in a list, you can refer to items by their position (first, second, third).
Each position in the list is numbered using an index. One thing to remember is that the first item in a list is at position 0, not 1. So when we say "the first item," we actually mean the one at index 0 (zero-based indexing).
Remember our list of favorite animals? You would probably count the list as 1, 2, 3. But in programming, the numbers would go from 0 to 2 if you made a list of those animals. It might seem odd at first, but starting at 0 is common in most computer systems.
Let's store our favorite animals in rank order:
Index: | 0 | 1 | 2 | 3 | 4 |
| Giraffe | Rhino | Hippo | Tiger | Impala |
Note that we still have 5 items in the list; it’s just that the list is using a zero-based counting system.
What Is a Set?
A set is more like a “collection of unique items,” such as a bag of unique trading cards or a guest list where you don’t want the same name twice.
Sets do not allow duplicate items: if you try to add a second “giraffe,” the set only keeps one. They are good for storing data when uniqueness matters - like property names or usages in a Giraffe project.
Sets are unordered, meaning there's no meaningful “first” or “last” item. The index does not matter.
Because of how they’re built, sets are very good at checking membership (asking, “Is this thing in the set?”) very quickly. Sets also support “set-math” operations: union (combine), intersection (common items), difference (what’s in one but not the other).
For instance, if you want to compare animals at two different zoos, sets work well since order doesn't matter.
You represent sets as objects in GeoJSON, using curly braces { }
Zoo A | Zoo B |
{"lion", "zebra", "giraffe", "panda"} | {"giraffe", "elephant", "lion", "otter"} |
Because these are sets:
You can easily find the animals both zoos have (the intersection):
{"lion", "giraffe"}You can find the animals only Zoo A has:
{"zebra", "panda"}And the animals only Zoo B has:
{"elephant", "otter"}
This shows how sets shine when you want to compare groups, check membership, or find differences — without worrying about order or duplicates.
Note:
The computer will display the items in some order when it prints a set, but that order has no meaning. The set doesn’t keep track of positions or indexes — it only cares whether an item is in the set, not where it is.
What is a Dictionary
A dictionary is a collection of key–value pairs that lets you store and retrieve information by name rather than by position. Each key is unique, and it points to a specific value — similar to labeled drawers in a toolbox. In GeoJSON, dictionaries appear anywhere you see { }, such as in feature properties or geometry objects, allowing data like "height" or "landUse" to be looked up quickly by their key.
A good use of a dictionary would be storing information about individuals by a key. For instance, maybe we want to store the height of the individual animals at our zoo. We might write that like this:
"animalHeight": {
"giraffe": [5.2, 5.0],
"rhino": [1.8, 1.9]
}
We could then look up the tallest giraffe by going to that key, then pulling the largest value.
Why Use One Over the Other?
Here are a few real-world analogies + reasoning for when you might choose a list vs a set vs a dictionary, depending on the problem:
Scenario / Need | Good Choice | Why |
Order matters | List | If the sequence is important — like steps in a recipe, a playlist, or messages in a chat — a list preserves that. |
Duplicates are okay or needed | List | If it’s fine (or desirable) to have repeated items, such as logging user actions or recording multiple measurements, a list is ideal. |
Uniqueness is critical | Set | When you only care about “did we see this before?” (e.g., tracking unique users, tags, or eliminating duplicate entries), the set’s automatic deduplication is very helpful. |
Frequent membership testing (“Is X in the collection?”) | Set | Sets usually allow very fast “contains” checks because of how they’re structured, making them ideal for membership queries. |
Working with groups mathematically | Set | If you need to combine collections, find overlaps, or differences (e.g., common customers, items left out), sets support operations like union, intersection, and difference. |
Lookup by label / key | Dictionary | When you need to associate a value with a unique identifier or key (e.g., animal type → height, site ID → parcel info), dictionaries let you retrieve data quickly without caring about order. |
Multiple values per key | Dictionary | Dictionaries can store lists or nested structures as values, making them ideal for grouping related data under one label (e.g., multiple giraffe heights under “giraffe”). |
Dynamic collection with both order and labels | List of dictionaries | When you need both order and key-based access, you can combine lists and dictionaries (e.g., a list of GeoJSON features, each with properties stored in a dictionary). |