Pro tip: Updating a component's structure in Figma without introducing breaking changes
By the product design team
While working with Design Systems and Figma’s component libraries, we often have to introduce more structural changes that might affect other files that are using our library’s components. We, the design team at InPlayer, have found a way to introduce changes in the library’s components that won’t affect the used instances of the components in current or older files.
Updating a component from a Library
Currently, if you try to update a component in a Library, that update will be propagated in all of the files where you have used it. You can review it but when working on the file, you’d always want to update your components and use them in the latest state, so you’re usually hit the “Update” button.
If the structure of your layers, their names or the variants have been changed, then the update might cause the current overrides to also get reset to the main component.
For example, you have added the “Button” component in another more complex component and imported it in your design file where you give it some context by changing the wording. Then, later you decide to add an icon and use the “Icon + Text” button variant instead of just the “Text” one. With the library’s update, the wording of your button’s instance that you overrode to fit to your context, will be reset to the default.
Imagine that you have used this component throughout dozens even hundreds of screens across your files.. even though it’s an action that can be easily reverted (just remove the icon and the text will be set back in place), we definitely would like to introduce updates, but avoid such braking changes.
Note: I still consider that this is an issue that Figma can easily fix, but there is a way to circle around it for now.
Avoiding breaking changes in a component
By introducing a copy of the original main component or creating a new one with the same structure (layer names, etc), the update will not affect your designs.
Figma actually uses an ID for each of their main components and its instances, and if you have worked with their API, you’d probably figure it out that a new main component with the same name won’t have any connection to the old one and will be considered a new one despite using the same name.
In the project file, the instance of the old component will continue to exist without getting an “update” notification. If you try right click and “Go to main component” it will take you to the old one, even though it was excluded from the Library by using “_” or “.” before its name (you still have to publish the change).
The connection will still be there, and even if you delete it, “Go to main component” will ask you to restore the original (which we probably won’t want to do, eventually).
Still, in your designs, even though you won’t get prompted to update the Library, if you want to use the new component, you can mindfully swap the component with the new one introducing the changed component to your current file.
By surprise, if every layer had used the same naming and structure (and in this case it does, because we created a detached copy), the instance will keep the wording of your current file overrides and will not break anything in your current design file even though it will have all the necessary changes we wanted to include in the first place.
Conclusion
This approach will definitely save you some time (and *khm* nerves), without having to revert the changes or going through all your instances and fixing the wording for all existing design files. The old files will keep the old version of the component (set in stone in history) and the new ones will be easily and mindfully updated when you have the need to do so.
Let us know if this tip has helped you out! :)