DEV Community: Miki Stanger

Randomness and Random Numbers in CSS

Miki Stanger — Mon, 23 Jun 2025 16:04:02 +0000

Recently, I created a Missile Command kinda-clone, using HTML and CSS only. It was my first CSS-only game, and a really fun project to work on.

One of the most useful tools when creating games is randomness. Randomness can help by making every game different - different enemies and collectibles spawning in different locations, random cards for your deck, and much more. It’s also helpful for creating special effects (consider particle-based effects, where many particles move in different directions and speeds to create explosions for example) and game worlds (in my Missile Command clone, for example, you’ll have buildings with different heights at different positions every time, and each will have different windows whose light is randomly on or off).

As of the time of writing, CSS doesn’t have a random number generator.
There might be one in the future, but for now, we’ll have to create our own (kind of).

But let’s begin at the beginning:

Who am I?

I’m Miki Stanger, a freelance front-end developer and architect with 15 years experience in the industry.
I like creating code that’s easy to maintain, and to work on both UX and the underlying stuff that makes the whole project work (so, for example, both perfecting the edge cases of a table behavior, and maybe implementing the underlying table logic myself).
You can learn more about me and what I do in my about.me page.

A Note About Range Notations

My math is very rusty, but among my few memories there’s the knowledge that there’s a way to write ranges.
A range is written in as a coma-separated pair of numbers, with either square brackets, round parentheses, or one of each around them. A square bracket next to a number marks that the range includes that number. A round parenthesis next to a number means that number is excluded from that range.

So, the notation: [1, 6) means “All numbers between 1 and 6, excluding 6”. So, everything from 1 to 5.99999…

My rusty math knowledge also means that I might lack terms or not use the most efficient way to do things here. But it works.

Random Numbers 101

Programming languages usually provide you with a random number generator. In JavaScript, for example, that would be the Math.random function, which returns a number at the range of [0, 1) (that’s a number between 0 and 1, including 0 and excluding 1).

Using such a number, we can get a random number of any range, by applying some math.
For example, given a minimum number m, a maximum number n, and a random number r in the range of [0, 1), you could get to a number of the range of [m, n) with the following formula:

m + r * (n - m)

So, to get a number between 1 and 6 (excluding 6), we’ll do:

1 + Math.random() * (6 - 1)

In order to get an integer, we’ll simply round down the result, thus removing the fraction part from the number. We’ll also add 1 to the multiplier of r, to include all numbers that are in the range of [m, m+1), which will be rounded down to m:

floor(m + r * (n - m + 1))

So in order to do a standard 1d6 (that’s a six-sided dice, or [1, 6] with integers only), we’ll do:

Math.floor(1 + Math.random() * (6 - 1 + 1))
(or simply Math.floor(1 + Math.random() * 6))

Ma, They Took My Random Number Generator

Back to CSS and it’s lack of a random number generator.

Because we don’t have that in CSS, we’ll have to create one of our own.
And because there’s no way I know to do that, we’ll have to create a pseudo-random number generator.

A pseudo-random number generator is a deterministic function that produces a sequence of numbers that seem random. Optimally, this number is within a specific range, so we could work it into any range we want.

CSS comes with some math functions which you can use. Among those functions (at least those that I recognized) I found two that I thought could be useful: sin and cos. Those are the best matches I found, but they aren’t perfect.

The sin of using trigonometric functions (eh?)

The sine and cosine functions are great for us in several ways:

They accept any and all numbers. This makes our life easy when providing input.
They output a number within the range of [-1, 1]. This could easily be converted to [0, 1], by doing (1 + sin(r)) / 2, which can then be converted to any range of numbers.

However:

The output is continuous. Close values will give you close numbers. This could create patterns that don’t feel random.
The output is cyclical. sin(x) == sin(x % 360deg) (The % operator is the modulo operator. a % b returns the remainder of a / b). This, together with the previous bullet, mean that not only close numbers give you close value, but numbers whose modulo 360 results are close will also behave the same way.
The output has a non-random shape (of a wave). This means that by putting in numbers with a constant difference or a constant modulo difference, you’ll get numbers that reflect the shape of the function, which will, again, not feel random.
[0, 1] is not [0, 1). The fact that the resulting range includes the number 1, means that when using the random integers formula, there’s a tiny chance you’ll get a number you don’t want.
The function’s distribution is not linear.

For most of these issues, there are workarounds. The final result will not be perfect, but for our needs it’s good enough. Let’s move on and see how our implementation brings us to a good enough solution.

But what do we pass to the sine function?

The sine function alone doesn’t help us; we’ll need to give it an input. That input is an important part of the pseudo-random secret sauce.

The CSS tl;dr is:

—random-number: calc(var(--seed) * var(--index) * var(--index) * noise);

Let’s discuss.

calc

calc is a CSS function that allows us to combine different variables, operators etc. to do a complex calculation.

var

var is a function that allows us to retreive the value of a CSS variable/custom property

--seed

--seed is a CSS variable. It is set at the top of the project (under the :root or body selectors) and it equals to a large number. By using a large number, we prevent the numbers from being close to each other, and solve problem #1.
Changing the seed will change the results of all of the random numbers in your project.

--index

--index is another CSS variable. When there’s a series of objects (In my game that could be, for example, the stars in the sky), each of the objects gets an index. You could do it with several nth-child pseudo-selectors, but I was lazy and used the style tag:

<div class="star" style="--index: 1"></div>
<div class="star" style="--index: 2"></div>
<div class="star" style="--index: 3"></div>
...

Another --index

This handles some of our problems. A simple seed * index * noise, where the index increments by 1 between objects, would give us a series of numbers with a constant difference between them. This also translate to a very visible pattern when doing a modulo operator on them, which means that it’ll show in a sine or a cosine function. As we discussed above, this will create a not-random-feeling pattern, which is the opposite of what we want.
However, doing seed * index * index * noise, which is actually seed * index² * noise, means that the linear differences between indices will not translate to linear differences in the sine/cosine function’s output. Problems #2 and #3 - solved!

noise

noise is a hard-coded number (could be -1, 17, 8, 7003, anything). It’s different for every number generated, just so you won’t get the same number for the same seed and index. You don’t have to multiply the noise - you can add, subtract or divide it. You can also add multiple noise numbers (e.g. r * 17 - 5).
The noise is also an opportunity to introduce a unit to the number. By multiplying the random number by 39deg, 8px, 1% etc., we add that unit to the generic random number.

A Range of Possibilities

Now that we have a random number, let’s convert it to the range we’d like.
Our pseudo-random number is in the range of [-1, 1] (the possible range of outputs from both sin and cos). This is workable and easy for many ranges, but by converting the range to [0, 1] we could (almost) use the simple generic formulas from above to generate a number of any range.
In order to do that:

We add 1 to the result, bringing its range to [-1 + 1, 1 + 1] = [0, 2]
We divide the result by two, bringing its range to [0, 1]

So:

--random-number: calc((1 + sin(var(--seed) * var(--index) * var(--index) * 17)) / 2); // 17 is the noise

And if we’d like to use this number for the range [1, 10], we could use our formula from above, which will result in:

--from-one-to-ten: calc(1 + var(--random-number) * 9)

Removing the Top

There’s still one important difference between our pseudo-random numbers and the random numbers we get from Math.random - the range is not exactly the same. Instead of a number within [0, 1). we get a number within [0, 1]. This means there’s a (tiny, tiny) chance of getting the number on the top of the range, which is especially problematic if you’d like to round down the the results to get an integer.

I don’t have a perfect solution for this. All of the solutions I found will mean losing a small range of numbers. There’s one, though, where you only replace the 1 with 0, doubling the chance for the input value to be 0 but otherwise not changing the equation.

The sign CSS function returns the sign of the number. You get -1 for a negative number, +1 for a positive number, 0 for zero (and -0 for a negative zero, which is a thing in programming, but doesn’t matter to us right now).

So, by doing sign(1 - var(--random-number)), we’ll get a positive sign (the number 1) for any random number but exactly 1, for which we'll get 0.
Multiplying this with our random number will set the number to 0 if --random-number equals to one, which brings us to - [0, 1):

--capped-random-number: var(sign(1 - var(--random-number)) * var(--random-number));

Having a double chance to get one number over the others is not perfect. However, we’re talking a lot of numbers and a very small chance. For many, probably most, cases - that should be good enough, and definitely better from the chance to get a 7 in a six-sided dice roll.

Now we can use the random integers function from above. For a random integer between 1 and 10, in CSS, it'll look like this:

--random-integer: round(down, calc(1 + var(--capped-random-number) * (9 + 1));

Note that in order for round to work, you either have to round a number without a unit, or pass a 3rd argument of 1<unit> (e.g. 1px), which tells it to round by this unit. You can read more about the round CSS function here.

What About the Non-Linear Distribution?

While squaring --index might help here, and while this might be visible mainly with a large number of random numbers with the same noise, I don’t have a true solution for this. However, for everything in my game - 80 stars, 12 buildings with 15 windows each, all affected by randomness - this was, again, good enough.

A New Experience Every Time

So far, we managed to generate random numbers. But these will remain the same random numbers every time you refresh, as --seed is a constant for the whole project, --index is a constant per element and the noise is a constant for every random number formula.

If we could change the --seed for every session, though, we’ll have a different experience every time - all of the random numbers will change.

In order to do that, I piggybacked on a very important part of the game - the “Start Game” button.

The HTML part looks something like this:

<body>
    <div class="screen screen-main">
    <!-- Title screen stuff -->
        <div class="start-game-button-wrapper">
            <input class="start-game-button" type="checkbox"/>
            <input class="start-game-button" type="checkbox"/>
            <input class="start-game-button" type="checkbox"/>
            <input class="start-game-button" type="checkbox"/>
            <input class="start-game-button" type="checkbox"/>
            ...
        </div>
    </div>
    <div class="screen screen-game">
    <!-- Game stuff -->
    </div>
</body>

Then, in CSS, we do the following:

body {
    .screen-game {
        display: none;
    }

    /* If there's any checked start-game-button, start the game */
    &:has(.start-game-button:checked) {
        .screen-main {
            display: none;
        }

        .screen-game {
            display: block;
        }
    }

    /* The start game button wrapper is a grid containing all of the checkboxes, the "Start Game" label etc. */
    .start-game-button-wrapper {
        display: grid;
        grid-template-columns: repeat(1fr, 20);
        height: 80px;
        width: 200px;

        &:after {
            align-items: center;
            content: "Start";
            display: flex;
            height: 80px;
            justify-content: center;
            pointer-events: none;
            position: absolute;
            width: 300px;
        }
    }

    /* The checkbox is now a tiny square. Those squares fill the start game button wrapper. */
    .start-game-button {
        appearance: none; /* Hides the system checkbox UI */
        background-color: #3355ff;
        display: block;
        height: 10px;
        margin: 0;
        width: 15px;
    }

    /* Checking a checkbox selects two base seed numbers according to the position of the element within the parent */

    /* That's the first base seed: */

    &:has(.start-game-button:checked:nth-child(20n + 1) {
        --seed1: 4306301;
    }

    &:has(.start-game-button:checked:nth-child(20n + 2) {
        --seed1: 5612987;
    }

    ...

    &:has(.start-game-button:checked:nth-child(20n + 19) {
        --seed1: 1834393;
    }

    &:has(.start-game-button:checked:nth-child(20n) {
        --seed1: 9229177;
    }

    /* That's the second base seed: */

    &:has(.start-game-button:checked:nth-child(17n + 1) {
        --seed2: 4306301;
    }

    &:has(.start-game-button:checked:nth-child(17n + 2) {
        --seed2: 5612987;
    }

    ...

    &:has(.start-game-button:checked:nth-child(17n + 16) {
        --seed2: 1834393;
    }

    &:has(.start-game-button:checked:nth-child(17n) {
        --seed2: 9229177;
    }

    /* By having a seed generated from two base seeds like this, we add much more options by adding a relatively small amount of rules and numbers. */
    --seed: calc(var(--seed1) + var(--seed2));
}

There's some stuff going on here, so let’s explain it:

The start button is made of many tiny checkboxes (designed to look like the button’s background). When you check one of those checkboxes, in addition to hiding the main screen and showing the game screen, the CSS variables --seed1 and --seed2 are set to two different numbers, which are added together to create -seed.
This means seed has 20 * 17 = 340 different options for a seed, which means that, depending on where the player clicked on the start button, they’ll get one of 340 different sets of random numbers.

To Sum It Up

Using a pseudo-random number generator - even with a single seed - opens up interesting options. You could randomize positions, colors - anything that can accept that calc function.

I hope you found this article as interesting as it was to me to write and implement it.

If you have any question, comments, ideas or ways to improve upon these ideas - please let me know in the comments.

Tooltips! A Nice Singleton-y Way To Only Show One At A Time

Miki Stanger — Tue, 17 Jan 2023 15:56:57 +0000

Tooltips are trickier than they look; For the optimal experience, you have to handle many intricacies and edge cases.

Positioning is complex, with its many edge cases (screen edges, scrolling). Hover behavior could be more intricate, so the tooltip remains open while you hover over it, and not just its target. Appearance and disappearance should both have delays and maybe animation. AND you don't want multiple tooltips appearing together and hiding each other.

Today I'll write about this last part. Let me know if you'd like me to elaborate on the other parts :)

===

Who am I?

I'm Miki Stanger, a front-end architect and advisor. I've been to the industry for 12 years. I currently accompany companies and help with architecture, decisions, mentoring and problem-solving.

I'm always looking for cool people and projects to help with! You can read more about me and find my up-to-date contact information here: https://about.me/mikistanger/

===

Tooltips (And When To Use Them)

Tooltips are a way to show additional information about something. They are usually triggered by hovering over an element, and should show an explanation about how to read or use a part of your system.

Because it is sensitive to mouse movement and positioned next to other elements, it is best used for short texts; Large bodies of text will require the user to not touch their mouse for a while (even though some people move the mouse, click or select texts while reading or while multitasking), and might create a huge box that overshadows or even hides the parts it explains.

If your explanation is more than a few sentences long, you could use a modal instead; A modal is more persistent and allows the use of photos and videos, and are thus a better medium for larger amounts of content.

The Problem

The premise of a tooltip is supposedly basic - Hover over something and some element should appear in the right position. However, if you have several available tooltips next to each others, this could happen:

See how the tooltips hide each other? This kind of clutter not only looks messy, it could also steal the user's focus from the one tooltip they're looking for.

The Solution

When we show a tooltip, we could simply hide the other ones.
As with a lot of tooltip-related things, this is a bit more complex than it sounds, especially when working with React. There are two approaches here:

Have a single tooltip component and control it through props. You could pass the method through a store or using context, so they're available globally. This is not a bad way, except that it might unnecessarily trigger a full re-render. We'll look at a different approach that doesn't require all of those additional mechanisms.
Have multiple tooltip instances that live where they are used, and some way to turn the others off. This is also achievable with a store or a context, but there's a better way (imo) to do it - manage hiding tooltips with a singleton.

What Is A Singleton?

A singleton is a single instance of an object that's exposed to the whole system (as opposed to creating multiple objects or instances of a class).

A singleton is useful when one needs to guarantee the same options and methods will be available and persistent throughout the project. A common example for a singleton is a logging instance - a single instance of a class, with its configuration and options, which guarantee that all logging will be done with the same options and policies everywhere.

The `PreventMultipleTooltipsManager` Singleton

Our tooltip is a component that wraps another component and surrounds it with a tooltip-triggering component:

export const WithTooltip({ children }) => {
    const [isVisible, setIsVisible] = useState(false);

    const setIsVisibleToFalse = useCallback(() => {
        setIsVisible(false);
    }, [setIsVisible]);

    const setIsVisibleToTrue = useCallback(() => {
        setIsVisible(true);
    }, [setIsVisible]);

    // Rest of logic

    return <TooltipWithStylesAndStuff
        onMouseEnter={setIsVisibleToTrue} 
        onMouseLeave={setIsVisibleToFalse}
    >
        {children}
    </TooltipWithStylesAndStuff>
}

OUTSIDE of the component, we'll create a class and initiate a single instance of it - a singleton:

class PreventMultipleTooltipsManager {}

const preventMultipleTooltipsManager = new PreventMultipleTooltipsManager();

This singleton is going to hold a function that hides the currently visible tooltip (its setIsVisibleToFalse function). When a new tooltip is shown, the singleton will allow us to use the now-previous tooltip's function and replace it with the current one's. We can do both operations in a single method, as they're always going to be called together in the same order:

class PreventMultipleTooltipsManager {
    private currentHideFunc: (() => void) | null = null;

    public changeTooltip(hideFunc) {
        this.currentHideFunc?.();
        this.currentHideFunc = hideFunc;
    }
}

const preventMultipleTooltipsManager = new PreventMultipleTooltipsManager();

We're also going to add an unmount method. This method will be used in a tooltip's teardown, in case it is removed from the DOM while visible. We'll later use it in a teardown function that's the return value of a useEffect:

class PreventMultipleTooltipsManager {
    private currentHideFunc: (() => void) | null = null;

    public changeTooltip(hideFunc) {
        this.currentHideFunc?.();
        this.currentHideFunc = hideFunc;
    }

    public unmount(hideFunc) {
        if (hideFunc === this.currentHideFunc) {
            this.currentHideFunc = null;
        }
    }
}

const preventMultipleTooltipsManager = new PreventMultipleTooltipsManager();

The singleton is done. Now we can call it inside the component. We'll use its changeTooltip method in isSetVisibleToTrue, and its unmount method in a useEffect:

export const WithTooltip({ children }) => {
    const [isVisible, setIsVisible] = useState(false);

    const setIsVisibleToFalse = useCallback(() => {
        setIsVisible(false);
    }, [setIsVisible]);

    const setIsVisibleToTrue = useCallback(() => {
        preventMultipleTooltipsManager.changeTooltip(setIsVisibleToFalse);
        setIsVisible(true);
    }, [setIsVisible, setIsVisibleToFalse]);

    useEffect(() => (
        () => {
            preventMultipleTooltipsManager.unmount(setIsVisibleToFalse);
        }
    ), [setIsVisibleToFalse])

    // Rest of logic

    return <TooltipWithStylesAndStuff
        onMouseEnter={setIsVisibleToTrue} 
        onMouseLeave={setIsVisibleToFalse}
    >
        {children}
    </TooltipWithStylesAndStuff>
}

And that's it! Look at it behaving nicely:

Conclusion

Tooltips are a wonderful case of how thinking about the small details makes a difference between buggy, unfriendly component and a delightful one. Today, we dug into one of several such details, learned what a singleton is, and use this knowledge to make our tooltips better.

What do you think? How would you implement a solution to this same problem?

Enforce Git Hooks in Monorepos with Husky - But How?

Miki Stanger — Tue, 13 Dec 2022 05:45:50 +0000

How to set up Husky hooks in a monorepo? Why should you? How to use them to enforce linting policies among your team?

It's another day of work. It's a good day at work - you finish stuff! You commit your changes and push them, and go to make yourself some caffeinated beverage while you wait for the CI to do its thing.
You come back and spill your beverage in shock as you see the CI failed! If only you could've prevented it!
You remember your friend talking about git hooks, and setting up something for themselves, but their idea for sharing was to send you a file. "It's hard to enforce hooks in a monorepo", they said.

After googling a bit, though, you find a nice article that explains how to do that (this one right here!). This is how it can be done:

Very TL;DR

Husky hook -> Main monorepo script with scope -> Individual package scripts

TL;DR

Set up Husky & hooks in your main monorepo directory

Your hooks should use your monorepo tool to run a script of a specific name by running it with scope.

Each package that you'd like to have this hook work on should have a script of that same name defined in its package.json file.

What's this about?

Git hooks are scripts that run on different stages of the git workflow. They can be used for side effect, or to fail a flow.

For example, the pre-commit hook runs when you try to commit something. If it fails (exits with code 1), the commit will not be made.
This is a perfect mechanism to enforce linting and tests before a developer's code is added to the repository.

However, there's one problem with this approach - git hooks are a git mechanism - they are local, user-specific and live in your project's .git folder. How can you enforce that nice pre-commit script for all users?

Husky is a wonderful package that allows you to define hooks for your package, then install them. But...

The Monorepo Problem

In monorepos, your repository is managed outside of your individual packages.

When you try to use husky with an individual package, it just won't work.

# Works okay
> npx husky add .husky/pre-commit "<something to execute>"

# Will not add your pre-commit hook to the right directory...
> npx husky install

# ...so it'll not run when it's supposed to :(
> git commit -m "Blah"

The Solution

I'm using pnpm & pnpm workspaces for my project, so I'll use those for the code examples. They are easily interchangeable with your package manager & monorepo tools of choice.

Also, I'm demonstrating this with adding a pre-commit hook for linting. The same method should work with any other hook as well.

1. Install Husky in your main monorepo

Go to your main monorepo directory, and run:

pnpm i -D husky

2. Set a main pre-commit script

In your main monorepo's package.json file, set a pre-commit script that runs a specific script in all projects.

Most (or all) monorepo tools have an option to run scripts for all, or some of the packages, by defining a scope.

In my current project, I make sure to use npm's scope notation (not related to the previous scope I mentioned) for all package names (@product/ui, @product/api etc.). This allows me to run a script on all packages easily:

> pnpm run --filter "@product/*" myscript

// main package.json
{
  scripts: {
    "pre-commit": "pnpm run --filter \"@product/*\" pre-commit"
  }
}

At this opportunity, you could also add a prepare script that runs husky install, so every user that sets up your project will have those hooks added to their .git directory automatically:

// main package.json
{
  scripts: {
    "pre-commit": "pnpm run --filter \"@product/*\" pre-commit",
    "prepare": "husky install"
  }
}

3. Add a husky pre-commit hook:

Still in your main directory, create a husky pre-commit hook that runs your new pre-commit script:

> npx husky add .husky/pre-commit "pnpm pre-commit"

4. Add pre-commit scripts for individual packages

The last things you'll have to add are the individual pre-commit scripts for each package.
I won't get into the actual linter configuration here, but I recommend using lint-staged with whatever linters you're already using. Lint-staged will only check staged files, so you'll save time and noise by only getting errors that are relevant to your current commit.

// Individual package's package.json
{
  scripts: {
    "pre-commit": "lint-staged"
  }
}

If you don't add a pre-commit script to a project, nothing will break. This is good for many cases, but beware not to miss adding a hook script for a new project because of this.

5. And that's that!

The next time you'll commit something, all of your package's pre-commit scripts will run.

Conclusion

Git hooks & Husky are powerful tools that allow you to enforce running local scripts and keeping coding standards. By using this approach, you can enjoy the advantages of hooks and of proper script scoping (each project has its own script inside it) in a monorepo.

What do you think? Would you approach this differently?

Thanks to Yonatan Kra for his thoughtful and thorough review. Check out his blog for many good articles of an experienced developer.

The cover picture was made with DALL-E 2. I don't know a lot about fishing, so I'm trusting its judgement about how fishing rods look like.

Pure Reduce Functions - Use Aggregator As A State

Miki Stanger — Mon, 09 May 2022 13:14:09 +0000

when using Array.reduce() for complex operations, we tend to resort to using side effects (e.g. defining a let variable or an object out of scope. and modify them while iterating).

Here's an easy way to keep your reduce functions pure by using the aggregator as a state.

Consider a reduce function that's meant to sum all numbers, and add the largest number twice.
We can declare a mutable variable before, use it to track the biggest number, then add it after we're done reducing:

let biggestNum = Number.NEGATIVE_INFINITY;

const sum = arr.reduce(
  (agg, val) => {
    biggestNum = Math.max(val, biggestNum);
    return agg + val;
  },
  0,
);

const sumAndBiggest = sum + biggestNum;

Alternatively, we can encapsulate all related logic INSIDE the reduce function:

const sumAndBiggest = arr.reduce(
  (agg, val, index, sourceArr) => {
    if (index === sourceArr.length - 1) {
      return agg.sum + val + agg.biggestNum;
    }

    return {
      sum: agg.sum + val,
      biggestNum: Math.max(val, agg.biggestNum),
    };
  },
  { sum: 0, biggestNum: Number.NEGATIVE_INFINITY },
);

You'll notice two things:

We use the aggregator as a state - we include the actual sum we're reducing, and the biggest number we found so far.
We use the 3rd and 4th arguments of the reduce function - the current index and the reference to the array we're iterating over - to see if the current iteration is the last. If it is, we add the largest number and return the final sum instead of a new state.

This way adds a bit more logic to the reduce function. Why should we use it then?
Because it allows us to encapsulate all of the data needed for the reduction operation. This means:

You don't get leftover variables after the reduction is done. When someone reads the code or debugs it, they won't have to worry about those variables - biggestNum in our first example - are being used elsewhere.
Your reduce function is a pure function. Everything you need to look at happens inside the function and its arguments. This also means easier debugging.
All of the state's data is garbage-collected when it's no longer used.

Unfortunately, TypeScript only offers an option to define one return value for reduce, and doesn't allow us to differentiate between the final and intermediary return values.
This means we'll have to define the reduce function as being able to return both types, and use the as keyword to assert our aggregator's type before use:

interface IReduceState {
  sum: number,
  biggestNum: number;
}
const sumAndBiggest = arr.reduce<number | IReduceState>(
  (agg, val, index, sourceArr) => {
    const { sum, biggestNum } = agg as IReduceState
    if (index === sourceArr.length - 1) {
      return sum + val + biggestNum;
    }

    return {
      sum: sum + val,
      biggestNum: Math.max(val, biggestNum),
    };
  },
  { sum: 0, biggestNum: Number.NEGATIVE_INFINITY },
);

If you have a nicer solution to this, please let me know!

Happy coding!

Thank you, Yonatan Kra, for your kind review.

A Better Way to Manage Z-Indexes

Miki Stanger — Sat, 04 Sep 2021 17:31:49 +0000

TL;DR

Z-Indexes can get messy fast.
It's common to pick z-indexes by guessing!
There are some ways to improve this, but they only work to a point.
We can automate our z-index values generation and solve most of those issues.

The Problem with Keeping Track of Z-Indexes

Z-index is a relative CSS property. It has no unit of measurement, other than the other z-indexes in the project. Those other values are usually spread all over the project, which leads to interesting phenomenons.

How Z-Indexes can get messy?

Let's say you have a modal with the value of 999999.
We add a date picker that should be behind it but above everything else, and write 99999 so you'll have some buffer.
A year later, a colleague has to add an error popup. It should be over everything, including the modal. He sets its z-index to 9999999999. He didn't know (or forgot) about an old ad component a third colleague, long gone, added with a z-index value of 999999999999.
Now, in one of the many pages of your project, an ad will pop up that hides the error.
Another similar bug could make your date picker unusable, and another - hide your modal's "buy" button.

Using Orders of 10 to Improve Workflow

One common way to guess less is to work with powers of 10. You add a lot of zeros to something that should be on top, and less zeros to things under it:

/* This is the most toppest thing ever! */
.modal {
  z-index: 10000000;
}

/* Oh wait */
.error {
  z-index: 10000000000;
}

Another common method is to use any number of 9s:

.modal {
  z-index: 99999999;
}

.error {
  z-index: 9999999999;
}

That one is extremely popular.

As your project gets bigger, and more people are working on it, this tends to become a guessing game, where a developer writes a very big number and hopes for the best:

.old-thing {
  /* I want my thing to always be on top of other things */
  ...
  /* This should be enough to always be on top. */
  z-index: 1000000;
}

.new-thing {
/**
  This should hide everything, even old-thing.
  It should also hide things we add in the future. 
 **/
...
/* I'll write a large number to make that happen */
z-index: 10000000000;
}

/**
  Wow, I've had to guess a lot of zeros here.
  I can't change other z-indexes because I don't know what 
  I'll break, but I have to guarantee it'll always be on top.
 **/
.newer-thing {
  z-index: 1000000000;
}

"Whoops, new-thing still hides this. I'll fix that:"

.newer-thing {
  z-index: 1000000000000000;
}

We end up with different magnitudes of numbers that don't make sense except them being guesswork.
It's also harder to understand the actual order of things as you use bigger and bigger number. When comparing 1000000000000000 and 10000000000000000, you'll have to count zeros to understand who's hiding who.

Using multiples of 10, 100 or 1,000

Another common workflow. It looks like this:

.menu {
  z-index: 100;
}
.sales-notice {
  z-index: 200;
}
.error {
  z-index: 300;
}

This is an improvement over the orders of magnitude method; It's easier to tell which component will be on top of which, as we now have a single order of magnitudes and a uniform difference between the different z-indexes.
However, it still suffers from some of the problems of the previous method; When you have to add a new layer between two existing one, you'd use the gap between the two and pick their average:

/* This hides the menu and hides behind sales-notice */
.menu {
  z-index: 100;
}
.tooltip {
  z-index: 150; /* Hmm */
}
.sales-notice {
  z-index: 200;
}
.error {
  z-index: 300;
}

And just like that we lose the uniform gap advantage. When digging into the code (or a new section of it) for the first time, we can't intuitively know if the smaller difference between the menu and the tooltip means something.
Also, as the project grows, developers will still start to guess numbers. They won't be gargantuan guesses, but it'll make the meaning of each number hard to understand.

Using an Object/Map/List to Manage Your Indexes.

Here you concentrate all of your z-indexes in the same place:

const zIndexes = {
  menu: 100,
  error: 200,
}

// Use those value as CSS variables. We'll get to this soon.
injectZIndexes(app);

.menu {
  z-index: var(--z-index-menu);
}
.error {
  z-index: var(--z-index-error);
}

This is a major improvement over the previous methods; Because you manage all of your z-index values in a single place, it's easy to see their order. Just as importantly, you can understand their purpose, now that they're named.
However, we still pick middle numbers when adding middle layers, so you can't easily tell the meaning of the numeric differences once your project grows:

const zIndexes = {
  menu: 100,
  tooltip: 125,
  modal: 150,
  error: 200,
  loadingScreen: 300
}

You can keep a constant, meaningful difference, but it'll require you to rewrite all of the values greater than the new addition.

To Summerize:

All of the methods above requires you pick numbers in a meaningless way, many times with guesses. They all become messy as your codebase grows.

A Better Way

Optimally, we'll have an object with constant differences between each layer:

({
  'z-index-menu': 100,
  'z-index-modal': 200,
  'z-index-error': 300,
})

The common thing to all of those methods, and source to most of those problems, and the reason we can't have nice things, is that you have to manage the values yourself.
Since you don't really care about the exact numbers, only about their relative values, we can do much better - we can let a tiny bit of code to take care of that for us:

const makeZIndexes = (layers) =>
  layers.reduce((agg, layerName, index) => {
    const valueName = `z-index-${layerName}`;
    agg[valueName] = index * 100;

    return agg;
  }, {});
);

When we use it, we get an object with all the variables you need for z-indexes, nicely named and automatically numbered:

const zIndexes = makeZIndexes(
  ['menu', 'modal', 'error']
);

// Which will give us:
({
  'z-index-menu': 100,
  'z-index-modal': 200,
  'z-index-error': 300,
})

To add another layer, just add its name in the array:

const zIndexes = makeZIndexes(
  ['menu', 'clippy', 'modal', 'error']
);

// The result:
({
  'z-index-menu': 100,
  'z-index-clippy': 200,
  'z-index-modal': 300,
  'z-index-error': 400,
})

What Did We Do Here?

We created a small array of names. By creating named variables, we can now know where each of them is used.
The numbers are automatically generated! We don't have to guess and hope anymore. We outsourced this concern to a few lines of code.
The names array is the only code we have to change to manage our z-Indexes. This is a very simple interface, that is managed from a single place.
The top layers' values have changed! Since the z-index number only matters because of its relation to other z-indexes, and since all of those indexes are managed here in a way that keeps their order, we don't care!
Equal difference between every two adjacent layers. This is easier to read, as you don't have to figure out the reason for different differences.

How To Use Those Z-Indexes?

That depends on your style framework. This method is easy to implement in any method, CSS preprocessor or framework you'd like:
Vanilla (JS-generated CSS variables) (example):

const Z_INDEX_LAYERS = ['menu', 'clippy', 'modal', 'error'];

const zIndexes = makeZIndexes(Z_INDEX_LAYERS);

// Format as CSS variables and inject to a top HTML element
const styleString = Object.entries(zIndexes)
  .map(([name, value]) => `--${name}: ${value}; `)
  .join('')

document.querySelector('.app')
  .setAttribute("style", styleString);

.menu {
  ...
  z-index: var(--z-index-menu);
}

SASS (see it working here):

$z-layers-names: ("menu", "sales-notice", "error");
$z-layers: ();

$i: 0;
@each $layer-name in $z-layers-names {
  $i: $i + 1;
  $css-var-name: "z-index-" + $layer-name;

  $z-layers: map-merge(
    $z-layers,
    ($css-var-name: $i),
  );
}

.menu {
  ...
  z-index: map-get($z-layers, "menu");
}

The vanilla solution, by the way, is universal. Your CSS preprocessor, or CSS-in-JS framework, should support this widespread feature.
Simply run the JS part, inject to a DOM element and use CSS variables wherever you'd like.

Related Z-Index Grouping (and Why We Still Use Multiples of 100)

We can use sequential numbers, but using multiples of a larger number gives us a convenient way to manage related z-indexes.
For example, a modal close button is related to the modal, and will always move with it - even when changing the order of layers. We can easily express this in CSS:

.modal-close-button {
  ...
  z-index: calc(var(--z-index-error) + 1);
}

I implemented this as a universally usable npm library, by implementing it as an Inventar plugin.
Inventar is a tiny, powerful, framework-agnostic theme & style logic manager. Among other things, it can convert your configuration to a function that injects CSS variables into an element's style.

This is how it looks like:

import makeInventar from 'inventar';
import zIndex from 'inventar-z-index';

const Z_INDEX_LAYERS = ['menu', 'clippy', 'modal', 'error'];

const { inject } = makeInventar({
  ...
  zIndex: {
    value: 100,
    transformers: [zIndex(Z_INDEX_LAYERS)],
  },
});

Questions? Complements? Complaints? Chocolate surplus? Let's talk about it in the comments or in my LinkedIn.

Thanks to Yonatan Kra for his helpful, thorough review.

CV - Tips, Tricks, Template

Miki Stanger — Thu, 17 Dec 2020 17:27:34 +0000

This is a translation and a minor update of a note I wrote in Facebook a while ago.

Disclaimer

I have no professional experience in resume writing or any other HR subjects. I write with a combination of a "gut feeling" and the (generally positive) feedback that I've got from headhunters, recruiters and friends who read my CV and/or used its template with good results.

Another Disclaimer

I am an Israeli developer, and I write my resume to target programming jobs in the industry and culture that I know. In other professions, industries and countries, people might look on CVs in different ways and for other things.

If you encounter any errors or have different opinions, I'll be happy to hear about them in the comments :)

TL;DR

My template gets constant positive feedback from recruiters and friends. One friend claims that twice as many people are calling her back since switching to this format.

This is the current version of my template: https://tinyurl.com/2ddur9tw
This is a previous version which might be better for shorter resumes.: https://goo.gl/AlkUie

To use, open your preferred link, go to file -> make a copy... and you'll get your own editable copy.

How to Use This Template (and general CV tips and tricks)

Layout & Design

Main Header

The main header is you. Your name, to be exact :)
A secondary title is not a must, but it might add some flavor or provide a place to talk about what you're looking for. I've used "Front-End Developer and UX enthusiast who you’d totally like to hire". The reader knows that I'm looking mainly for a front-end position, and they might remember me better for the unusual "who you'd totally like to hire" ending (for which I've got good feedback).
Contact details - Name, email, phone number. You can also add icons with the relevant username (if different from your full name in the title) to LinkedIn, GitHub etc.

Primary Column, Secondary Column

The primary column includes the arguably most important part of your resume - your professional experience
Education could be moved to the primary column if you don't have a lot of professional experience and/or if it's important in your field.
If you can fit all of your info in the primary column, there's no reason for you to use the secondary one. You can just delete it.
You can change the secondary column's width. I made it thinner over time, so the primary column would fit in a single page, but the width is flexible and should be fine as long as it's clear that it's the secondary column - that is, it's not nearly as wide as the primary one.

Design (for non-designers)

Work hard on fitting everything in a single page. If you have a lot to write, consider using more concise phrasing, format the resume differently etc. However, make sure you're not omitting important stuff, and that you're not making the font size too small.
If you have a large block of text, consider splitting it to bullet points instead. This might make your description more readable and help you to save some real estate.
Make sure that texts with different roles look different. Titles, subtitles, emphasized terms etc. should look differently. In a nutshell and without learning design - try different font weights (bold vs. regular), underscores and color.
Don't change the role of font weights, colors etc. For example, if you used bold letters to emphasize, don't use it for secondary lines as well; emphasizes and secondary lines should be discernible by their design.
IF you choose to add a color - add a single, solid and readable one! If you have to make an effort to read it (e.g. you colored some of your text yellow), then the recruiter will also have to do that, and they might just put your CV aside and move to others. If you need to add another color, use a brighter or darker version of the first color, and that's it.
** Use a solid and readable font.** Your CV is not the place for "crazy" fonts, handwritten fonts etc. Again - the more effort the recruiter will have to make reading your CV, the lower the chances they'll actually get through it. Also, use a single font for all of your CV.

How to fit my CV in a single page?

Make the font smaller. Not too small, though - it should still be easily readable.
Write time ranges differently - In the newer version of my CV, I moved the time ranges so the years would be below each other. This made the dates thinner and allowed more space for the primary column.
If you're using columns, try to expand the column that takes the most space. You'll have to make sure no column gets too thin, as you don't want to have a line break every other word.
Use concise language

Writing Style

Be focused and concise, don't write irrelevant text. "Managed projects" is more readable and takes less space than "In my first six months at the company, I have managed two projects."
Focused and concise doesn't mean you shouldn't expand on responsibilities, technologies and the nature of what you did. That's important. In long sentences, ask yourself - "can I remove this word and still send the same message?"
Be honest - don't lie, don't invent false professional/education history. You'll probably be interviewing with people who are experienced interviewers, and who'll know to find out lies and "dirty tricks" in your resume.
Good grammar creates a good impression. Know your commas and stops and make sure you don't have any typos.
In many cases, humor can help you. Don't make your CV a standup session, but inserting a joke or two - especially if they're relevant to your profession - might make the reader smile and give you an edge against the other CVs. In my case, writing that I "know how to quit VIM" actually got me a job interview :)

Sections

Professional Experience

Job history order - start with your most recent job and go back in time.
Write years, not months - 2013-2015 looks better than Aug. 2013 -> Feb. 2015, and it takes less document real estate. Also, you'd usually talk about years of experience, not months.
A single job title should include the position and the company name
Keep a consistent writing style. Whatever style you pick, stick with it.
- Some such styles:
- Was responsible for project management
- Managed project
- Did project management
All of the styles I mentioned, and much more, are legitimate, but I'm a big fan of being short and to the point, with emphasis on the job's nature and your achievements.
Emphasize important words and terms (like I'm doing in this article). These include relevant technologies & buzzwords, significant projects and achievements that stand out.
You can shorten descriptions of older/less relevant jobs.

Education

Sections order - start with your most recent degree and go back in time.
The title should include the degree title and the institution where you studied.
You can add info about relevant projects, research and graduation with honors. I assume that if you've got relevant academic education, you can skip adding additional info about your high school extras and earlier degrees.
You can skip some of the details in degrees that are not relevant for the position you're applying to.
Emphasize important words and terms. These include elective studies (in highschool), graduation with honors, titles of interesting and relevant projects you did during your studies etc.

Military Service (if applicable)

In some countries that have compulsory military service, it's worth mentioning in your resume. Add your service under the professions part if it's relevant, and in its own section otherwise.

Skills

Relevant technologies, software etc.
If you've looked into, or played with, other technologies that you didn't get to use enough professionally, you can add them in a separate section. I've added them under "recent interests".
Write essential technologies and software first, then add those that are not directly relevant but could help in different sections. For example, a web developer should write about HTML, CSS, JS frameworks etc. first. In a different section, they'll mention their Photoshop experience, which is not directly related but could improve processes in some cases.

Portfolio/Examples (only available in the newer template)

Add links to a personal website, portfolios, projects you were involved in, GitHub user and anything else that could show what you can do.
If you have a long link, and it's not important to show the domain (e.g. a portfolio in a hosting website), consider using a URI shortener (e.g. tinyurl.com). This will make it easier to type, and take up less space in your CV.

Languages

If a language is your mother tongue, write that.
If it's not your mother tongue, write your reading, writing and spoken levels. If they're all the same, just write the proficiency once ("French - fluent").

Before Sending Your New CV

I highly recommend letting friends and/or people from your industry read your CV and ask for their feedback - both for their contents and for proofreading.
Both PDF and Word files are acceptable, but unless specifically asked to provide a specific format, PDF is the way to go; More people can open it, and it guarantees consistent formatting and layout.

That's it. Good luck!

The Time I Wrote a White Noise Generator To Improve Loading Times

Miki Stanger — Sat, 28 Nov 2020 13:10:00 +0000

The year was 2011. I was a young, ~~aspiring~~ software developer working in my first position in the industry.
In our app we had a web view, which we could use to display dynamic content. As mobile connections were at 2011 speeds, we had a hard limit on the size of each web view page - including all assets and code. That was usually not a problem, until one day I had to implement a design where the background was a just-slightly-grainy grey.

Grainy = white noise.

That was a problem. To understand why, let's talk about image compression.

Image Compression in a Nutshell

The images you see on the web are usually compressed; they can use many different methods in order to save space, but all of them can be categorised into two groups:

Lose some of the data (This is called lossy compression, and includes JPEG and GIF, among others)
Represent the data in a way that takes less space (this is called lossless compression, and you might best know it through the PNG format)

Lossy compression of images is commonly visible. JPEG artifacts are a known side effect of JPEG compression, and in GIFs you could recognise "rounding up" of colors, as it's limited to 256 colors. these methods could work fine for many things (e.g. photography in JPEG), but might be too much where small, clean lines/details are needed. Our white-noise-textured background fell in the second category.

If not JPEG or GIF, I tried to save the background as PNG. The file was BIG.

You Can't (Losslessly) Compress White Noise

The main method I know for lossless compression involves finding repeating patterns, replacing them with a shorter representation and keeping the replacement in a dictionary. For example, in the string aaabaaacaaad, we have the substring aaa appearing a few times.
We can shorten it by replacing it with a single character; let's call it 1. We now have a compressed string - 1b1c1d, and a dictionary - 1:aaa

When displaying the string, we use the dictionary to replace the shorter substring back to the original one, and get aaabaaacaaad again.

Different formats differ in the way they find what to replace, how many times they return the process, and what of many other optimisations they use. However, these basics are commonly used.

Back to our noisy image - white noise is, by definition, random; it is a noise generated by receiving different values in a range with equal probability. Being random, the chance for repeating patterns is very low, and lossless compression in the way we described is not very effective.

What If We Won't Load This At All?

We'll still have noise, don't worry, but we'll have to deal with it differently:

Load the page, with a background color or image, but without the noise.
Use a canvas to generate white noise
Give the canvas a very low opacity
Position it above the background
Mission accomplished!

White noise, being simply a uniform random grey value on each pixel, is very easy to generate. You iterate over the canvas' width and height, and color each pixel in a random shade of grey.

It worked! The total page size was now small enough to fit our hard size limit. However, my state of the art iPhone 4, and all other mobile devices we've tested, took a noticeable time to run this code. This wasn't a good user experience, so we've had to find another solution.

Tiles

The next plan was to use the existing generator to generate a much smaller area of white noise, and use it as a tile, a repeating background. As it has a low opacity and was used as a texture, people wouldn't easily see it repeats, and we'd have a nice, elegant background texture that is quick to generate.
This also meant that I couldn't simply use the canvas above the background, as I'd then have to fill it. Instead, I used an invisible canvas to generate the white noise tile, then used that tile, in the format of a data URI, as a background to a different element.
Thankfully, canvases have long provided this functionality natively.

This is the process we ended up with:

Load the page, with a background color or image, but without the noise.
Use an invisible canvas to generate a low-opacity white noise tile.
Get the canvas image as a data URI, and use that as a second background-image for the container element (together with the untextured image), or as a background-image over a color background.

Since the texture was very subtle, we could get away with texture repetition without it being noticed - as long as the tile wasn't very small. A few attempts to balance tile size (repetition vs. loading speed) and how visible the repetition was, and we've had a working feature :)

What Should We Take From This?

It's good to know how things work, even if you only work with them indirectly. By knowing some basics about image compression and white noise, for example, I could find the source of a non-trivial front-end problem, and solve it.
Beware of focusing too much on the things you directly need for work. Learning a bit about things outside of your daily line of work, in addition to being interesting, could help you out later.

Having Moment.js Replacements Is Not Enough

Miki Stanger — Mon, 09 Nov 2020 06:50:09 +0000

Having Moment.js Replacements Is Not Enough

A few months ago, moment.js announced the project is now in maintenance mode. They discourage you from using it in new projects, offer alternatives (including their own Luxon) and tell of a bright future with Temporal (a stage 2 proposal at the time of writing).
This is good; Moment.js has served us well, but it currently a huge library that doesn’t support tree-shaking, and isn't as performant as other libraries.
It is, however, still a dependency of many, many libraries, and it’ll take a long time for this to change (if at all - not all libraries have active development going on).
As long as you’re installing one of these packages, you’re going to have a
non-tree-shakable, 232kb (68kb if your dependency developer knew to ignore locales) hunk of code, in addition to whatever time-and-date library you’d like to be using.
In my case, I usually end up using moment.js in my larger projects, as I see no reason to include two libraries to work with dates, especially when one is this huge.

What can we do?

We CAN wait a few years, but most companies won’t appreciate this kind of timeline. Another solution is to provide moment API wrappers for the new generation of time and date libraries. I’ll explain:

Let’s say I’m publishing my own cool new time and date library. Let’s call it Chair.js, as coming with good names for libraries is hard (I spent more time finding a name for Inventar than coding its first release), and I looked at a chair just now.

Chair is light, fast and simple to work with. It sits well in its role (eh?). Its API is modern and immutable, which means that it’s different than moment.js.
I also know that developers wouldn’t use Chair if they have moment.js installed as a dependency of a dependency already, which they probably do. So I’ll make sure that these dependencies of dependencies can easily use Chair instead, by providing an additional package - chair-moment-wrapper.

chair-moment-wrapper:

Has a similar interface to that of moment.js, or at least its most used features. This interface calls Chair behind the scenes.
Has Chair as a peer dependency, so no additional copy of it is installed.
Is optimally tree-shakable.
Isn’t necessarily optimized for performance. It can get away with being at moment.js’ ballpark.

As a module, it should add itself as moment, or the user should install it with an alias (npm install —save moment@npm:chair-moment-wrapper or yarn add moment@npm:chair-moment-wrapper).
It should also replace the moment global object, if it’s added.

With this kind of wrappers for major time and date libraries, most developers could pick one knowing they wholly and completely replace moment.js - even for their dependencies. They could reap most of Chair’s size and performance benefits and, most importantly, could more quickly get to the day where they won’t have to use it.

So, developers of Luxon, date-fns, js-joda, Day.js - What do you think?

Inventar - A Framework to Keep Your Styles Tidy

Miki Stanger — Wed, 02 Sep 2020 20:24:29 +0000

Keeping your styles tidy is hard.

You end up with duplicates (or worse, almost similar values) of colors and sizes, you have to guess your z-index and hope for the best, you have to duplicate your values if you need them anywhere else, and you're not sure if the same values have the same roles and now any change you have to do there is a terrible experience...

The solutions tend to either be forgotten, to be coupled with a very opinionated styling framework (which means a major refactoring and a lot of settling over other things), or not enforceable.

CSS variables are beginning to be seen in the wild, and can solve some of these problems. On their own, however, they might just become a part of the mess.

That's where Inventar comes in.

Inventar is a tool and a system to manage all of your design variables from a single place - no matter if you're using vanilla CSS, SASS, Styled Components, Tailwind or any other styling language/system(s).

As long as you can use TypeScript, JavaScript or CSS variables, Inventar could work for you.

Let's look at a basic example:

import makeInventar from 'inventar'

const { jsInventar, cssInventar, inject } = makeInventar({
  warmGray: '#e0ded8',
  blue: '#2233aa',
})

makeInventar takes your configuration and returns three variables: jsInventar, cssInventar and inject.

jsInventar returns the configuration in JS formatting conventions. For this configuration, it'll look the same as the input:

  {
    warmGray: '#e0ded8',
    blue: '#2233aa',
  }

cssInventar returns the same configuration, but with CSS variables formatting conventions:

  {
    '--warm-gray': '#e0ded8',
    '--blue': '#2233aa',
  }

inject accepts a DOM element and adds the css variables into its style attribute. You can provide your own custom injection logic as an option, and Inventar comes with an injectRoot function that you can import and provide there.

  const wrapperElement = document.getElementsByClassName('wrapper')[0]
  inject(wrapperElement)

This means you can use the same values everywhere - CSS will read the injected variables from a wrapping object, and JS styling solution (or dynamic logic based on styles) could use the JS Inventar object as a source.

Derivatives allow you to understand what's going on better

After defining two basic colors, I'd like to use them. I could just use them in CSS as they are, but this could make it harder to understand why a variable is used in every place, and could make refactoring hard.

Instead, Inventar allows you to define variables as functions of other variables:

import makeInventar from 'inventar'
import zIndex from 'inventar-z-index'
import tinycolor from 'tinycolor2'

const { jsInventar, cssInventar, inject } = makeInventar({
  warmGray: '#e0ded8',
  blue: '#2233aa',

  backgroundColor: config => config.warmGray,
  linkColor: config => config.blue,
    linkHoverColor: config => tinyColor(config.linkColor).brighten(30).toString(),
})

backgroundColor, linkColor and linkHoverColor have functions as their values. These are derivatives - they are used to derive a value from other values.

In this case, the configuration separates from the color definitions (hex value) to their roles (background, link), which makes things more understandable and much easier to change and refactor.

linkHoverColor has additional logic, to generate a brighter version of linkColor. You can use any calculations as long as a string or a number is returned.

This is what we're getting:

{
    warmGray: '#e0ded8',
  blue: '#2233aa',
  backgroundColor: '#e0ded8',
  linkColor: '#2233aa',
  linkHoverColor: '#3b4cc3',
}

Transformers can generate, alter and remove variables

With some basics done, we'd like to use Inventar to store our z-index value from all around the object.

We CAN just add them...

{
  zIndexHeader: 100,
  zIndexModal: 200,
  zIndexErrorMessage: 300,
}

...and having them all in one place is better than the usual chaos of z-index values, but you might still find yourself changing other numbers in order to add a new layer between two existing ones. A transformer can make this a completely painless process.

Transformers are Inventar's plugins. They can alter a variable's name and value, return one or more other variables, and even remove it if needed. In the example above, we provide a single transformer to a single variable. You can provide multiple transformers as well, or apply them globally. In this example, we'll use inventar-z-index, which takes in an array of layer names, and uses it, and the initial value and variable name, to generate the variables you need instead.

import makeInventar from 'inventar'
import zIndex from 'inventar-z-index'
import tinycolor from 'tinycolor2'

const { jsInventar, cssInventar, inject } = makeInventar({
  warmGray: '#e0ded8',
  blue: '#2233aa',

  backgroundColor: config => config.warmGray,
  linkColor: config => config.blue,
    linkHoverColor: config => tinyColor(config.linkColor).brighten(10).toString(),

  zIndex: { value: 100, transformers: [zIndex(['header', 'modal', 'errorMessage'])] },
})

We'll end up with:

{
    warmGray: '#e0ded8',
  blue: '#2233aa',
  backgroundColor: '#e0ded8',
  linkColor: '#2233aa',
  zIndexHeader: 100,
  zIndexModal: 200,
  zIndexErrorMessage: 300
}

There are many potential uses for transformers - removing values in certain cases, renaming them according to values or conventions, and linting are just a few.

And there you have it - a single place to manage your style variables in a clear, tidy way.

I believe Inventar has many advantages over the existing solutions:

Your values are now separated from your styling solution

...and that's a good thing!

Having a single place where all of your colors, sizes, asset paths and other style variables allow you to use them anywhere. Vanilla CSS, SASS, JSS, Styled Components, Tailwind CSS, plain inline style (please don't)... As long as you can use CSS variables there, you can use it with Inventar. You can also use them in whatever JS logic you need.

This could also make future refactoring or styling language changes so much easier.

Your values are now in a single place

With a single source of truth, it is much easier now to enforce styles ("Hey, I see you used a color string outside of our Inventar"). Maybe you can even write a linter rule for that :)

It's much easier to name things

Instead of seeing a single color value scattered all over, you'll see names. The Inventar format allows you to separate names and roles, define which values are derived from other value, so you'll know exactly why is it there and what do you need to change.

You can easily use, and reuse, style-values-dedicated logic

Writing derivatives and transformers is very easy. Also, if someone publishes their derivative or transformer, you could use them as well, no matter what's your style language/system. Inventar being a tiny library (<2kb gzipped at the time of writing), it might find use as transformers adapter.

There's also one disadvantage:

This will only work in browsers that support css variables

CSS variables and proxies (which are used behind the scenes) are widely supported, but you won't be able to use Inventar with Internet Explorer and Opera Mini.

One thing I hope to see is tighter cooperation between developers and designers. An Inventar configuration could be written in a pairing session, working on a single file and, in many cases, being simple enough for both participants to understand. Combined with easy enforcement, I believe this will prove to be a very effective way to enforce both the designer's wishes and future changes they might decide on.

In the future, an Inventar configuration can be the single source of truth for designers as well - maybe with plugins to their software or a dedicated UI, that reads the same file and submits pull requests with changes.

Currently, the project is in a very early stage. I'll appreciate any feedback in the comments :)

Your Buttons Get Wider on Hover Because You Change Their Font Weight? Here's How to Solve This.

Miki Stanger — Fri, 19 Jul 2019 16:27:22 +0000

So, A while ago, I've had to implement a design that called for buttons that change their font-weight on hover. Now here's the problem with this:

You can try it here:

This width change is bad. It breaks the layout by pushing adjacent elements, the width change itself feels jumpy, and it all makes for an unpleasant user experience. That's probably not what the designer intended.

Let's solve this.

Set Constant Width

Setting the button's width in CSS is the best and easiest solution here... if there are only a few widths you should set.

// Button definition
.constant-width-button {
    width: 120px;
    /* Colors and shape and position and stuff */
}

// Modifier class
.constant-width-button--larger {
    width: 240px;
}

However, if you're making a reusable button that has text-dependent, dynamic width, playing around with a margin value that'll fit is a major hassle. It is also prone to breakage with different fonts. Here's how I solved it:

Duplicate the Label With CSS

The TL;DR

We use CSS to create an invisible pseudo-element that contains a bold version of the text. This element stretches the button, which now has the larger width when you don't hover over it.
We wrap the element's text with a span, and use absolute positioning to put it over its parent button.
🎉🎉🎉PROBLEM SOLVED 🎉🎉🎉

You're getting a:

Button component that just works.
Canonical, valid HTML that shows correctly with or without styling, no matter what reader you use.

Let's go through the code:

HTML

<button type="button" data-label="Hover Me Please" class="button">
  <span class="button__label">
    Hover Me Please
  </span>
</button>

There are two major additions in the HTML:

An additional span was added around the label. We need that to apply some CSS to it.
The label was duplicated into a data- attribute. This will be used in a :before pseudo-element. You could, theoretically, use that same attribute to generate an :after element and just remove the span and its content, but that would not be semantic - if the CSS won't load, the button wouldn't have any label that way.

CSS

The button itself wasn't changed much:

We added position: relative so we could use absolute positioning on the children without them overflowing.
We moved the padding values to variables, so we could reuse them and be clear about it:

:root {
  --vertical-padding: 5px;
  --horizontal-padding: 10px;
}

.button {
  padding: var(--vertical-padding) var(--horizontal-padding);
  position: relative;

  // Design
  background: green;
  border: none;
  color: #fff;
  font-size: 24px;
}

.button:hover {
  font-weight: bold;
}

The pseudo-element:

Takes its text from the data-label.
Renders it in bold weight.
Is hidden, but its box still affects its surroundings.

.button:before {
  content: attr(data-label);
  font-weight: bold;
  visibility: hidden;
}

The label:

positioned absolutely
Fits the content area of the button.

.button__label {
  position: absolute;
  top: var(--vertical-padding);
  bottom: var(--vertical-padding);
  left: var(--horizontal-padding);
  right: var(--horizontal-padding);
}

Example: Implementation in React

This logic, if you'll use it, will probably be repeated throughout your code. I used it in a component, which allowed me to take care of the label duplication and encapsulate styling.
I used CSS modules in my project, but you can use whatever styling method you prefer.
Also, note that this example assumes that the button's label is a string and not other React elements.

import React from 'react'

import styles from './MyButton.module.scss'

export default ({ children, className, ...restOfProps }) => {
  const buttonClassNames = className ? `${styles.button} ${className}` : styles.button

  return (
    <button type='button' className={buttonClassNames} data-text={children} {...restOfProps}>
      <span className={styles.button__label}>{children}</span>
    </button>
  )
}

Conclusion

Being a stickler for clean HTML and not liking to do CSS tweaks on every reuse of a component, this is the best solution I've found for this problem so far.
Please let me know if you've got better ones in the comments :)

Thanks

Amir Grozki, for coming up with the duplicate label idea and discussing what's the best implementation for it.

DEV Community: Miki Stanger

Randomness and Random Numbers in CSS

Who am I?

A Note About Range Notations

Random Numbers 101

Ma, They Took My Random Number Generator

The sin of using trigonometric functions (eh?)

But what do we pass to the sine function?

calc

var

--seed

--index

Another --index

noise

A Range of Possibilities

Removing the Top

What About the Non-Linear Distribution?

A New Experience Every Time

To Sum It Up

Tooltips! A Nice Singleton-y Way To Only Show One At A Time

Who am I?

Tooltips (And When To Use Them)

The Problem

The Solution

What Is A Singleton?

The PreventMultipleTooltipsManager Singleton

Conclusion

Enforce Git Hooks in Monorepos with Husky - But How?

Very TL;DR

TL;DR

What's this about?

The Monorepo Problem

The Solution

1. Install Husky in your main monorepo

2. Set a main pre-commit script

3. Add a husky pre-commit hook:

4. Add pre-commit scripts for individual packages

5. And that's that!

Conclusion

Pure Reduce Functions - Use Aggregator As A State

A Better Way to Manage Z-Indexes

TL;DR

The Problem with Keeping Track of Z-Indexes

How Z-Indexes can get messy?

Using Orders of 10 to Improve Workflow

Using multiples of 10, 100 or 1,000

Using an Object/Map/List to Manage Your Indexes.

To Summerize:

A Better Way

What Did We Do Here?

How To Use Those Z-Indexes?

Related Z-Index Grouping (and Why We Still Use Multiples of 100)

CV - Tips, Tricks, Template

TL;DR

How to Use This Template (and general CV tips and tricks)

Layout & Design

Main Header

Primary Column, Secondary Column

Design (for non-designers)

How to fit my CV in a single page?

Writing Style

Sections

Professional Experience

Education

Military Service (if applicable)

Skills

Portfolio/Examples (only available in the newer template)

Languages

Before Sending Your New CV

The Time I Wrote a White Noise Generator To Improve Loading Times

Image Compression in a Nutshell

You Can't (Losslessly) Compress White Noise

What If We Won't Load This At All?

Tiles

What Should We Take From This?

Having Moment.js Replacements Is Not Enough

Having Moment.js Replacements Is Not Enough

What can we do?

Inventar - A Framework to Keep Your Styles Tidy

Keeping your styles tidy is hard.

The `PreventMultipleTooltipsManager` Singleton