Variable Content Containers for Components (Replace/Reorder Layers in components)

The Problem

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

  1. 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.
  2. Let us reorder layers in component instances that exist in an auto-layout context.
3 Likes

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.

1 Like

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.

Hi @Constantine_Zuev! You can try to do it like in my example file:

Or if you want, send a link to your file for me to see.

@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 :sweat_smile: 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.

1 Like

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!

1 Like

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.

4 Likes

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).