Forem: Scott Wagner

TIL: Straight Borders on a Rounded Element With CSS

Scott Wagner — Sat, 19 Jun 2021 21:30:47 +0000

Hi! This is the second post in my TIL series, where I'm sharing small things that I've learned recently. With this post, I'm going to cover a method I've recently used for putting a straight border on an HTML element with rounded corners.

I was building out a "card" element for a website, and it had that typical card styling: some rounded corners, and a bit of a box shadow to create some depth. While reading through Refactoring UI: The Book I got to the "Finishing Touches" section. In that section, the book suggested adding accent borders to things for a pop of color. It looks neat, so I decided to go for it.

How do you put a border on an HTML element?

This isn't a trick question. It's usually one of the first things that a web developer will learn when they're starting to play with CSS. You use the border property if you want all the borders to be the same. Otherwise, you'll use some combination of the side-specific border properties: border-top, border-bottom, etc.

The Problem

The card element has a border-radius set on it to achieve the rounded corners we want. As a result though, the border follows the curvature of the corners. If this is desirable for you, then there's no problem. What I wanted though, was a straight line "accent" that mimicked a border.

The Solution

I ended up using pseudo-elements to achieve the desired accent effect. With absolute positioning, and hiding overflow on the card, I was able to make an accent line that didn't curve with the card's corners. There's a CodeSandbox demo below with the working solution.

Demo

This CodeSandbox has a demo of the problem and the solution.

Pros

I think the straight accent line looks nicer than the curved border.
Using the pseudo-element unlocks extra animation options if we want them (slide in, expand outward, etc.)

Cons

The solution introduces positioned elements. This may cause some layering problems depending on the elements around it. Unlikely, but possible. (See The stacking context and position)
The element with the accent line needs to have its overflow hidden. It's fine in this use case, but may not be in others.
It does require more code than using a regular border.

Conclusion

This solution ended up working out well for me. It allowed me to achieve what I believe is a more desirable look without too much more code. I realize that the cons list is longer than the pros list, but the tradeoff is worth it for me. The scarier cons about positioning and overflow only apply in specific situations that seem unlikely.

Also, I mentioned Refactoring UI: The Book earlier. I'd highly recommend it, but it is a bit on the pricey side (see if your employer has an education budget). I've found it to be a great resource for developers looking to improve their web design skills with practical examples.

TIL: DRYing Out Styles With styled-components

Scott Wagner — Tue, 04 May 2021 23:12:38 +0000

Welcome to the first post in my TIL series. My intention with this series is to share tidbits of neat things that I've learned, experimented with, or rediscovered.

This first post is going to be about extracting and reusing some common styling in React components using styled-components (a CSS-in-JS library for React), and how Typescript saved the day.

So here's the background: I'm working in a React Typescript project that uses styled-components. In this project, there was a component that had a dropdown element to it and when the dropdown expanded a chevron svg would rotate as a bit of visual indication that the dropdown was now open. I needed to add a new component that had a dropdown element with a similar svg animation.

Note: The CodeSandbox sample project isn't the actual project, but a stripped down example for this post.

How I Started

Here's the first component. The interesting bit is the svg styling in the button, particularly the transition and transform properties. They combine to create the rotation animation that responds to the styled component prop change.

// OriginalComponent.tsx
/* other components and stuff */

const DropdownTriggerButton = styled.button<DropdownTriggerButtonProps>`
  /* some button styles */
  svg {
    height: 1em;
    width: auto;
    /* LOOK HERE 👇 */
    transition: transform ease-in-out 300ms;
    ${(props) =>
      props.isOpen
        ? css`
            transform: rotate(0deg);
          `
        : css`
            transform: rotate(180deg);
          `}
  }
`;

What Next?

I needed to add a new component, so I did that.

// NewComponent.tsx
/* other components and stuff */

const Expander = styled.div<ExpanderProps>`
  svg {
    height: 1.5em;
    width: auto;
    cursor: pointer;
    /* LOOK HERE 👇 */
    transition: transform ease-in-out 200ms;
    ${(props) =>
      props.expanded
        ? css`
            transform: rotate(0deg);
          `
        : css`
            transform: rotate(180deg);
          `}
  }
`;

The Neat Part

Through the use of the css utility in styled-components, I was able to extract the common svg animation to a reusable variable for inclusion in both components. This is the DRYing (Don't Repeat Yourself) bit.

/* expandIconAnimation.tsx */
import { css } from "styled-components";

type expandIconAnimationProps = {
  expanded: boolean;
};

export const expandIconAnimation = css<expandIconAnimationProps>`
  svg {
    transition: transform ease-in-out 300ms;
    ${(props) =>
      props.expanded
        ? css`
            transform: rotate(0deg);
          `
        : css`
            transform: rotate(180deg);
          `}
  }
`;

This is neat for a couple reasons:

There's now an animation that's easy to include in new components that need it. We don't need to reinvent the wheel every time.
This promotes visual consistency across components. If the two components had the same icon animation for the same semantic reason (implemented separately), and there were differences in the timing function, or the animation duration, or even the transform, it wouldn't feel as cohesive. This can be a bad thing. If you did want to allow some style overrides for specific circumstances, you could change the expandIconAnimation variable to a function that accepted arguments for values that need to be be able to be overridden.

Updating Our Original Components

Our components after being updated to use the expandIconAnimation "partial":

const DropdownTriggerButton = styled.button<DropdownTriggerButtonProps>`
  /* some button styles */

  ${expandIconAnimation}
  svg {
    height: 1em;
    width: auto;
  }
`;

const Expander = styled.div<ExpanderProps>`
  ${expandIconAnimation}
  svg {
    height: 1.5em;
    width: auto;
    cursor: pointer;
  }
`;

We've successfully reduced the duplication and ensured a consistent rotation animation for the expand/collapse functionality. However, you may have noticed that the DropdownTriggerButton used isOpen as the prop to control the transforms, whereas the Expander used expanded, and the expandIconAnimation expects expanded. This means that the usage in DropdownTriggerButton won't work.

Luckily, Typescript catches that for us. When using expandIconAnimation in DropdownTriggerButton we get a build error that the property expanded is missing in the props type for DropdownTriggerButton, but is required by expandIconAnimation. Fortunately, it's a pretty simple fix in this scenario. We can just change the prop on DropdownTriggerButton from isOpen to expanded. The types are satisfied, and the animation works as expected. Thanks Typescript.

Takeaways

Making common styles can be a good way to reduce code duplication and promote visual consistency.
Typescript is a great tool to aid in the prevention of bugs.

The Hunger for Learning: Based on a True Story

Scott Wagner — Sun, 08 Mar 2020 02:50:04 +0000

Note: This was a blog post I originally published on my personal site back in June of 2018. I've decided to write here instead, and now some parts are wrong (particularly the last paragraph). Most of it is still relevant.

This story starts with a web developer who had a desire to learn new skills, and practice and reinforce old ones.

First, he tried to contribute to open source. It was a bit intimidating, and he didn't feel comfortable with it (may have been a small case of imposter syndrome). Next, he tried to find opportunities at work to learn new skills. This proved difficult as well, because he didn't have the freedom to choose how his work got done. Finally, a voice spoke to him, "Build a portfolio website/blog. All the cool kids are doing it. Plus, you can start building a personal brand. Score!" And that's just what he set out to do.

With an idea in hand, and a thirst for knowledge, his focus shifted from "What?" to "How?". The "How?" question was almost as tricky as the "What?" question, and itself posed a "What?" question. "What do I know, and what do I want to learn?", he asked himself. "Well, I'm pretty comfortable with React and its ecosystem. Let's start there."

The developer started like many people do in this situation, he fired up VS Code, initialized a new project, installed all of the necessary dependencies, etc. After about 30 minutes, voila, a React project shell was born. His pomodoro timer said it was time for a break, and he rested.

Upon returning to the task at hand, he began to research how others were building blog sites in React, at which point he stumbled upon Gatsby. Gatsby is a static-site generator for React which handles a lot of the boilerplate necessary to get a site up and running, and has a GraphQL data/configuration layer to make programmatic page generation easy. This revelation, while a huge time-saver in the long run, meant that he had to tear down the existing project and start over. So after deleting the "old" project, initializing a new one, and installing one or two dependencies, he was ready to go. For real this time, and quicker than before.

He read through a bunch of the tutorials on Gatsby's site, learned about all the cool things Gatsby could do, and pushed them to the back of his brain for later consumption. Now that Gatsby was handling all the tricky stuff, our developer was free to focus on what he was comfortable with, building a site with React. The components were coming along nicely, and he had a basic layout built, but he needed to make it look pretty. This meant taking a journey into a place he was less familiar with, CSS Land. He read about UX patterns, and anti-patterns, and anti-anti-patterns. How much padding this or that element needed, and what borders are okay to use. He read about media queries so that mobile users would have a nice experience too. He refreshed his memory of Font Awesome to add nice icons for social sites, and then he got to work on making the site pretty.

At this point in our story, the site was built, and looked kinda pretty, but it wasn't accessible to the world. This meant he had another question to answer, "How do I host this, and how do I get it there?" Many options were available to him: use a GitHub Pages repository, use a static web host and FTP the files there, use a VPS, but ultimately he decided to go back to the second question "What do I want to learn?" He decided that cloud hosting and provisioning was a gap in his skill set that needed addressing. To remedy this, he chose to use AWS S3 to host the site, with a plethora of other AWS services (Cloudfront, Route53, etc.) to support it. Using the AWS CLI along with the web interface, he was able to create the infrastructure needed, put files where they belonged, and show off his new site to the world.

He still wasn't satisfied. The developer had recently been to a meetup where he was introduced to the concept of infrastructure as code, using Terraform to provision AWS infrastructure. This was another opportunity to learn a new skill, and the developer seized it. He tore down his existing AWS infrastructure, re-provisioned it using Terraform, and wrote a script to automate the Gatsby build, and AWS/Terraform deploy process. The script was run, and a fully functional site was available to the world, and it was good.

The developer looked back on this project, and was relatively pleased with the results. He now had a fully functional portfolio site/blog, and a new set of skills acquired in the process. Starting with knowledge of React and a touch of CSS, he learned Gatsby, more in-depth CSS, AWS, and Terraform. Knowing that no work is ever truly complete, he continues to look for areas of improvement to this day.

My name is Scott Wagner, and I am that developer. ~~The site you are on~~ (scottwagner.io) is the site built in this story. I wanted to share my experience building this site and learning a bunch of neat stuff along the way, so I started writing, and it came out as a third person story. I'll be adding more content in the coming weeks/months on a variety of software-related topics. Stay tuned sports fans.