-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Soft deprecate the concept of label in config and split its responsabilties #1291
Labels
Comments
Skaiir
added
enhancement
New feature or request
needs discussion
Needs further discussion
labels
Oct 3, 2024
Skaiir
changed the title
Soft deprecate the concept of label in config and split its responsabilties (proposal)
Soft deprecate the concept of label in config and split its responsabilties
Oct 8, 2024
Skaiir
added a commit
that referenced
this issue
Oct 10, 2024
Skaiir
added a commit
that referenced
this issue
Oct 10, 2024
Skaiir
added a commit
that referenced
this issue
Oct 10, 2024
bpmn-io-tasks
bot
added
needs review
Review pending
and removed
in progress
Currently worked on
labels
Oct 10, 2024
Skaiir
added a commit
that referenced
this issue
Oct 14, 2024
Skaiir
added a commit
that referenced
this issue
Oct 14, 2024
Skaiir
added a commit
that referenced
this issue
Oct 14, 2024
Closed via #1300 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Currently, we have a unified concept of label that takes on two different responsibilities. It defines (in most cases) the default label a component is using. It also defines the "name" a component uses in the UI. Especially because of that second reason, we need to define it on every component, which is confusing for components that don't have a label.
Describe the solution you'd like
So for clarity and allowing us to control those two behaviors independently, I would propose that we split it into these two configs:
To keep backwards compatibility with potential custom components, but move forwards, I think we should:
Describe alternatives you've considered
Keep it as-is?
Additional context
Somewhat related to or to be worked on with #1290
This allows us to get rid of the hardcoded solution for datetime label added here #1292
The text was updated successfully, but these errors were encountered: