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

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.

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

1 Like

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.

1 Like

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ā€¦ :cry:

This is far and away the most important feature missing from Figma, and would be a game changer if they could add it.

4 Likes

Definitely interested in this as well. Seems quite related to this thread, that has more support, and a rep from Figma: Fully Editable Component Instances - #52 by dfeldman

What would really help in my case would be if the inner components could be detached without detaching the whole component.

Letā€™s consider this example structure:

  • Template (component)
    • Header (frame)
    • Content (component)
    • Footer (frame)

Youā€™d just detach that ā€œContentā€ component and modify the frame as you wish, while keeping the ā€œTemplateā€ component in sync.

3 Likes

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

Ayo!

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.

7 Likes

Itā€™s hard to believe that years later, with all the developments and improvements to Figma, this CORE FEATURE still doesnā€™t exist. Is there some fundamental reason this wouldnā€™t work in Figma or are all these threads being ignored? (other threads for example: Fully Editable Component Instances - Share an idea - Figma Community Forum | Editing Variants - Share an idea - Figma Community Forum)

3 Likes

Commenting to keep this alive.

Related:

Repeater fire (Auto-Layout evolution)