-
Notifications
You must be signed in to change notification settings - Fork 20
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
Toggle state for list items is persisted even for different elements #86
Comments
Discovered when implementing bpmn-io/bpmn-properties-panel#31 |
I think we have to things here
That's probably to the fact we don't use unique ids per element. The
That's a bit tougher. Giving we add uniqueness to each item, they will be rendered which every element selection change. Persisting the collapsed state would mean we would have to persist the state per element somewhere. I don't think we have a proper way of doing it as of now. What we could try out is to use the |
I agree with what Max described as expected behavior for sections and list items. We have to pay attention to one thing in addition: there are more properties across selections than just sections and list items. One example is the textarea (for documentation and others). If the user resizes it for one element, would it be expected to be also resized on all other elements? Maybe it was just a single reason because of a long text or script. But it could also be that someone just wants to focus on documentation and wants to have it open and large for all elements. I have no strong opinion on that yet and am open to suggestions. As fallback, we could start without persistence. |
I added a simple fix for the first part ("Toggle state of list items should not be persisted between different elements") via #89. Since the second part is more difficult, I'd tackle it separately. |
I could imagine that we start without persisting the list states. For sections I see the value but for lists I'm not sure how much value this actually brings, given the effort it takes to implement this. |
One step at a time 👍 |
I disagree with @volkergersabeck statement and am not sure if the consequences were understood. Currently, we have just wrong behavior and keep states of list items in sync that have nothing to do with each other. Why should variable 3 on one element be kept in sync with variable 3 on all other elements? This should be avoided. But I agree with doing that step by step, of course. However, it should be part of the initial scope. |
To clarify
that's the current behavior, which is a bug for sure. We can fix this by making all list items unique, which is solved by bpmn-io/bpmn-properties-panel#63 + #89. However, this will keep all items unsynced and not persisting. Therefore, when a new list item is rendered for another element, it will be closed, because it was not there before. Persisting the state is way more difficult and has to be solved individually. |
Ok, if this can be handled independent from each other, I'm fine with it. Let's (a) fix the behavior that I mentioned right now and (b) enable the persistence within a list later. |
I opened another issue to track the b) part: #90 |
Describe the Bug
Toggle state for list items is persisted even for different elements.
Steps to Reproduce
(Notice the same thing can be created with other list components, e.g., Input Parameter)
Expected Behavior
Toggle state of list items is persisted for the same element==> follow up #90Environment
Example BPMN
The text was updated successfully, but these errors were encountered: