A way to access list elements with the dot notation

[DmitrySharabin]

Motivation

Mavo allows us to access object properties via:

• the get() function (get(obj, foo))
• the dot notation (obj.foo).
• the bracket notation (obj["foo"])*.

(*) The latter is possible either by disabling expressions on an element and its descendants (via mv-expressions="none" or mv-expressions-ignore) or re-defining expressions syntax (via mv-expressions).

However, there is no way to access list items by their index with the dot notation. E.g., foo.1 is impossible. It is worth mentioning that this is not a Mavo weakness; in the JS world, array.1 is also impossible. However, something like array.$1 is perfectly valid.

Proposal

Add an alias for a list item index, prepending it with $ so that we can have something like foo.$1, equal to get(foo, 1), which is also equal to get(foo, $1). This should play well and be consistent with other special properties we already support on lists.

Note: Of course, there is no need to use get(foo, $1) when we already have get(foo, 1). My point is that it shouldn't break the code and return the expected result.

[LeaVerou]

Props for having a motivation section, though ideally it should also include a little on what user pain point the proposal is addressing. Sometimes this may be obvious, but in this case it's not, at least not to me.

Once we implement #1009, this would be obj.get(1) as well. And as you point out obj[1] where brackets don't mean "expression" (and with smarter parsing, we could enable them even where it does), which is exactly the same number of characters as obj.$1.

[DmitrySharabin]

Sometimes this may be obvious, but in this case it's not, at least not to me.

Right. After you have commented, I can clearly see that my proposal sounds like: “Let’s add this feature because it's cool.” Let’s not do that. 😅

ideally it should also include a little on what user pain point

For sure. Will take this into account next time. Thank you!

Once we implement #1009, this would be obj.get(1) as well. And as you point out obj[1] where brackets don't mean "expression" (and with smarter parsing, we could enable them even where it does), which is exactly the same number of characters as obj.$1.

That would be awesome. Can’t wait.

In conclusion, I’m going to close this (useless) issue.