I had not found this problem in my search. The following situation:
I have a desktop UI that opens an overlay via a button (a drawer that slides in from the right). In this overlay is a dropdown. Each entry of this dropdown should display a different overlay.
The dropdown is a component with the following variants:
Default
Hover
Focus (i.e. with opened box where the entries are available for selection)
Selected
There are only two interactions in the main component: 1. hover and 2. onClick Focus
I now have an instance of this component in another prototype. There I place the interactions on the entries in the box that appears with Focus. However, the interactions do not work. Because in the first overlay the dropdown is set to Default. The interactions are obviously not transferred and the overlays cannot be swapped.
If I leave the dropdown in the focus state (which is not normal behavior in a prototype), the interactions are taken over and I can replace the overlay.
I have now “solved” it myself. The main component of the dropdown is located in a central file where all standard components are grouped together (for the developers). This makes sense for large projects with many different areas.
An instance of this main component is used in another file where it does not work. If I now move the main component to the file where it is used and assign the interactions for each overlay in the dropdown, it works.
However, this means that I have to create a separate main component for each new file (because it has its own area). So very often I have to use the same component but with different interactions. This is somehow not smart. Because if I have to make even the smallest visual change in a standard dropdown, I am forced to know where this component is still used and to manually adjust all other main components again.
That doesn’t really seem well thought out to me.
I’m not sure how your design system works but it seems like you’ve been using those components with premade functions to another or different function. Normally, you’ll have guidelines on how to use the components, so it should have limitations where, when, and how to use it.
In our case, when we want to reuse the same component but have different function, I would create another variant of the component, and if the function is different already, where it can’t be done with just creating a variant of the component, I would separate them completely even though visually, they almost look the same.
I have built a Material Design Select (main) component that is completely responsive, including the dropdown box. All states are defined in variants. All colors, corners, strokes, arrows, paddings, min-width, etc are clearly defined. What I would expect if I use an instance of this component in another file is that I can at least define the content, i.e. the strings, and the interaction differently for the new area.
One more note: We also use the team library in our cost plan. A member can create a new file, drag and drop my component from the library, and apply their own interactions to it. So much for the theory.