I agree that looking at it from the dev side is what makes sense here.
For example, comparing Figma components and React components, this issue is one of the big differences.
In React, it is common to pass “children” into a component. Child components can be both your custom components and natively supported “components” (html tags).
This is what I think is missing in Figma. You can only pass custom components using “instance swap” properties. It isn’t possible to pass Figma’s natively supported “components” (frame, group, autolayout, etc.) to a component.
How in the world is this not getting more attention? Coming from XD here where this isn’t an issue.
I ran into this problem yesterday and thought there must be something I’m doing wrong, but no. What, ultimately, is the point taking the care to create a design system when you need to detach components in order to make simple overrides?
I think the concept of not allowing overrides is actually intentional. That’s how components generally work when coding, so it seems to me that Figma wants things to line up better between dev and design teams.
Of course, since component properties can only be used for certain attributes in Figma, there is still a huge gap between dev and design.
Anyway, my point is that I also came from XD and it’s a lot simpler if you think of your components as being the same components that will be created by developers. In XD I used to create certain components solely for the sake of making the design process easier, knowing I could override it. In Figma that doesn’t work (although component variants sometimes seems similar).
Ironically though, sometimes I do create one-time use components to do some weird stuff with component swaps hack Figma into allowing customization of child components.
@Travis12 Other commenters in this thread have raised a number of really great user problems that OP’s suggestion would solve.
The problem is less about allowing overrides and more about allowing composition. As others have already described in depth, if you want to create any type of container element that has options for how it is composed (think predefined Grid / Column Templates or complex Card) you currently can’t do it inline without detaching. Creating Swap-In components separate from the actual Page Frame is a solution but can feel a little disjointed depending on your workflow.
Saying that overrides aren’t generally allowed on components in coding is objectively wrong and seemingly contradicts your previous comment re React composition (which I agree with). Can you provide some justification / examples for this statement?
This is a problem even with simple components, like a Breadcrumb. It is a perfect example, because you could find yourself in the need of have a lot of steps on a particular instance and the only way to have them without detach is to have lot of them hidden in the component.
