Extract after you repeat

Utilities first; extract once the pattern repeats.

Adam Wathan@adamwathan
This workflow prevents premature abstraction; I design with utilities first and extract components when I start seeing repeated patterns.
Jun 8, 2017View on X ↗
Adam Wathan@adamwathan
@JeroenGerits These days I use a "utility-first" approach, and create components when I find myself repeating patterns of utilities.
Jan 23, 2017View on X ↗
Adam Wathan@adamwathan
@mindplaydk @dfkaye @tailwindcss @Killgt The pay off for me is the ability to quickly design in the browser, and the removal of pressure to create premature CSS abstractions around things that will never be reused. A traditional CSS approach forces you to name things that don't often deserve names.
Dec 8, 2017View on X ↗

Counts below are computed live from the markup each pane generates.

Add plans, then extract

Add plans. Extract once a pattern repeats.

Abstract up frontBad

        

        

      

      

        
Repeat, then extractGood

        

          

          

        

        

      

    

    
/* 1. Repeat the utilities while you design */
<div class="flex items-center justify-between rounded-lg border p-3 text-sm">Pro</div>
<div class="flex items-center justify-between rounded-lg border p-3 text-sm">Team</div>

/* 2. Third copy: extract one component */
const Plan = ({ name, price }) => (
  <div className="flex items-center justify-between rounded-lg border p-3 text-sm">
    {name} ${price}
  </div>
)

  


  

    
Why it matters, pros and cons

    

      
Why it matters
Names are guesses until the pattern repeats. Repetition shows what really varies.

      
Pros
  • No premature abstraction to unpick later
  • Design directly in the browser, no naming step
  • The extracted component fits the real variants

      
Cons
  • Copies pile up if nobody extracts
  • Early on, markup is longer than a named class
  • Needs a component layer to extract into