In figma, it is currently not possible to persist certain compository styles without having to think of all the possible use cases before and putting them in there, or to provide a component just so that it can be used as a reference, a starting point. The reason for this is that once a layer is in a component, it cannot be replaced, removed, multiplied or reordered. This makes sense, but limits what a component can do.
Examples
Buttons that are capable of showing any icon.
The Icon can only be replaced by a different icon of the same size or the same parent component (icon/*). Meaning, that all icons that are available need to be thought of before. This breaks the components capabilities, because it all of a sudden needs to be aware of the icons it can display.
Text-Content
Content that consists of a variable structure of headlines, paragraphs, lists, quotes, etc. Designing a Template for a view that will receive content from, for example, a CMS is impossible as a component, because we cannot reorder or add individual layers in component instances.
Possible Solution
Let us define variable content containers in components, that can receive any other layer in an instance. This way, we can author components with variable content in mind but still retain the ability to lock certain constants.
Let us reorder layers in component instances that exist in an auto-layout context.
Being able to reorder layers within a component (perhaps within certain restrictions, such as only within designated autolayout containers) would open up a host of useful possibilities.
I have this problem too, typically when icons do not fit a square. One trick I am making is to have several options embedded with auto layout frame. Then I can show/hide the one I need without creating a separate variant of the same component. But it is very tedious to maintain and easy to break.
However I do not see how you propose these ādefine variable containerā will work. The issue right now is that at some place there is an instance with fixed width and hight (and constraints). And it is logical that it preserves its fixed size up the hierarchy.
@tank666 thanks a lot for this tip! It seems like the core here is to wrap all icons in Auto Layout frame and set as variants. My only problem with your sample file: I cannot recreate it in Figma How did you manage to create a frame of zero size (w=0,h=0)? (one that holds a text)
Icon components donāt need to be combined into variants. You need to add Auto Layout to the component with āHug contentā settings, and set the icon layer (eg vector) to āFixed widthā and āFixed heightā.
To create a frame with zero height and/or width, just write .001 in the appropriate fields.
This idea is super powerful, and goes way beyond replacing and reordering single layers. If you can make an empty variable-content frame within a component, you can componentize container designs and page frames. Maybe this conversation, and the original statement above doesnāt quite advertise its strength enough! May need to make a new thread!
I really believe that if more people had some interest in this as well, it might have gotten more than just four upvotes. Unfortunately there doesnāt seem any interest in bringing Figmaās capacities closer to basal mechanics of the web, neither from the people using it, nor from the people developing it.
If I understand what youāre saying correctly, I think this will be really powerful for creating slide presentations with figma, where you have a set of basic slide components, but want to swap out images on a per-slide basis.
The lack of interest in this amazes me, and demonstrates why thereās such a gap in communication between designers and developers. Designers arenāt defining components in the same way they are built which in my opinion leads to extra time required liaising with the designer to determine intent, something I enjoy doing but that also could be avoided.
Figma kinda half allows what I need by allowing variable text properties for things like a title, but the lack of a general variable content container seems like a huge oversight. Take a tile component as an example; the properties of my tile include title, subtitle, background colour, padding, and then ācontentā. In the example of a dashboard I might use the tile to show some text, or a pie chart, or a todo list, or a calendar widget. The base ātileā doesnāt change, itās not a variant of tile if the content is a graph vs text. Variants of the tile might include light/dark, full-width / half-width, variations on properties of ātileā not of the tileās content.
Thatās how the component would be built by a front-end dev. The component is defined in one place, our āclassā, then used in multiple places just with different content. As a FED if Iām building a dashboard I donāt make 50 different ātileā components because they have different content, I make one component that can accept variable content. The pattern of ātileā is all the things around the content, not the content itself.
This basic difference in conceptualisation between designers and devs is a huge pain point for me, and Iām very surprised it isnāt for others.
This is a frequent point of frustration for me. Working on a marketing site, Iām constantly having to detach instances to make simple one-off adjustments, like adding a disclaimer under a CTA button in a hero component. We should have an option to create component frames that can accept unlimited numbers of children, just treat them all the same (e.g., wrap them in 20px of padding and separate them with 20px gutters).
You should use Font Awesome for the icons, variants for differing content to turn on and off and auto-layout to have more control on placement, visibility and sizing of your elements. Font Awesome will give you complete control of any icon and its size, color etc. through the font panel in Figma. You can also add your own icons to Font Awesome with the paid version so you arenāt bound by using only their icons, though there is likely a nice icon ready and waiting for you for most of your needs. Font Awesome icons are extractably as SVG, PNG, PDF etc. for your developersā specific needs as well.
Iād find this very useful as well. I love how easy it is to add and move stuff around in frames with auto layout, but I was surprised to find out that this no longer works once Iām using an instance of a component. I can detach the instance, but then Iāll have to do more manual work if Iām ever adjusting the design of the component.
It should be possible to have an instance that inherits stuff like color, corner style, padding, gutter, etc, while allowing you to move and duplicate the content thatās in it.
Anyone familiar with a way to convert this to a formal feature request?
I love figma as a developer that also does design work, but (as Anni said perfectly) itās strange and confusing why this feature isnāt available.
The type of reusability that weāre discussing is the core concept of a ācomponentā in UI frameworks. Is there a reason this wouldnāt be core to the design concept as well? I want to build my mocks the way I build appsānot just because Iām a dev, but because it makes more sense to me from a design perspective, as well. Constantly having to detach container components to support children breaks all inheritance, wastes a lot of time when I need to iterate the design of one of these container components, and leads to inconsistencies in my mocks if Iāve run out of design hoursā¦
This is far and away the most important feature missing from Figma, and would be a game changer if they could add it.
There is another way around, wondering why not to take it? You make a slot component and swap it with your custom contents. Not that convenient but still a legit way to embed a custom content without breaking down instances as you describe
I donāt know if thereās a way of bumping these idea threads on here but this is literally top of the list when it comes to Figmas Config goal of bringing designers and developers closer together.
Figma is promoting component-based design, yet, the designs we hand off to development are full of detached modal and list components because they lack variability.
It would be nice to be able to create a āshellā component and add a Dynamic Content section that represents child properties.