Outer CurrentValue access

For me Option1 is the most straightforward. Colors can also help to match the right level of CurrentValue with the right list.


@shishir Given how you’re currently doing it elsewhere in coda, e.g. when there’s column name ambiguity, and given the apparent need for backwards compatibility — I think it would make the most sense to just have multiple CurrentValue options in the suggestions list, and distinguish them by color and type, and specify in the variable description where it comes from. It would look something like this:


CurrentValue1, CurrentValue2 would be confusing. It’s not clear that 1, 2 etc refer to nesting. This would make more sense to keep it for the scenario when an outer function needs to pass multiple values down the FormulaMap, e.g. a full join of two lists.

I wouldn’t introduce new syntax just for this. I really don’t see a problem piggybacking on existing system (unless there’s a technical one). As I said, you already have disambiguation mechanism in your formula editor. Actually, the screenshots above are not fake :slight_smile:

Another option would be to give these variable completely distinct, verbose names e.g. EvaluatedRow in filter, ThisObject or Iterator in FormulaMap or something. But I’d actually stay with CurrentValue.


While aliasing and naming would work better from a formal / coding perspective, I do agree with @Paul_Danyliuk that the coloring is already a convention for competing variables so why not re-use it?

Second this.

Coloring is great to identify the scope, event though it’s currently broken with nested functions. But I assume that would be fixed.

Just to throw in another idea, in addition to coloring, you could think of appending the formula name to it, e.g. ....FormulaMap(...Filter(currentValueFilter = currentValueFormulaMap))

I also agree this is the best solution. However, one way that it might lead to frustration is in copy-pasting… ideally the level of [currentvalue] would be kept when copy-pasting formulae.

Copy-pasting doesn’t work reliably anyways. I think it’d be a fair tradeoff.

BTW for the record, here’s a workaround solution I documented elsewhere. Past due it belongs in this topic:

1 Like

I want to bump this. Just came up for me. I am trying to emulate the output of a Pie Chart, which does this type of thing as part of its default function … I want to be able to get an array of all the ‘pie percents’.

+1 to Option 1 @shishir

I too am struggling with the need of being able to do FormulaMap(SomeOtherThing.filter(OUTER_CURRENT_VALUE_NEEDED_HERE))

P.S. Re copy-pasting. I think internally in Coda references in formulas are copy-pasted by their full $$[] descriptors, not just the names. And it’s just the names when you paste it outside of Coda. My point is, correct CurrentValues may actually stay preserved when copying formulas within Coda.

More about the $$[] operator:

Sorry if I’m hijacking this thread, but maybe there’s a way here I haven’t thought of

Where I’ve hardcoded “Linnéa”, I’d like to use the CurrentValue from the FormulaMap. Is there a way? :slight_smile:

Edit: It wasn’t clear in the screenshot, but there can be multiple assignments (and members working) on any given day

My 2 cents on this topic, while having multiple CurrentValue's in this list and highlighting the matching scope with coloring/bold is a nice UX consistent with the current webapp, I believe that an explicit solution is required - certainly at the server API level.

So why not just focus on that first, and roll it out to the UI level as well as a first pass?

So something like :CurrentValue or some other “escaping” character (like ... for file systems) to refer to the outer scope(s), as mentioned earlier as a possible solution.

I don’t see how to get around the need for explicit syntax - the other solutions are just syntactic/visual sugar to layer on top of this.


Can you please share the doc here or with just me actinarium@gmail.com? I think there’s a way around this.

E.g. if you pull in all assignments for a user, you can rewrite your FormulaMap as:

  CurrentValue.Assignments.Filter(Date = thisRow.Date).Load.Sum()
1 Like

I think you might be on to something, we just have to filter by task start and end date instead. I think…

Look at Workload Lab section:

I’ll look a bit later — going to be super busy rn.

1 Like

Not sure what’s happening here, why can’t I access the Assignments columns after the Filter() call?


edit: It’s as if Filter() returns Members.Assignments.[Project task]…


It’s unclear to me exactly what you’re after. But here’s one approach that might give you some ideas.

1 Like

Hey, @Ander, thanks for giving this a shot! Interesting with how you use Sequence and Nth, I did not know one could construct loops like that. Your approach is close to what I want, I want the sum of load per assignment, per user. As in: Stefan: 125%, Pontus: 50% etc. You’re close but I don’t get how to modify your column 8 to give that result.

Using Sequence and Nth, I managed to solve it :slight_smile:

Sequence(1, thisRow.Members.Count()).FormulaMap(

Thanks @Ander for giving me a way to the solution!


Eh, hey @Ander, you’ve modified your document afterwards, right? Since I can now see what I was going for in it? :smiley:

1 Like


Yes, I cleaned it up for future reference. Nice work solving that. I learned a new technique, thanks!

1 Like