Model labels are part of the model metadata. Model and field metadata (which would also include field names and types) is considered static. We don’t really support dynamic or frequent changes to any metadata, because that would create an extremely unstable experience. Merge variables are dynamic and change frequently, so we don’t currently support merge syntax in field metadata properties.

Perhaps we should reconsider this for labels, but it would be a new feature as we’d need to add the ability to broadcast changes to the metadata so that other parts of the Skuid runtime could update. I’m going to log this as an idea/suggestion and we’ll consider it for a future release.

Thanks for taking a look at this JD.  In the example, the model metadata never changes, it always remains “Overridden on Model: {{{Name}}}”.  What is dynamic is the text that is displayed on the screen based on the model metadata being run through merge processing.

If you override at the field editor field level, the label you specify is run through merge processing.  This leads to inconsistent behavior depending on where you override the label.  The only solution of which is to override at the component field level for each field.  The challenge here is that when you have multiple components all displaying the same field, you end up duplicating the same configuration (and having to maintain) in multiple places.

Understanding that metadata is static and it would continue to be even if merge syntax was processed on the label metadata.  For some reason, if you override at the field editor level, the label from metadata gets “merged” but if you override at model, it doesn’t.

Thoughts?

Thanks Barry.

There would be a lot of complexities to supporting full merge syntax in object metadata properties.

Components, like the Field Editor, don’t change the metadata - they have the advantage of being able to use metadata or not, so we give you the ability to use the object or field’s metadata or use an alternative, which is a bit different.

I get the value of the use case you’ve mentioned, however. The product team is discussing options. If we end up implementing a solution, we’ll let you know.

As always, your input is very valuable and has spurred some healthy internal discussion. Thanks, and please keep it coming.

Thanks JD.  I can definitely see where involving merge syntax in certain metadata fields would present challenges.  For the label though, unless I’m overlooking something, it would only involve running merge during rendering of the label text (across all components that use label).  That said, I can understand where setting a precedent to support merge in some metadata and not others presents its own unique challenges.  

I have several situations where I’m doing some unique things with model label metadata and supporting merge syntax would make things a ton easier.  There are some other open issues with the label (e.g. doesn’t update when model data changes as it uses text() instead of a TemplateComponent or some other dynamic listener to respond to model changes, etc.).  While in there, maybe whoever it is will slip a getMergeText in there on “accident” :) 

In the meantime, marking as under consideration makes sense.  Appreciate the dialogue, thanks again!

As a part of the fix for Obtain “Label” metadata property of field in renderer, we ended up implementing this as well. As a result, merges in model metadata label overrides should be evaluated in the Rockaway release. Two for the price of one!

Love seeing this, awesome!  Thank you!

Question - Given field.options.label will now contain the unmerged label override, assuming that there is no specific field level override, this value should contain the model label override, correct?

Yep, you got it.

Beautiful!

This fix is now available from Get the Latest Skuid Releases & Everything That Came Before in the Rockaway Release.

Tested and confirmed with Skuid 8.8.  Thank you!