question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

v3 - optional labels

See original GitHub issue

I have a use-case where labels are part of a field it self and are controlled by field because of design requirements. So I would like to have a way to remove label rendering completely.

I saw that in new version you are offering usage of label templating with slots. But even if slot is empty you still render label tag. So for someone to remove label it has to remove it in schema currently.

I would suggest you make some additional form option or something that would indicate what parts of “general” layout should be rendered.

Current workaround is to ditch label in schema and introduce some other custom property that would act like one.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:9 (6 by maintainers)

github_iconTop GitHub Comments

1reaction
gapiprocommented, Oct 18, 2018

Yep thats exactly what I have done. Thanks for help.

0reactions
zoul0813commented, Oct 18, 2018

think of label as a reserved property, that is common and shared across all VFG fields. You can introduce a new custom property called “labelText” or “customComponentLabel” (where “customComponent” would be the name of your component … so the field is specific to your component.

I believe v3 is introducing a standard “property bucket” called “attributes” or something similar … where custom components can place any extra bits, without overriding VFG core fields.

For example …

{
  "type": "customComponent",
  "model": "model",
  "attributes": {
    "label": "custom label for your component to use"
  }
}

You can also change “attributes” to be the name of your custom component, and store any necessary properties your component needs in this object … keeping your components custom properties scoped to itself, without littering the fields common scope properties.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Allow explicit optional in proto3 · Issue #275 · bufbuild/buf
Explicit 'optional' labels are disallowed in the Proto3 syntax. To define 'optional' fields in Proto3, simply remove the 'optional' label, ...
Read more >
How to define an optional field in protobuf 3 - Stack Overflow
Since protobuf release 3.15, proto3 supports using the optional keyword (just as in proto2) to give a scalar field presence information.
Read more >
Language Guide | Protocol Buffers - Google Developers
optional int32 result_per_page = 3; }. The SearchRequest message definition specifies three fields (name/value pairs), one for each piece of data that you ......
Read more >
Compose file version 3 reference - Docker Documentation
It's recommended that you use reverse-DNS notation to prevent your labels from conflicting with those used by other software. build: context: . labels: ......
Read more >
Gerrit Code Review - Review Labels
The defaultValue must be within the range of valid label values. It is an optional label setting, if not defined the defaultValue for...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found