Skip to content
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

bug: Copying a component prototype with multiple states does not create a full copy of the prototype #4480

Open
dialmove opened this issue Apr 21, 2024 · 1 comment
Labels
bug managed on taiga This issue has been moved to our project at Taiga.io

Comments

@dialmove
Copy link

dialmove commented Apr 21, 2024

Steps To Reproduce

When copying a multiple selection of elements linked with interactions for navigating between them, the interactions should be updated to point to the copies.

This would allow having a replica of the original prototype, with the interactions navigating between the copies. The current behavior makes (some of the) copied interactions point to the original elements, and starting a flow in View mode makes you navigate back to the original elements instead of the copies.

Button prototype - 2024-04-21 16-26-08

  1. Create a prototype using a component as its main state, and several instances of the component as sub-states, like the Action Button in the example image:

See the prototype

image

  1. Set navigation interactions between the components (for example, some Open overlay / Close overlay actions)
    image

  2. Update the label of the main component. The instances are updated as they should:
    image

  3. However, if you now select all the states of the prototype and create a copy:
    image

    a. Updating the properties (label, color) of the main component in the copy does not update the label of the sub-states of the copy:
    image
    They need to be updated by hand, one by one:
    image

    b. The interaction link in the component pointing to the first instance is not updated to point to the copy, so navigation starting at the copy does not work. (Also, the Relative to field has been reset to empty in the copy).
    image
    However, the interaction link from the first instance to the second instance has been updated to point to the copy. This is the expected behavior, but it is not consistent with how the component was copied.
    image

Expected behavior

When a component and instances are selected in a multiple selection, there should be a "copy component" action that creates a deep copy detached from the original component:

  • The copy of the main component should be a separate main component
  • The copied instances should be instances of the main component
  • The interactions between the copied component and instances should always be redirected to point to the copy, not the original

Actual behavior

  • The main component is not copied as a different main component.
  • The instances are not updated to point to the copied main component, so their properties are not updated when the copied main component is updated.
  • The linked interactions are copied inconsistently; sometimes they point to their original target, sometimes they are updated to point to the copy.

Screenshots or video

Button.prototype.-.2024-04-21.16-26-08.mp4

Desktop (please complete the following information)

No response

Smartphone (please complete the following information)

No response

Environment (please complete the following information)

No response

Frontend Stack Trace

No response

Backend Stack Trace

No response

Additional context

No response

@dialmove dialmove added the bug label Apr 21, 2024
@madalenapmelo-kp
Copy link
Contributor

Hi @dialmove,

Thank you for reporting this! I created an issue on Taiga so that we can look further into this, you can find the details here: https://tree.taiga.io/project/penpot/issue/7562

@madalenapmelo-kp madalenapmelo-kp added the managed on taiga This issue has been moved to our project at Taiga.io label Apr 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug managed on taiga This issue has been moved to our project at Taiga.io
Projects
None yet
Development

No branches or pull requests

2 participants