DEV Community: Katie Langerman

Figma controller components & prepping for variants

Katie Langerman — Tue, 29 Dec 2020 00:00:00 +0000

I've seen figma variants done with and without component nesting, and at this point made a button both ways. Having gone through the process a few times sigh I feel pretty confident in using controller components to build out variants. My key takeaway: variants are like props and should be used to toggle states. You don't want to be building core UI within the variant setup, you just want to hook it all up. Either way its a tedious process– but the end result is pretty rad.

Along with using controller components, it's important to do some prep work before you start building out each variant. I'll go through how I plan for variants before touching my figma file.

Controller component

Build a base level component to act as a "controller" for each variant. This is where you could control border radius, margins/padding, size, autolayout, and ordering/layout.

It's great if you have a rough idea for reach property before you start, but as you build out variants you can easily make new controllers. I started with my default button height and sizing, then later added specific controllers for icon buttons so I could utilize autolayout. Once I was happy with my default set, I made copies of each controller and added small and large sizes. Now if I want to make my large buttons GIANT, I only have to change it in 6 places (vs 34)

Planning for variants

Step away from your figma file for a minute. Maybe do a little research by looking at other design systems. Make a list of every variant you think you might need. I'm usually a build only what you need when you need it person, but in this case its much easier to have a little plan before you start. The same goes for actually architecting a component with code– the clearer picture you have of the different props, the better.

Here's my list for Button

state [default, hover, disabled]
size [small, default, large]
variant [primary, secondary]
outlineBtn [true/false]
loading [true/false]
iconLeft [true/false]
iconRight [true/false]
iconOnly [true/false]
fullWidth [true/false]

Use whatever naming convention feels good. I'm using camelCase to make it easier to transfer this to JS.

Take that list and define every property for the first Button variant. Figma is looking for a specific format. It should look like this:

state=default, size=default, variant=primary, outlineBtn=false, loading=false, iconLeft=false, iconRight=false, iconOnly=false, fullWidth=false

Alright, back to your figma file

Make a new frame and copy your button_controller into it. Do not detach instance. It should look something like this:

Make that new frame Button a component. This is what we will base our variants off of. Style this first component while still using the controller. The only changes I really made to Button are colors and some autolayout to allow for fullWidth. Click the plus sign under Variants to enable, but instead of manually adding props (it takes forever) just copy paste the list above into the name of the first button in the layers panel.

You can do the same thing here but it will take 5x longer (Add New Property)

Onward

Now when you make a new variant, you can simply make whatever design adjustments you want and change any of the props you already created! You can continue changing props via text in the variant name or through the variants panel. Having a prop-plan ahead of time will allow you to more easily build each variant and hopefully prevent any major oversights that generally mean you have to start over.

Feel free to check out my figma file for Button as a reference or to use in your own system!

Converting Fluid Typography LESS mixin to CSS clamp()

Katie Langerman — Sat, 16 May 2020 00:00:00 +0000

I've been waiting for clamp() browser support for awhile. Finally we're at a point where it feels safe to implement with a fallback for production sites. I spent a day converting an existing fluid type scale to utilize clamp() and documented the process along the way! My goal with this conversion was to keep the compiled sizing as close to the original LESS mixin as possible. A few benefits I already see for using clamp():

The syntax is immensely easier to read and write
The clamp() definition could live in a CSS custom property, allowing for themes to utilize one type scale file without losing control over individual heading sizes
You no longer need to rely on a complicated LESS mixin

Skip ahead to my codepen for the results

out with the old

Below is the original LESS mixin I've been using for years. I've seen this several times on codepen and in various articles, so I'm not sure who to credit. I use rems and assume a base font size of 16px.

    .fluid-typography-rem(@min-screen: 320px, @max-screen: 1600px, @base-font: 16px, @min-font, @max-font, @fallbackFontSize) {
        // min font size
        font-size: @min-font;

        @media screen and (min-width: unit((@min-screen / @base-font), ~'rem')) {
            font-size: ~'@{fallbackFontSize}';
            font-size: calc(
                @min-font ~' + ' unit(@max-font - @min-font) ~' * ((100vw - '
                    unit((@min-screen / @base-font), ~'rem') ~') /' unit(
                        (@max-screen / @base-font) - (@min-screen / @base-font)
                    ) ~')'
            );
        }

        @media screen and (min-width: unit((@max-screen / @base-font), ~'rem')) {
            // max font size
            font-size: @max-font;
        }
    }

    /* the output looks like this for h1 */
    /* minimum size of 25.6px */
    h1 {
        font-size: 1.6rem;
    }

    /* starting at 320px screen width */
    @media screen and (min-width: 20rem) {
        h1 {
            font-size: 1.75rem; // fallback of 28px
            font-size: calc(1.6rem + 0.4 * ((100vw - 20rem) / 70));
        }
    }

    /* anything beyond 1440px */
    @media screen and (min-width: 90rem) {
        h1 {
            font-size: 2rem; // max of 32px
        }
    }

I've always felt that this logic is really hard to follow. Essentially we are setting a min font size, a max font size, and asking the browser to scale up and down fluidly between the two based on the viewport width in the calc function... which is also calculated based on the screen size range and base font size we have specified. I think clamp() is doing the same thing, though I haven't been able to get an exact match between the mixin and clamp. I'm okay with that.

converting to clamp()

Since I already have a fluid type scale, I can reuse those values within my clamp definitions. I still need to support ie11 and other browsers that have yet to support clamp() so I'll be using @supports with a fallback. I found this article really helpful in understanding clamp() and using it with @supports, but I'm going to elaborate on each part of clamp for my own sake (it took me a bit to fully grasp).

clamp() breakdown

Read the spec here

clamp(min, val, max)

min the smallest unit you ever want

max the biggest unit you ever want

val the ideal unit

The middle value is referred to as a preferred value. I found this part a little confusing to figure out. If the computed val is less than min : min value will be used. If the computed val is greater than max : max value will be used.

By setting the preferred value in vw units, we can leverage the "fluid" aspect of relative units. And by using clamp() we can enforce a min and max font-size to regain control over the fluidity whenever necessary (eg: not allowing the font-size to go below or above a certain point.) Having a good understanding of how vw works helps here! As a little overview:

vw = 1% of the viewport's width
3vw = 30% of the viewport's width
vw and vh are relative units, not absolute, so they scale with the width or height of the viewport (perfect for fluid typography)

example

Say this is our clamp definition: font-size: clamp(1.6rem, 4vw, 2rem);

If the viewport window is 768px, font-size: 4vw computes to 30.7167px

768 * 0.4 = 307.2 or 30.72px

If that calculated value of 30.72px was higher than the max value we defined in the clamp, the font-size would instead take the max value.

In plain english, clamp says: "Here's my min font-size, here's my max font-size, and here's my PREFERRED font-size. Please use my preferred font-size whenever possible, but don't let it exceed my max font-size or go below my min font-size."

the comparison

From what I can tell, there's a slight difference between the fluid typography mixin logic and clamp(). You can see the difference in the codepen below where I'm printing out each computed font size side by side. Now that I understand how to utilize the val part of clamp() it's quite easy to control the type scale, but trying to match it with logic in a mixin I barely understand was a struggle. Since I have further improvements I'd like to do to this particular type scale, I'm happy with the results being close enough for now!