If you're making every possible modal a seperate component the system isn't going to scale that well. I'd only recommend that for very small projects. The answer to your question also kinda depends on if you're building a actual component library or a sketch file containing all your components. I prefer using something like BEM naming.

We are currently setting up our component library (part of the design system) in Figma. We try to make 1 main component with all the variations of the element placed as flexible as possible. From this component we make Instances and start making the variations by hiding the elements. Those variations than sometimes become part of the library depending on the overall usage.

So for example:

Main component: Input field

Placeholder text, Optional text, Label text, Clear icon, Validation/error icon, validation/error text

Instance: Default state for input field

Showing only the: Placeholder text + Label text

Btw. What's up with the text colour of the comment section input field here at DN? It's like i'm typing in the placeholder text.

Anyway hope this gives a clear idea about our workflow!

Instead of thinking as every instance of a modal as a separate component, think about a single modal component with attributes that you can modify.

A list of attributes a modal can have: - Header - Body - Footer

I'd consider the header and footer to be mostly defined where the body gives the flexibility to add whatever content necessary.

You're current approach may be too verbose. Try thinking of modals as having three parts; header, body, footer. In the body section of the modal you can have any combination of form or other page elements. While in the header you have the main title, and in the footer you have your CTA buttons. Don't account for every use case, just build a flexible template that allows you to dump any kind of information into the modal.

At Stack Overflow, we created a base modal style that had minimal styles applied by default. Then other components were placed within it as needed. Most of the time, most modals were composed of a headline, copy, maybe some inputs, and couple action buttons.

For Modals specifically, I tend to make layer styles for the modal (container) and overlay (background). Depending on if they're themed i'll typically name them something like theme/dark/modal/container or something like that.

Then I keep the components within the modal as symbols and text styles (you might have headlines and descriptions in some or just headlines in others).

I found this to work best because you get the benefits of the design system without having to "Detach from symbol" all the time.

Atomic design helps somewhat with things like this. The header bar, bottom bar (if any) and general sizing of the modal body (including scroll) are atoms and molecules. The modal frame is an organism based on these constituent component. The form you'll nest inside the modal is ALSO an organism (comprised of buttons, inputs, labels, errors, etc). Together they create a general template (or pattern). And the final piece with real elements is a page.

You can have multiple modal organisms if your app calls for that. That's OK... but question why you need two instead of one. Atomic design isn't perfect by any means (it's taxonomy is quite clumsy) but it's a common language to help talk through front-end hierarchy like this.

My team creates separate symbols for each state of a component, but only for the simple elements like text fields and buttons.

For more complex organisms, we build example symbols that we expect to break apart as soon as we place them in a new design. These example symbols are more intended to give guidance rather than being unchangeable objects.

So I use nested symbols in Sketch for the component, then I override the different parts of it to suit the context that it is in. This is pretty obvious, I know, and the next challenge that comes is when you want a 'template' of each of these contextual variations, without creating more and more symbols...

So I came across this plugin called 'Symbol State', https://github.com/ahmedmigo/Symbol-state which allows you to save the 'state', (i.e. the unique combination of overrides that you have made based on that symbol's context) and give it a name. Then when you add this symbol to an artboard, you can change its 'state' to automatically apply all of the overrides you need for that context, with one click. Saves so much time! And doesn't create more/unnecessary symbols, and allows you to use Atomic Design principles.

The plugin can be a little finicky to use sometimes, but when I've gotten it to work, it's been amazing.

I mostly use it for international translations of copy in the same component symbol. (It even saves overridden text!)

I'm not sure how active the developer of the plugin is (when I've been confused or had an issue) but the concept is still great if this inspires anyone else to create something similar, or the dev for this plugin to be more active.

I use the principle of atomic design and break down the design to little parts. The little parts will be put together as molecules and so on till i have my component. My smallest parts are objects like a circle or pill which i use to create buttons for example. Whenever i need a circle i will place that symbol color it with a layer style and move on and put other symbols together. I don‘t build states most of them are only need color adjustments i do that via layerstyles or switch symbols.

It is just more clever to break it down as little as possible instead of having multiple symbols of the same thing. It helps me keeping a organized structure.