Sass regex

I was writing some large blocks of repetitive text in SCSS. Had some colors defined, and we wanted to group them in color-ranges, like this.

So we started with with:

$green-50: #f1fdf6;
$green-100: #dcf5e7;
$green-200: #b3e6c8;
$green-300: #75d09b;
$green-400: #37b96d;
$green-500: #1aaa55;
$green-600: #168f48;
$green-700: #12753a;
$green-800: #0e5a2d;
$green-900: #0a4020;
$green-950: #072b15;

We want to remove the values so we just have a list of names

Find:        :.*$
Replace:     ,

Replace everything from the colon to the end of the line with ,

Manually wrap it in parenthesis so it looks kinda like a SASS Map:

$theme-greens: (
  $green-50,
  $green-100,
  $green-200,
  $green-300,
  $green-400,
  $green-500,
  $green-600,
  $green-700,
  $green-800,
  $green-900,
  $green-950
);

Wanted to make it look like this:

$greens: (
  "50": $green-50,
  "100": $green-100,
  "200": $green-200,
  "300": $green-300,
  "400": $green-400,
  "500": $green-500,
  "600": $green-600,
  "700": $green-700,
  "800": $green-800,
  "900": $green-900,
  "950": $green-950
);
Find:      (\$.*-(\d+))(,|$)
Replace:   "$2": $1$3

$1 is the original value (e.g. $green-100)
$2 is the number, which we wrap in quotes
$3 is either comma or end-of-line



Troubles with input type=”number”

Using type="number" on input fields is far less useful than I originally thought. We were previously using it for the form on Framer. Since they are number fields, having the number keyboard pop up on phones is something we wanted. It also prevents people typing in non-numbers, so there’s some free form validation.

Here are some of the issues we had:

  1. Scrollwheel/trackpad will cause your number to go up or down without you noticing
  2. Default value of the step attribute is not “any”. Decimal numbers will be rounded unless you specify it
  3. Things consisting of numbers are not necessarily numbers – you don’t want to accidentally increment your credit card number because of scrolling up a little

Typing numbers is not like using an abacus. People don’t enter numbers by adding one at a time. If they do (i.e. quantity fields), you are better off with explicit Add/Remove buttons, rather than the tiny tiny arrows that browser input fields give you.

There is a great writeup from Filament Group, I wanted to type a number, which runs through these problems and gives a solid solution.

Also see You Probably Don’t Need input type=”number”.

Find in Similar Files for VSCode

I want a shortcut for VSCode that lets me”Find in files”, but with the filter pre-filled to current file type. So searching from a scss file will default to searching scss files. Same for rb or js files. This might use a different shortcut to the default find in files, or use the same one but configure pre-filled file types.

Not sure how it would handle the case where you’d previously set filename filters – should it clear the filter, or only replace empty filter? Not clearing would match the default behaviour a bit better.

Optionally add multiple file types in some order, and order the results like that. So prefer files that match the current suffix (e.g. _spec.rb), then show similar file types (.rb).

I haven’t yet found an extension that does this. I’m confident it exists, but I cannot think of how to phrase a search query to find it.

In the meantime, some useful shortcuts:

  • Alt + F12 to go to definition
  • Shift + F12 to find usages
  • Alt + Click for multiple cursors (totally unrelated but cool)

Utility CSS Is Not Inline Styles

I love utility CSS. It means I write CSS once, and change it rarely. I can quickly and easily add/change pages, and can often read a chunk of markup and know what something will look like. text-right font-bold is more obvious to me than nav_item--inner.

But a common complaint is “it’s like inline styles”. This seems based purely on appearances, rather than actual function. Looking similar doesn’t mean they are the same.

People rarely ask “why is that bad?”. What is actually wrong with inline styles? Does any of that apply to functional CSS? Let’s find out!

Inline styles don’t allow media queries

This is a huge reason to not use inline styles. And a valid one. It does not apply at all to functional CSS! Utility classes in bootstrap, tailwind, and others have classes with media queries.

You can use .p-md-2 to only add padding on medium-and-larger screens. Or d-sm-noneto hide stuff on small screens.

Inline styles cannot be easily changed

For testing quick changes in devtools, or changing a style project-wide. Inline styles requires a full text find/replace. Using CSS does not. You want to be careful to not end up with .text-red { color: blue }. But this can be avoided by naming things properly in the first place. If you change your primary color, the one-line CSS change for text-primary is easier than replacing every color attribute.

Maintenance is harder

Similar to the previous point; with correct names this shouldn’t affect functional styles. There are cases where you’ll still need a find/replace (i.e. if you decide labels shouldn’t be bold). In this case component styles are simpler, as you just update the label.

Separation of Concerns is another popular-but-misguided argument against util classes. Splitting unrelated components or modules into different files is how you separate concerns. Putting related code far apart because they have different file extensions is not.

Performance blah blah

Please measure before using this as an argument. There may at some point be a performance impact. But this is not your bottleneck yet. If you are serving many MB of HTML without gzip, this may come into play. If you get to that stage you have other problems.

I think a lot of this comes from people opening devtools and seeing so much markup. But browsers don’t really mind this. They are pretty good at parsing HTML. Don’t optimize for devtools users.

Additionally, you can easily strip out unused classes with a tool like purifycss. This leaves you with a pretty minimal set of styles + markup.

References

5 Quotes About Getting Started

  1. “The secret of getting ahead is getting started.”
    – Mark Twain
  2. “To begin, begin.”
    – William Wordsworth
  3. “The journey of a thousand miles begins with a single step.”
    – Lao Tzu
  4. “What is not started today is never finished tomorrow.”
    – Johann Wolfgang von Goethe
  5. “There are only two mistakes one can make along the road to truth; not going all the way, and not starting.”
    – Buddha