I’ll share 3 patterns that I find useful in my work, because there’s always more than one way to do things in Decker.
As explained above by Missooni and Internet Janitor, a grid as a key-value store is what most people are going to want or need. It’s like a Python/Lua dictionary, JSON, or even a SQLite database. So, it covers most use cases anyone will want.
The following three examples below are some alternatives that may be useful.
Pattern 1
Many times, I’ll have an artibtary field that I’ll name, and refer to it across cards like deck.cards[card_name].widgets[widget_name].value.
deck.cards["card1"].widgets["field1"].value: "my_value"
deck.cards["card2"].widgets["field1"].value: deck.cards["card1"].widgets["field1"].value
That gets pretty verbose quickly, so I usually have a helper function:
# get["card1" "field1" "value"] <- here "value" refers to the key/attribute on the object. it's
# usually named .value - so:
# cards["card1"].widgets["field1"].value
# becomes
# get["card1" "field1" "value"]
get: on _ c w k do
cards[c].widgets[w][k]
end
# set["card1" "field1" "value" "my_value"]
# same rules as get, where the 3rd argument is the key on the decker widget and the 4th is the value
# to set, so:
# cards["card1"].widgets["field1"].value: "my_value"
# becomes
# set["card1" "field1" "value" "my_value"]
set: on _ c w k v do
cards[c].widgets[w][k]:v
end
which results in:
set["card1" "field1" "value" "my_value"]
set["card2" "field1" "value" get["card1" "field1" "value"]]
Or actually, most of the time, I’ll put the helper functions inside of a module, so the code is defined once and then I move it between my decks via the File->Resources menu:
# lib.get[deck "card1" "field1" "value"]
# when it's a module function you have to pass a deck reference,
# because the module doesn't have access to a deck otherwise
# so it's like before, except where:
# cards["card1"].widgets["field1"].value
# was
# get["card1" "field1" "value"]
# it now becomes
# lib.get[deck "card1" "field1" "value"]
lib.get: on _ d c w k do
d.cards[c].widgets[w][k]
end
# lib.set[deck "card1" "field1" "value" "my_value"]
# similar rules to set and lib.get, except where:
# cards["card1"].widgets["field1"].value: "my_value"
# was
# set["card1" "field1" "value" "my_value"]
# it now becomes
# lib.set[deck "card1" "field1" "value" "my_value"]
lib.set: on _ d c w k v do
d.cards[c].widgets[w][k]:v
end
then the previous example becomes (assuming we have a module named lib):
lib.set[deck "card1" "field1" "value" "my_value"]
lib.set[deck "card2" "field1" "value" lib.get[deck "card1" "field1" "value"]]
The benefit to doing it this way is imagine if we have structured card, with known names, and similar layouts: then it becomes easy to iterate over them. For example, say I have a deck to play a tabletop RPG and there are player characters statistics on each card. Then, imagine if I am the GM and want to “heal the players to full” with a button:
on click do
# heal the players to full, if "health" is a widget on each card:
# and "max_health" is one, too
each p in "Alice","Bob","Charlie","Doug" # this could be a variable stored somewhere
cards[p].widgets["health"].text: cards[p].widgets["max_health"].text
# which can also be written as cards[p].health.text, or cards[p].widgets["health"]["text"], etc.
end
end
That’s why I’ll manage data and state like this a lot of times, because the data I want to keep track of is spread across cards. But, each card is structured, so I know how to “address” the individual values on each card. It’s a lot like doing a JSON query or a path in a DOM. Once we know the “path” to the data that we are looking for, it’s easy to program repeatable patterns.
I use this pattern a lot in my web Decker+WebXDC+danger.js decks, because I only need to synchronize a small portion of the total data in a deck.