Fully Editable Component Instances

Share an idea
1

One common problem I run into, as well as others is adding things to component instances, or changing things like auto-layout direction for a given instance.

Right now, in order to achieve for example a tree structure that can grow would be to make sure that the tree items are not in a component, and handle the nesting manually by resizing the tree nodes. This can get pretty bothersome when you also need to worry about other layout constraints, or need to change the spacing for example. Another way would be to have all of the possible tree nodes you want already pre-created in the master component, but this makes it quite annoying to manage, because you’d need to always hide and unhide each tree node and it pollutes your layer view with unnecessary items.

I think a solution to this problem, and also likely other common issues with component instance management would be to just allow instances to be modified completely without restrictions, including being able to add items into the hierarchy of an instance. These items would be clearly marked as foreign. Something along these lines:
image

This would also make it possible to compose elements together out of other components without using variants. An example could be a base button component, which has only a label, but you could add an icon to the button either by drawing directly inside the button instance, or placing an icon component inside the instance.

Then to solve the “tree problem”, one would just have an empty auto-layout “children” frame in the tree node master component, and when you create an instance of it, you can then just add any number of tree node instances into the children frame, and nest them however deep is necessary. Then if you decide to change the padding of the child nodes for example, you just change it in the tree node master and everything will automatically update.

29 Likes
2

I think this would destroy a lot of the existing concepts that Figma is built on. If you need an exception to component, detach it?

If we can’t depend on component being consistent and predictable, why have components at all?

6 Likes
3

That’s a fair criticism. On the other hand, I would argue that the alternative of detached components offers no consistency and predictability either.

What I definitely disagree on is that because a component can be modified from the outside there is no reason to have components at all. It’s already possible to change many aspects of a component instance outside the master, such as text and colors. I’d argue that this one of the most important aspects of components, if not the most. I’m only advocating to extend that to allow all modifications, rather than just select ones.

Certainly, as with all tools, people can of course misuse and create weird setups, but I don’t think that should be a reason in itself to restrict things in pro tools.

1 Like
4

I agree, but I think what the OP is thinking about is something like CSS classes in Webflow. You could save a set of layer properties as a class and apply it to different objects. For example, suppose that all your modal containers are white rectangles with 16 px rounded corners, 32 px padding, and 32 pixels of auto-layout spacing between items. Instead of creating this container as a rigid component that can nest only a specific number of items, you could create a class with said configuration and apply it to a regular frame, within which you could nest whatever amount of elements you want. Webflow users would understand.

There is already a plugin that saves style configuration, but it doesn’t include auto-layout.

So, instead of proposing fully editable components maybe we can push for something like CSS classes?

4 Likes
5

Sort of. Fully editable instances would definitely allow for the kind of setup you described though. Classes would be a new concept (which could be an interesting feature in its own right), and it wouldn’t solve the problem of arbitrarily deeply nested tree nodes for example. Ideally this should be possible with existing Figma concepts.

Imagine a scenario of a file structure like so:

  • Computer
    • Users
      • John
        • Documents
        • Photos
        • Videos
      • Bob
    • Windows

Being able to copy styles wouldn’t help much here, since the structure and the indentation would have to be done manually.

If you could edit instances you could set up a tree node component:

  • TreeNode
    • children

And then insert whatever components you needed in instances of TreeNode:

  • TreeNode
    • Computer
    • children
      • TreeNode
        • Users
        • children
          • etc…
3 Likes
6

I see. Then, if I understood you correctly, what you are proposing is to expand the override scope to include more than just style, text, and visibility overrides. I don’t see much problem with this, since you could always reset the instance (and this is something you can’t do with a detached instance)

4 Likes
7

I need this. I mainly use Figma as a visual thinking tool, so creating tree structures is really important. I view components as a transclusion tool and it often makes sense to nest components within components, but that doesn’t really work in Figma (I can only nest instances within components). The fact that making something into a component changes the properties of what’s nested within it to make it difficult to edit frustrates me to no end.

3 Likes
8

I feel there are a couple or maybe several core use cases that overlap causing someone to want to detach an instance.

  1. What can and cannot be edited by users of a component? Sometimes as a designer of the component you want to restrict certain properties, like whether the component should be able to be resized. Figma currently already makes some of these choices for you. For example you cannot change the x and y coordinates of layers inside instances. Before recently you couldn’t override rounded corners but now you can. I think if Figma offered more control to the designer as to what properties can and cannot be changed of a component as an instance, then there would be less need to detach it—and result is better consistency intended by the designer. Another way of avoiding this could be if Figma allowed global styles for corner radius and padding and not just, colours, text and effects.
  2. The second is the need to vary either the amount, or type of content inside a component. Some examples of these are things like modals, tables, layouts, cards, accordions and I’m sure there are more. If you take a table for example, some tables might have four columns others might have eight. The usual practice at the moment is either one of the following: 1) make duplicates of the columns in the main component and hide or show the columns in the instances. Or 2) detach the instance when you need a different number of columns. The trouble with both of these options is they’re not very manageable and somewhat inconvenient to work with. With the later option you loose the ability to control the look of the components after you’ve detached it. Fortunately HTML and frontend frameworks already have a solution for this. They allow you to use components inside components via slots. Technically you can already achieve this in Figma today—by using placeholder instances inside your component with auto layout. Then when you swap the instances of the placeholders you can change the content. While neat, this is cumbersome because you have to create a unique component for each placeholder (or slot) and you must edit the content of that placeholder from the main component, not in-place in the xomponent. If there was a way to define a “slot”, which objects can be placed inside after the instance is created, then this would also help in avoiding components being detached.

On another note (shameless plug), I specifically built a plugin to help with creating an maintaining tables called Table Creator. It tries to solve the problems mentioned above by providing a way to update tables which have been detached. The same technique I used in that plugin led me onto my next plugin, Layer Styles, which lets you to save layer styles. When these layer styles are applied to components and the components are detached, the layer styles can still be updated. Both of these plugins were created to help ease some of the issues mentioned above. However they can only provide as good an experience as plugins can, so native solutions to these problems would greatly enhance the user experience.

2 Likes
9

Layers Styles is pretty useful! I think we talked about it on Slack, and I suggested adding auto-layout properties to the style as well, that way you would have something like a CSS class in Figma.

10

Yes, I’ve still been thinking about your suggestion. One aspect that makes a concept like CSS classes difficult in Figma is that some properties don’t have a null state. For example corner radius is always a number from 0 and upwards, the same for padding. If Figma supported unapplied states for properties (Sketch has this) then I could see this being more feasible.

11

Hi, I have transitioned from Adobe XD, where you can fully edit a component while maintaining link with original properties. This is probably not useful for handoff to production, as it would create inconsistence along component specs, but the research, draft and discovery stages of design may benefit from this feature. When you just want to explore options, test variants without creating actual variants or just add stuff while being able to cancel all overrides and get back to original design.

2 Likes
12

image
image1920Ă—1050 245 KB

I cannot even move the position of instances in the component. I have to by force detach the instance and make the edits. That is not the idea way since it is no longer linked to the main component

1 Like
13

Maybe this might help? Git Like versioning

14

@Pavels_Amosovs how does Git versioning relate to component instance editing and overrides?

15

This? “When you just want to explore options, test variants without creating actual variants or just add stuff while being able to cancel all overrides and get back to original design.”

1 Like
16

I made a plugin to solve exactly this issue, and my aim is that you’ll never have to detach your instance ever again, it is a nice little tool to put in your toolbox before this requested feature happens (if ever)

5 Likes
17

Downloaded the plugin, thank you so much :slight_smile:

1 Like
18

@Mr.Biscuit thanks a lot. That’s 100% what I need when I’m using your Ant Design Kit for Figma. Appreciated

1 Like
19

A simple and a bit random idea/approach for this issue, which I have not thought through at all but put here for some discussion: what if any empty frame in a component can then contain editable content in an instance? Most of the time I break an instance from the master in order to add/modify one bit of it (items in a drop-down, rows in a table, number/format of tabs in a tab bar etc etc). If Figma supports a component instance “containing” other content like this, then we get a lot of flexibility without having to detach the instance…

Edit: just thought as well that having an auto layout applied to the empty frame would mean that the component is still setting up the overall component behaviour nicely too ie. padding between/around items in a drop-down list is still set at the component level, where you would want it.

5 Likes
20

what if any empty frame in a component can then contain editable content in an instance

My plugin can help you achieve exactly that, if you make the “empty frame” an instance

1 Like