v3 - optional labels
See original GitHub issueI 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:
- Created 5 years ago
- Comments:9 (6 by maintainers)
Top 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 >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Yep thats exactly what I have done. Thanks for help.
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 …
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.