You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 24, 2024. It is now read-only.
Is your feature request related to a problem? Please describe.
Our application needs to persist the selection state of certain gantt items (tasks, and events) during certain workflows (expanding/collapsing a section, or increasing/decreasing the width of the app). You can view one of the workflows in the attached GIF. In this workflow, when the section is collapsed, we have to unload the track with the selected task (which destroys those nodes), and load it in at its new position (which creates new nodes without the task being selected).
We are currently solving this problem by storing the key of the selected carbon element and re-selecting it if the element with that key isn't already selected after the section collapse has occurred. We accomplish this by using query selectors to retrieve the carbon node from the DOM and performing a click event on that node if it isn't already selected. However, this causes our code to be tightly coupled to the internal structure of carbon which means we could easily break if that internal structure ever changes.
Describe the solution you'd like
The easiest solution I can come up with is to expose an attribute, isSelected, on the configuration objects carbon uses to build the dom elements. Carbon would apply it's selection styling if that attribute is set to true. Some additional processing could be done to determine if the element is even selectable based on the presence of the onClick function.
Describe alternatives you've considered
Another possible solution would be to use some kind of refCallback pattern. This would allow us to pass down a refCallback function that carbon would use to pass in the DOM reference of the node that needs re-selected. We could then perform the click event on the given ref instead of finding the node ourselves. However, this would still tie us to the internal structure of carbon because we would need some way to determine if that ref is already selected (maybe through an aria-selected attribute on the node?).
Additional context
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Our application needs to persist the selection state of certain gantt items (tasks, and events) during certain workflows (expanding/collapsing a section, or increasing/decreasing the width of the app). You can view one of the workflows in the attached GIF. In this workflow, when the section is collapsed, we have to unload the track with the selected task (which destroys those nodes), and load it in at its new position (which creates new nodes without the task being selected).
We are currently solving this problem by storing the key of the selected carbon element and re-selecting it if the element with that key isn't already selected after the section collapse has occurred. We accomplish this by using query selectors to retrieve the carbon node from the DOM and performing a click event on that node if it isn't already selected. However, this causes our code to be tightly coupled to the internal structure of carbon which means we could easily break if that internal structure ever changes.
Describe the solution you'd like
The easiest solution I can come up with is to expose an attribute, isSelected, on the configuration objects carbon uses to build the dom elements. Carbon would apply it's selection styling if that attribute is set to true. Some additional processing could be done to determine if the element is even selectable based on the presence of the onClick function.
Describe alternatives you've considered
Another possible solution would be to use some kind of refCallback pattern. This would allow us to pass down a refCallback function that carbon would use to pass in the DOM reference of the node that needs re-selected. We could then perform the click event on the given ref instead of finding the node ourselves. However, this would still tie us to the internal structure of carbon because we would need some way to determine if that ref is already selected (maybe through an aria-selected attribute on the node?).
Additional context
The text was updated successfully, but these errors were encountered: