Does .value make a difference in expressions?

[lofloflof]

Hi everybody!

I'm havin issues with a rather complex MoGrT involving a heap of expressions. There are randomly ocurring glitches in the resulting videos, where results of expression calculations seem to get lost.

I consulted Copilot and they seem to think that there might be issues with my inconsistent use of .value. But even though using .value obviously makes a difference

throw typeof(transform.opacity) // -> function
throw typeof(transform.opacity.value) // -> number

the returned value of both these statements is the same:

transform.opacity.value // -> 100
transform.opacity // -> 100

Copilot claims that "Both work, but .value ensures you're getting the actual value, not the expression object."

So would I be right in understanding that omitting .value will trigger an re-evaluation of the expressions for transform.opacity, while using .value retrieves a (formerly stored) result of said expressions?

[Rick Gerard · Accepted solution]

Sometimes you need to add the dotValue (.value) to a property so that another line can find the value. Most of the time, it is not necessary. That happens a lot with JavaScript and other programming languages. I don't have time to dig into my archives to show you an example, but I have a few expression-based animation presets that do require the addition of dotValue.

[Roland Kahlenberg]

You'll want to add .value for drop menu expressions - 
effect("bGEMs DropMenu")(1).value

You will also want to do the same for checkboxes and quite often, for sourceText if you are going to perform string manipulation with its result and when accessing CSV/JSON data.

HTH

[lofloflof]

Thank you Rick and Roland for your answers.

I know when to add .value in order to get expressions to work. But I wonder what the difference is "under the hood". Will omitting .value trigger an re-evaluation of the expressions, while using .value retrieves a (formerly stored) result?