Best practice for checking if lookup matches element without toText()?

1

Hi, I keep running into situations where I need to determine which of a series of values another look-up column has selected. For example:

SwitchIf(
   thisRow.Frequency.toText()="One-time", ...,
   thisRow.Frequency.toText()="Monthly", ...,
   thisRow.Frequency.toText()="Quarterly", ...,
   thisRow.Frequency.toText()="Yearly", ...,
)

Using the toText() method feels very brittle. Ideally I’d like the flexibility to check both by value (as I’m doing here) and by reference so that if the options label text changes, the linkage changes along with it (as is the case when columns are renamed).

Any guidance on the best practice for comparing by reference instead of by value?

In a pseudo-Coda-ese, I’d want a reference comparison akin to:

SwitchIf(
   thisRow.Frequency=Frequency#[One-time], ...,
   thisRow.Frequency.toText()=Frequency#Monthly, ...,
   thisRow.Frequency.toText()=Frequency#Quarterly, ...,
   thisRow.Frequency.toText()=Frequency#Yearly, ...,
)

Where the # symbol reflects that I’m referring to the display value of a specific row in the Frequency table, and that if the display value changes this formula would update accordingly (like columns do) and won’t break.

2

@MrChrisRodriguez Where do you see the brittleness? The ideas that come up for me is to further specify your frequency by chaining into the next value, ie thisrow.Frequency.[TimeFrame]="Monthly".

Also look into the ability to reference a singular row by typing @[Display Column] - this will link you directly to the row so it will work even if the column name changes.

Hope these help! :pray:

3

Hi @MrChrisRodriguez,
two things:

  1. (The trivial one) for the sake of simplicity, if you test against the same condition you might use Switch() instead of SwitchIf(). Therefore
Switch(thisRow.Frequency.toText(),
  "One-time", ...,
  "Monthly", ...,
  "Quarterly", ...,
  "Yearly", ...,
)
  1. I concur with @Johg_Ananda’s idea, however I’d ask you if you have a sample to share to dig into the data model: I tend to avoid to have literals (i.e. explicit values) in formulas as they represent a potential integrity threat. Maybe this is not the case, but in case…