I too assumed the ‘persistent’ property would be most useful when applied to view parameters, however I believe the intent is to toggle off the ‘persistent’ preference on the properties that reference your view parameters, though I’ve only arrived at this realization as a result of this conversation. This presumably allows saving test view parameter values to the project, while being sure to ignore them at runtime, as the ‘bound’ property value literally doesn’t exist in the JSON.
For what it’s worth, only input parameters are unable to be bound. As a workaround, you can change parameters to read/write (input/output) by clicking the arrow to the right of the parameter. This will allow static expression bindings as @Carl.Gould mentions to be attached and thus they will no longer be subject to the permanent deletion by the ‘persistent’ preference implementation as it exists today (values won’t be saved, but the binding expression will).
I’d suggest this is most definitely only a workaround, and could potentially cause problems if a now read/write parameter that should be input/read-only were somehow/accidentally exposed in a writable component.
It does seem to make intuitive sense (to me anyway) that input view parameters, while not able to be bound, should have a method of saving a default or
null value (or modifying value persistence), thus allowing us to modify them at will in the designer (for test purposes) without having to revert them or worry that the test values might get saved to the view. This seems more initially accessible than finding/changing the ‘persistent’ preference on all the properties that reference the view params (multiple bound properties reference single view parameters in my world). This was the root of my misunderstanding.
Here’s a thought - perhaps all bound properties should be non-persistent by default and input/in-out view parameters should always be persistent? This would negate the issue of having to worry about view param initial values and force designers to plan for "default’ initial conditions if they don’t want errors in cases where bindings fail, as opposed to designing to avoid seeing test/initial values when bindings fail? Of course this would break existing installs that rely on seeing initial values in error conditions.