DEV Community: Ayc0

@blocz/react-responsive v4

Ayc0 — Sat, 04 Jan 2025 10:59:29 +0000

@blocz/react-responsive v4 was just released with a few removals of deprecated APIs. Those are <Match> and the CSS-in-JS support. You can check out the full release details here: https://github.com/bloczjs/react-responsive/releases/tag/v4.0.0

Breaking changes

No more `<Match>`

In the v3, @blocz/react-responsive exposed a <Match> component that was reading the props only and matchMedia in any of its children. This was inspired from @reach/router v1’s <Router> component. It could be used such as (from the previous README.md):

import React from "react";
import { Match } from "@blocz/react-responsive";

const App = () => (
  <Match>
    <div only="xs">xs</div>
    <div only="sm">sm</div>
    <div only="md">md</div>
    <div only="sm lg">sm and lg</div>
    <div only="xl">xl</div>
    <div>
      <div>
        <div>
          <div only="smDown">nested smDown</div>
        </div>
      </div>
    </div>
    <div matchMedia="(min-width:768px) and (max-width:992px),(max-width:576px)">
      {"(min-width:768px) and (max-width:992px),(max-width:576px)"}
    </div>
  </Match>
);

This has 3 major issues:

It requires using React.Children to manually crawl all the children and wrap each of the ones matching either a only or matchMedia prop in a <Only> component. Problem: this API is considered as legacy in React and they even mention this: :::caution[Pitfall] Using Children is uncommon and can lead to fragile code. See common alternatives. :::
If any child was a custom component that was using one of those props, you’d get a conflict,
This is not compatible with TypeScript. The README mentioned a way to make it work with custom components. But for regular HTML elements, we had to hack around. And this hack was injected into all projects depending on @blocz/react-responsive to all HTML elements those 2 props only and matchMedia.

Also this wasn’t creating a great DX as it wouldn’t work with spread props, and similar situations.

So in this v4, we decided to fully drop this API, and instead push for either <Only> (more declarative than <Match>), or hooks like useBreakpoint() (more composable).

Removal of CSS-in-JS support

Initially, toJSON and toCSS were designed to work in a project using styletron, and within this project, we wanted to make it possible to plug styletron into @blocz/react-responsive breakpoints for responsive designs.

But this was a long time ago, and a lot of things changed since:

We stopped working on this website, so we have less direct incentive to make those 2 coincide,
In general, CSS-in-JS fell in terms of usages, and more specifically styletron,
Our support for CSS-in-JS was not great: it could be adapted to a lot of use-cases as toJSON could work for any nesting of objects, but toCSS couldn’t and we didn’t want to have to maintain a CSS parser. And in general we didn’t want to keep up with all the new features of either CSS in general or CSS-in-JS engines.

Moreover, this layer of connection between @blocz/react-responsive and CSS-in-JS can still be replicated using useBreakpoint() and custom wrapper in user-land.

All of those reasons lead to the full removal of both toJSON and toCSS.

Other changes

React 19 support

This v4 officially adds support for React 19. Even if technically it was already compatible and you can use the v3, you may have warnings with your package managers. Also we added tests for React 19.

Node version

This shouldn’t impact any users as this is mostly for our internal tooling: we upgraded the supported Node.js version to 20 & 22 (the current LTS), and dropped support for all other versions.

Bundle size

With the removal of toJSON, toCSS, and <Match>, we were able to reduce the bundle size (according to bundlephobia) from 3.8kB in the v3.0.3 to 2.7kB in the v4.0.0 minified (and from 1.7kB to 1.3kB gzipped).

This wasn’t a goal per se, but we can always appreciate reducing the impact we have on our end customers.

Intl.Segmenter(): Don't use string.split() nor string.length

Ayc0 — Tue, 25 Jul 2023 13:04:00 +0000

TL;DR
Explanation
1. Definitions
2. UTF-16
3. String.prototype.length
4. Unicode composition
5. Emoji Sequence
Intl.Segmenter
1. Browser compatibility

The other day I was playing with JS and I saw this:

'é'.length;
// 1
'é'.length;
// 2, not the same output as the line before
'é'.split('').join('|');
// 'e|́'

(Yes, all of those are valid, you can copy paste them 😅)

TL;DR

As an image is worth 1000 words:

You can use Intl.Segmenter

const seg = new Intl.Segmenter('en', { granularity: "grapheme" });

[...seg.segment('🙌🏾')].length
// 1
[...seg.segment('é')].length
// 1

Explanation

This article will talk about character vs code unit vs code point vs grapheme vs glyph.

Definitions

Character: generic term that can mean any of the other 4 terms.
Code Unit: A code unit is the smallest unit of data in UTF-16 encoding. In UTF-16, each code unit is 16 bits (2 bytes) in size. It can represent a part of a character or a complete character, depending on the character's Unicode value.
Code Point: A code point is a numerical value assigned to a specific character in the Unicode standard. It's a unique identifier for each character and is typically represented in hexadecimal. For example, the code point for the letter "A" is U+0041. In UTF-16, every code point is composed by either 1 or 2 code unit.
Grapheme: A grapheme is the smallest unit of a writing system that carries meaning and represents a single "user-perceived" character. In UTF-16, every grapheme is composed by at least 1 code point. Not all code points are part of graphemes, like the zero-width non-joiner.
Glyph: A glyph is a visual representation or image of a character. It is the actual shape or form of a character as it appears on a screen or in print. A single character can have multiple glyphs associated with it, representing different typographic variations or font styles.

You can check https://stackoverflow.com/questions/27331819/whats-the-difference-between-a-character-a-code-point-a-glyph-and-a-grapheme for more details.

UTF-16

JavaScript uses UTF-16 (and not UTF-8 as opposed as many other languages. To note: UTF-8 would also have all of those issues).

In UTF-16, characters are encoded in 16-bit chunks (code unit). For instance $ is encoded in hexadecimal into 0024 (thus its notation U+0024 or '\u0024'); and € is encoded as 20AC.

Problem: Using a 16-bit code unit can only result in 65536 possible characters, so how do we represent the other characters? UTF-16 has a system where it can use 2 code units to encode some code points. For instance 𐐷 is the code point U+10437 will be encoded as D801 DC37 (a high surrogate D801 and a low surrogate DC37).

String.prototype.length

According MDN, the length is based on code units:

The length data property of a String value contains the length of the string in UTF-16 code units.

This explains why for 🙌 (U+1F64C) or 𐐷 (U+10437), using .length doesn’t return 1 as those are encoded in 2 code units:

'𐐷'.length; // U+10437
// 2
'🙌'.length; // U+1F64C
// 2

One possible fix for this case is to use iterators. According to MDN again, iterators work on code points (they say characters, but they mean code points):

Since length counts code units instead of characters, if you want to get the number of characters, you can first split the string with its iterator, which iterates by characters

And it does work indeed…

[...'𐐷'].length // U+10437
// 1
[...'🙌'].length // U+1F64C
// 1
[...'é'].length
// 2
[...'🙌🏾']
// 2

… but not for all characters. Why?

Unicode composition

Another specificity of Unicode is that it can combines multiple code points to form a grapheme. This is called canonical equivalence
(see https://unicode.org/reports/tr15/#Canon_Compat_Equivalence).

For instance the letter "Ç" can either be the code point for this character, or the code point for "C" followed by the diacritic mark "◌̧"

We can also use normalization NFD and NFC to switch between the precomposed and decomposed forms (see https://unicode.org/reports/tr15/#Norm_Forms):

Many characters are known as canonical composites, or precomposed characters. In the D forms, they are decomposed; in the C forms, they are usually precomposed.

This explains why é’s length was either 1 or 2 in the initial example:

decomposed form → 2 code points
precomposed form → 1 code point

In JavaScript, you can use String.prototype.normalize (MDN):

'é'.length;
// 1
'é'.normalize('NFD').length;
// 2
'é'.normalize('NFD').normalize('NFC').length;
// 1

Emoji Sequence

Similarly to character compositions, emojis can be combined together with special characters (this is not an exhaustive list):

Skin tone modifiers can be used to customize the color skin of emojis
For instance "🙌🏾" is composed of "🙌" + "🏾" (Medium-Dark Skin Tone modifier)
```
[...'🙌🏾'];
// ['🙌', '🏾']
```
Zero-Width Joiner (ZWJ) can be used to merge some emojis together
For instance "😮‍💨" is composed of "😮" + "‍" (ZWJ) + "💨"
And "👩‍👩‍👧‍👦" is composed of each individual family members plus ZWJs:
```
[...'👩‍👩‍👧‍👦'];
// ['👩', '‍', '👩', '‍', '👧', '‍', '👦']
```
Variation Selectors can be used to choose a different glyph variant for a code point
For instance "ℹ️" is composed of "ℹ" + "️" (Variation Selector-16 to force the display as an emoji)

Intl.Segmenter

In 2021, the TC39 committee added to ECMAScript Intl.Segmenter:

The Intl.Segmenter object enables locale-sensitive text segmentation, enabling you to get meaningful items (graphemes, words or sentences) from a string.

Once a locale is picked, you can use .segment to generate an iterator with each grapheme of a string:

const seg = new Intl.Segmenter('en', { granularity: 'grapheme' });

for (const grapheme of seg.segment('Hélô 👩‍👩‍👧‍👦 🙌🏾')) {
    console.log(grapheme.segment);
}
// "H"
// "é"
// "l"
// "ô"
// " "
// "👩‍👩‍👧‍👦"
// " "
// "🙌🏾"

And if you want to get the number of grapheme (like .length), you can transform it to an array first:

[...seg.segment('🙌🏾')].length;
// 1

[...seg.segment('é')].length;
// 1

Browser compatibility

Sadly, at the date of the writing (July 2023) is not supported on Firefox yet – check on caniuse.com. You can track this issue if you want to follow its development.

TypeScript 5.0: new mode bundler & ESM

Ayc0 — Tue, 11 Apr 2023 14:43:00 +0000

In TypeScript 5.0, 2 new features were released:

moduleResolution: bundler
allowImportingTsExtensions

(see release note)

Let’s dive into what these allow us to solve.

Problem

Introduction

Let’s take this piece of code:

// INPUT
// foo.ts
export const foo = 'foo';

// bar.ts
import { foo } from './foo';

export const bar = `${foo} sets a new bar`;

If we want to transpile this plain JavaScript, with module: CommonJS set in our tsconfig.json, we’d get something like:

// OUTPUT
// foo.js
exports.foo = 'foo';

// bar.js
const { foo } = require('./foo');

exports.bar = `${foo} sets a new bar`;

But now you could tell me:

“Wait, I thought that JS now supports import/export? Also, isn’t this require/exports only for Node.js?”

Yes, you’re totally right! import/export are part of ESM (ECMAScript Modules). And require/exports are indeed only valid in Node.js.

Let’s try to use ESM!

ESM

You can enable this via module: es6 / es2020 / esnext / node16 in your tsconfig.json.
With the same input, we’d get:

// OUTPUT
// foo.js
export const foo = 'foo';

// bar.js
import { foo } from './foo';

export const bar = `${foo} sets a new bar`;

“Wait, what’s the catch here? This seems to be valid!”

In the ECMAScript spec, they mention that imports need to have a file extension, so import { foo } from './foo'; is not valid (see in Node.js’s doc).

Which extension should we pick?

Okay, let’s say I want to build for ESM, what extension should I write in my source code?
Let’s try a different code samples:

`.ts`

With a .ts extension:

// INPUT
// foo.ts
export const foo = 'foo';

// bar.ts
import { foo } from './foo.ts';

export const bar = `${foo} sets a new bar`;

we’d get this code in JS:

// OUTPUT
// foo.js
export const foo = 'foo';

// bar.js
import { foo } from './foo.ts';

export const bar = `${foo} sets a new bar`;

You can see that this cannot work: foo.ts doesn’t exist in the generated code as the generated file is named foo.js

`.js`

Okay, so what about with a .js file then?

// INPUT
// foo.ts
export const foo = 'foo';

// bar.ts
import { foo } from './foo.js';

export const bar = `${foo} sets a new bar`;

This would generate:

// OUTPUT
// foo.js
export const foo = 'foo';

// bar.js
import { foo } from './foo.js';

export const bar = `${foo} sets a new bar`;

This indeed works!
Hoorah! We have some working code with TypeScript & ESM 🎉
This is the official way of supporting ESM in TS files: https://www.typescriptlang.org/docs/handbook/esm-node.html.

The only issue is that we have to write down foo.js in the source TS file, which is weird 😕 (as the file doesn’t exist during dev time).

Why are extensions required in ESM?

Due to how the web works, it has to work with files that are fully pre-determined, otherwise when writing import './foo', if it implemented the same logic as node, we’d have to download: foo.js, foo.cjs, foo.mjs, foo/index.js, etc.
So for browsers, it makes more sense to treat the import as the reference.

Why isn’t the transform of the extension automatically done by TypeScript?

TypeScript never rewrites module specifiers in its JavaScript emit.

I don’t have the exact reasons why they don’t do it, but to me this would counterproductive as there are more differences between CommonJS & ESM (see TS v4.7 release note).
So enforcing the use of the extensions, is a great way to tell people that we are in ESM, and also is closer to the underlying generated JS logic.

Summary of the issue

To support ESM, we need to:

Change all imports use .js, .cjs, or .mjs -> large update,
The new imports don’t match the source files,
Tools like webpack/esbuild/deno do support .ts files in paths, so why is this an issue?

Solution: `allowImportingTsExtensions`

In TypeScript 5.0, a new option was added: allowImportingTsExtensions, which allows users to use .ts in imports!

The only requirement with it, is that we cannot emit code anymore (as this wouldn’t produce any valid JavaScript code).

So either noEmit: true needs to be set, or emitDeclarationOnly: true (as importing .ts files is allowed in .d.ts files).

We can now write the following (useful for Deno for instance):

// INPUT
// foo.ts
export const foo = 'foo';

// bar.ts
import { foo } from './foo.ts';

export const bar = `${foo} sets a new bar`;

Solution: `moduleResolution: bundler`

Enabling the .ts extension is already a bonus, but why should we write any extension at all when the code is bundled anyway by Webpack, Vite, esbuild, Parcel, rollup, swc?

If your code is bundled, there is now a new option that you can use starting with TypeScript 5.0: moduleResolution: bundler (see PR that added it).

This:

tells TypeScript that you’re code will be bundled by another tool, and thus to loosen the rules with imports (can have no extension, or use .ts extensions)
requires to use module set to es2015 or later (which enables parsing exports in package.json and other changes)

Note: Using es2015 or later will enable new rules in TS (e.g.: like disabling require), so it won’t be a no-op.

Conclusion

Module resolution in TypeScript is complex, and has evolved over the years. TypeScript 5.0 added 2 new tools to allow adapting the tool in more contexts than before. But they all come with requirements.

How does CSS work? The specificity

Ayc0 — Mon, 30 Jan 2023 16:03:00 +0000

Introduction

Let’s take this piece of code:

<style>
  .red {
    color: red;
  }
  .blue {
    color: blue;
  }
</style>
<div class="red blue">Hello world</div>

What is the color of the text? Let’s try it out:

Congratulations if you picked blue!

The reason why the color appears blue is because the selector was defined last.

Now let’s try the same thing with:

<style>
  #id {
    color: green;
  }
  .red {
    color: red;
  }
  div {
    color: blue;
  }
</style>
<div id="id" class="blue">Hello world</div>

What is the color of the text now? Let’s try it out:

It appears green. But why so?

Specificity

General rule

CSS uses multiple rules to determine how to apply styles and selectors to elements. One of them is the specificity: this is a score computed for each selector. Once all of them are computed, CSS will pick the selector with the highest specificity.

Let’s circle back to our 2nd example. If we display the specificity of each selectors, we have:

#id { color: green; } /* Specificity: (1, 0, 0) → WINS */
.red { color: red; } /* Specificity: (0, 1, 0) */
div { color: blue; } /* Specificity: (0, 0, 1) */

Which explains why the text appears green: #id has the highest specificity.

Egality

If 2 selectors have the same specificity, then the last defined will take over, which explains the situation in our 1st example:

.red { color: red; } /* Specificity: (0, 1, 0) */
.blue { color: blue; } /* Specificity: (0, 1, 0) & last one → WINS */

How to compute the specificity

General rules

The specificity is a list of 3 elements: (A, B, C), where:

A is the ID selectors (e.g., #example)
B is the class selectors (e.g., .example), attributes selectors (e.g., [type="radio"]) and pseudo-classes (e.g., :hover)
C is the type selectors (e.g., h1) and pseudo-elements (e.g., ::before)

If you want to check the differences between pseudo-classes (like :hover) and pseudo-elements (like ::before), you can check this post: https://dev.to/ayc0/css-before-vs-before-1d35.

Edge cases

* (universal selector) and :where() have no specificity (0, 0, 0).
:is(…), :not(…), and :has(…) pseudo-classes have the specificity of their most specific complex selector in their selector list argument. For instance: :not(.class) will have the same specificity as .class (aka (0, 1, 0))
:nth-child(…) and :nth-last-child(…) have the specificity of their most specific complex selector in their selector list argument plus their own specificity For instance: :nth-child(2n of .class) will have the same specificity as .class + :nth-child (aka (0, 1, 0) + (0, 1, 0) = (0, 2, 0)).

Examples

.a.b.c -> (0, 3, 0) (3 classes)
div#id -> (1, 0, 1) (1 id + 1 element)
html -> (0, 0, 1) | :root -> (0, 1, 0) (which in https://dev.to/ayc0/lightdark-mode-corrections-5e19#-raw-root-endraw-with-class-names I said that they both represent the same element with just different specificity
span > a[href$=".org"]:not([disabled]) -> (0, 2, 2) (2 elements (span & a) & 2 attributes selectors (href & not disabled)

Combining selectors

When writing CSS rules, multiple selectors can be passed:

[type="password"],
input:focus,
:root #myApp input:required {
  color: blue;
}

In those cases, it won’t create 1 giant agglomerated selector. Instead CSS will treat those as 3 distinct rules:

[type="password"] {
    color: blue;
}
input:focus {
    color: blue;
}
:root #myApp input:required {
    color: blue;
}

And then it’ll continue as normal: find the selector with the highest specificity and apply it.

If you want to know how to bump or increase the specificity of a selector, I’ll shortly release a separate article about it.

Inline style

There are 2 ways of injecting styles in HTML:

CSS style sheet that use selectors with specificity,
inline style in HTML.

Inline style doesn't use selectors, and thus cannot have specificity. So how do they fit in this system?

We can think about it as a 4th element in the list I: (I, A, B, C), that has more importance than the 3 others we’ve seen previously.

With this logic, in this example, "Hello World" should appear purple:

<style>
  #id {
    color: green;
  }
  .red {
    color: red;
  }
  div {
    color: blue;
  }
</style>
<div id="id" class="blue" style="color: RebeccaPurple">
  Hello world
</div>

`!important`

Even if !important has nothing to do with specificity, it allows styles to be applied no matter what their specificity.

Which means that in this example: even if div has the lowest specificity, its style will be applied and the text will appear blue:

<style>
  #id {
    color: green;
  }
  .red {
    color: red;
  }
  div {
    color: blue !important;
  }
</style>
<div id="id" class="blue" style="color: RebeccaPurple">
  Hello world
</div>

Another article dedicated to how !important works will be released in the future.

Tools

Parsel

When selectors become too complex, you can use Parsel, a library built by Lea Verou:

.bar + div.k1.k2 [id='baz']:nth-child(2n of .k3):not(:where(#yolo))::before" and determining its specificity (1,6,2)"/>

VSCode

Similarly, VSCode can parse selectors and display their specificity on hover.

.bar + div.k1.k2 [id='baz']:nth-child(2n):not(:where(#yolo))::before""/>

How to learn CSS with games

Ayc0 — Thu, 26 Jan 2023 10:39:06 +0000

Learning CSS isn’t the easiest. But the community helped solving that by creating a lot of interactive games online (as the best way to learn is with games).

Selectors

If you want to learn CSS selectors, you can try out CSS Diner 🍱:

Flexbox

For flexbox, you can try out Flexbox Froggy 🐸

Grid

And finally, you can learn CSS Grid with Grid Garden 🧑‍🌾

CSS :before vs ::before & :after vs ::after

Ayc0 — Tue, 17 Jan 2023 15:05:00 +0000

When reading CSS code, we sometimes see code using :before and other times with ::before (same for ::after).

Is there a difference between the 2 notations? Is one correct?

A bit of history

In CSS2, the syntax used at the time was :before. This was confusing because CSS also had selectors like :hover, but they both had different semantic meanings.

So in Selectors Level 3, they decided to change the syntax for :before to ::before (and for legacy reasons, we can still use :before, but it is now deprecated).
The : notation isn’t deprecated as a whole, instead the old syntax was split into two:

: now represents pseudo-classes (and is still valid for :hover for instance),
:: represents pseudo-elements (and should be used for ::before).

`:pseudo-class`

Pseudo-classes represent variations of a state of an element.
When the condition is satisfied, the whole element is selected.

A CSS pseudo-class is a keyword added to a selector that specifies a special state of the selected element(s).

Example

:hover matches an element on hover
:not(p) matches an element if it's not a p
:last-of-type matches an element that is the last of its siblings, and also matches a certain type selector.

See the full list in MDN

`::pseudo-element`

On the other hand, pseudo-elements are parts of the original element. They represent fake HTML nodes within the selected element.

A CSS pseudo-element is a keyword added to a selector that lets you style a specific part of the selected element(s).

Example

::before corresponds to a slot just before this element,
::first-line selects the first line in the current element,
::first-letter retrieves the very first letter of the element.

See the full list in MDN

Light/dark mode: Corrections

Ayc0 — Mon, 16 Jan 2023 14:44:27 +0000

In this post, I want to fix some mistakes I made in other posts, and also include new elements I discovered on this topic since I wrote them.

When this will be released, all other related posts will also be edited to avoid mentioning those errors. I wanted to reference all of them for posterity.

CSS color scheme

Light/dark mode: the lazy way

Ayc0 ・ May 29 '21

#webdev #css

In this post, I only mentioned the meta tag with the name color-scheme:

<meta name="color-scheme" content="light dark" />

But I forgot to mention that this can also be set in the CSS (see MDN):

:root {
  color-scheme: light dark;
}

I also wrote:

Note: this will work on both Chrome and Safari, but not Firefox

This has been fixed in Firefox 96 🎉 (see caniuse).

Native system colors

Light/dark mode: the lazy way

Ayc0 ・ May 29 '21

#webdev #css

In this post, I only mentioned the use of color-scheme. But there is also another powerful tool available to us: native system themed colors.

In CSS, you can say that a color should follow the system color for multiple semantic elements, like LinkText, or Canvas (background color):

The best is that those colors will have automated variants in dark mode (which is why they should have been mentioned in the “Lazy way” post).

For the whole list of system colors, and their semantic meaning, you can out the MDN page.

`:root` with class names

Light/dark mode: user input

Ayc0 ・ May 30 '21

#webdev #css #javascript

In this post, I wrote:

And as we are using classnames, we cannot use :root as before.

This is wrong 😕. When we read its MDN page, it says:

The :root CSS pseudo-class matches the root element of a tree representing the document. In HTML, :root represents the <html> element and is identical to the selector html, except that its specificity is higher.

After some tests, I can confirm that the following works fine:

:root.dark-mode {
  /* Works great! */
}
/* Equivalent to html but with a greater specificity */
html.dark-mode {
  /* Works great! */
}

:root has specificity of (0, 1, 0), and html has a specificity of (0, 0, 1).

Using data attributes instead of class names

Light/dark mode: user input

Ayc0 ・ May 30 '21

#webdev #css #javascript

In this post, I mentioned that we were using 2 classes .light and .dark. And that we were using this function to control those classes:

const colorScheme = document.querySelector('meta[name="color-scheme"]');
function applyTheme(theme) {
  document.body.className = theme;
  colorScheme.content = theme;
}

The issue with it, is that it overrides all classes set on the body. This is fine for this post, as we don’t have any other classes, but it may not be in your own application.

A more realistic function would be something like:

const colorScheme = document.querySelector('meta[name="color-scheme"]');
function applyTheme(theme) {
  document.body.classList.remove('light');
  document.body.classList.remove('dark');
  document.body.classList.add(theme);
  colorScheme.content = theme;
}

You can see that it's a bit tedious to have to remove all classes, especially if you start to add more themes, like low/high contrast, etc.

A better solution would be to use data attributes, to which we can add the correction we did for the color-scheme, and for the root :root:

:root[data-theme="light"] {
  color-scheme: light;
  --text: black;
  --background: white;
}
:root[data-theme="dark"] {
  color-scheme: dark;
  --text: white;
  --background: black;
}

body {
  color: var(--text);
  background: var(--background);
}

And to set it:

function applyTheme(theme) {
  document.documentElement.dataset.theme = theme;
}

(document.documentElement is the <html> node, see on MDN)

Real time system mode

Light/dark mode: system mode + user preferences

Ayc0 ・ May 31 '21

#webdev #css #javascript

In this post, I explained how to use a custom picker and how to use a system mode.

I forgot to say that this system mode won’t follow the current theme users have on their machine. Instead it just computes this theme when the mode is picked.

This mechanism is more complicated and can be explained in its own post. But in the meantime, the React implementation includes this feature:

Light/dark mode: React implementation

Ayc0 ・ Jun 24 '21

#webdev #css #javascript #react

Proper cross-fade in CSS

Ayc0 — Thu, 06 Oct 2022 14:40:01 +0000

In https://www.youtube.com/watch?v=PYSOnC2CrD8, @surma and @jakearchibald talked about what a proper crossfade is, why it is complicated to do with the current technologies. And at the end of the video, they mentioned that they just proposed this to the CSS working group.

What is a proper cross fade?

If we want to transition from a text A to a text B, the easiest is to vary the opacity from 1 to 0 on A, and from 0 to 1 on B.

The main issue with this method is that, for instance, during the middle of the animation, both will have a 50% opacity. Due to how CSS composes layers, we'll still have a color with 75% opacity. But in cross fade, the opacity should always be 100% as we are animating from the start to the end, without any notion of "this is on top of the other".

Here you can see the difference between improper and proper cross fade:

Incorrect 75% opacity	Fixed version

How to achieve this

The way to do it is to add mix-blend-mode: plus-lighter on the second text, so that CSS knows how to blend this layer with the other ones.

In addition to setting the mix-blend-mode, we should add isolation: isolate on the container so that CSS knows that the composition operation should only be computed within this element, and that we shouldn't also apply it with the full background.

Here is the MDN article on mix-blend-mode: https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode.

TypeScript 4.9: satisfies operator

Ayc0 — Sun, 25 Sep 2022 13:44:45 +0000

In their v4.9, the TypeScript team is releasing a new operator: satisfies (see blog post https://devblogs.microsoft.com/typescript/announcing-typescript-4-9-beta/#the-satisfies-operator).

Purpose

The purpose of satisfies is to enforce a constraint on a variable, without changing its type.

For instance, you want to say that a color is "either a string, or a RGB tuple", which would give something like that:

type RGB = readonly [red: number, green: number, blue: number];
type Color = { value: RGB | string };

const myColor: Color = { value 'red' };

But now, we don't know whether myColor.value is a string or a tuple. So we cannot do something like myColor.value.toUpperCase() (even if it's actually a string).

In TS 4.9, it'll be possible to do this (TypeScript Playground):

type RGB = readonly [red: number, green: number, blue: number];
type Color = { value: RGB | string };

const myColor = { value: 'red' } satisfies Color; // works
const myIncorrectColor = { value: 100 } satisfies Color; // throws error

myColor.value.toUpperCase(); // valid operation as myColor is a string

Combining `as const` and satisfies

As expected, you combine as const and satisfies (TypeScript Playground).

type RGB = readonly [red: number, green: number, blue: number];
type Color = RGB | string;

const palette = {
    red: [255, 0, 0],
    green: "#00ff00",
    blue: [1,2,3],
} satisfies Record<string, Color>;

console.log(palette.green);
//                   ^? green is string


const constantPalette = {
    red: [255, 0, 0],
    green: "#00ff00",
    blue: [1,2,3],
} as const satisfies Record<string, Color>;

console.log(constantPalette.green);
//                          ^? green is "#00ff00"

Note: the order matters. While as const satisfies <type> works, the opposite isn't true: satisfies <type> as const will throw a TS error (TypeScript Playground):

type RGB = readonly [red: number, green: number, blue: number];
type Color = RGB | string;

const invalidPalette = {
    red: [255, 0, 0],
    green: "#00ff00",
    blue: [1,2,3],
} satisfies Record<string, string | RGB> as const; // throws an error

CRA vs Parcel

Ayc0 — Mon, 05 Sep 2022 23:03:26 +0000

When working a new React project, there are a lot of frameworks / bundlers that we can choose:

create-react-app,
NextJS,
Parcel,
Vite,
astro
and many others.

Here I only want to focus on comparable tools: I'll only look into frameworks to build a React single page app.

As I haven't used Vite that much, I'll only compare create-react-app and Parcel.

CRA

Create React App is one of the first tools released to manage a React SPA. It's maintained by Facebook and the open source community.

Pros

It comes with a long of tools out of the box:

a seamless webpack & babel config,
a test runner,
an ESLint integration (integrated with an overlay),
TypeScript / Flow,
Fast Refresh,
CSS modules / SASS,
web vitals,
and many other good things out of the box.

It's also the default template proposed by Code Sandbox when starting a new React Project.

Cons

The first drawback is related to its primary advantage: it provides out of the box configuration for most tools. But as soon as you want to have a little customisation, CRA won't be nice to you:

If you want to customize the webpack configuration, you either need to eject, or to work against the package (with yarn patch, forking react-scripts, or using CRACO which is the easiest). But none of them are officially maintained by the CRA team.
You cannot have a version of ESLint or babel locally that differs from react-scripts' version, otherwise the build will crash.
You cannot have any ESLint error / warning, otherwise the build will crash.
Adding new loaders can be tricky.

I also noticed over the years a few issues with particular versions of Node, or yarn.

Parcel

Parcel is a zero configuration build tool. It comes out of the box with a lot of resolvers, plus it proposes a large set of plugins.

Pros

Just like CRA, Parcel comes out of the box with:

no config (or almost no config),
TypeScript resolver,
Fast Refresh,
CSS modules / SASS.

Thanks to its plugins system, if something doesn't come out of the box, the community can come with their own plugins (for instance a MDX plugin).

As Parcel doesn't depend on babel nor on webpack, it also installs way fewer packages, so the node_modules folder is way smaller.

Cons

As Parcel is just the bundler, it doesn't come with a test runner, nor any CLI tool to simply start a project.

Note: About test runners, for smaller projects we don't necessarily need one.

Code samples

CRA

I'll compare the same architecture between CRA and Parcel. Let's start with the initial CRA project with npx create-react-app test-cra:

$ npx create-react-app test-cra
Need to install the following packages:
  create-react-app@5.0.1
Ok to proceed? (y)
npm WARN deprecated tar@2.2.2: This version of tar is no longer supported, and will not receive security updates. Please upgrade asap.

Creating a new React app in /code/test-cra.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template...


added 1394 packages in 58s

209 packages are looking for funding
  run `npm fund` for details

Initialized a git repository.

Installing template dependencies using npm...

added 56 packages in 4s

209 packages are looking for funding
  run `npm fund` for details
Removing template package using npm...


removed 1 package, and audited 1450 packages in 1s

209 packages are looking for funding
  run `npm fund` for details

6 high severity vulnerabilities

To address all issues (including breaking changes), run:
  npm audit fix --force

Run `npm audit` for details.

Created git commit.

Success! Created test-cra at /code/test-cra
Inside that directory, you can run several commands:

  npm start
    Starts the development server.

  npm run build
    Bundles the app into static files for production.

  npm test
    Starts the test runner.

  npm run eject
    Removes this tool and copies build dependencies, configuration files
    and scripts into the app directory. If you do this, you can’t go back!

We suggest that you begin by typing:

  cd test-cra
  npm start

Happy hacking!

We can see that the install took almost a minute, and it installed 1394 packages, including 6 high severity vulnerabilities.

The project itself looks like this:

Migration to Parcel

Let's try to replicate the same architecture with Parcel.

$ npm i           
npm WARN deprecated stable@0.1.8: Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility

added 171 packages, and audited 172 packages in 5s

72 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

We can see here that the install is way faster: only 5s, and fewer packages were installed.

Except for modifying a bit the dependencies and the public/index.html file, I haven't changed the rest. (The devDependencies were automatically added by parcel in the following image)

And here are the modifications I did to the index.html:

I removed a "magical" env variable %PUBLIC_URL% and instead used direct paths,
Added a hard coded <script> tag:

Conclusion

I stopped using CRA when working for my React projects, and instead I always go to Parcel:

it's way faster (both for the install and to run) and smaller,
it comes with fewer "magical" tools that cannot be configured,
it's easier to customize and to maintain.

Semver: The unknown buildMetadata

Ayc0 — Thu, 14 Jul 2022 01:30:39 +0000

I was reading semver's spec and I noticed something weird in the regex:

This is the 1st time that I ever encountered the mention of buildmetadata.

Let's deconstruct that a bit

When you read the regex, it mentions at the beginning the required major, minor, and patch: a valid semver version needs to be at least MAJOR.MINOR.PATCH, for instance 1.2.3.

Then the version can contain an option prerelease tag starting with a -, for instance 1.2.3-hello and this prelease tag can be anything made of alpha numerics (0-9 or a-z or A-Z), . and -.

But what surprised me is the last one: the buildmetadata prefixed with a + (same thing as the prerelease so any alpha numerics, or ., or -).
So for instance 1.2.3+build is valid, and so is 1.2.3-beta.1+build.linux

Verification

Just to be sure, I run this in runkit, and indeed it can properly parse 1.2.3-pre.release.4+build.meta.5.6 as:

{
  major: 1,
  minor: 2,
  patch: 3,
  prerelease: ["pre", "release", 4], // here 4 is even a number
  build: ["build", "meta", "5", "6"], // but here 5 and 6 are strings
  version: "1.2.3-pre.release.4",
  raw: "1.2.3-pre.release.4+build.meta.5.6"
}

See for yourselves:

Discussion

I've seen plenty of times the prerelease being used (and I used it myself a few times too).

For instance, React uses it a lot:

My topic for a conversation with you is: Have you ever seen this used anywhere on NPM (or else where)? And if so, for what purpose?

Yarn.lock: How to Update it

Ayc0 — Sun, 05 Sep 2021 21:58:59 +0000

Introduction

Knowing how to read a yarn.lock file is important: it lists the packages that your application will end up using. Sure, your dependencies are listed in your package.json, it only lists your direct deps, not the deps of your deps.

So, if you really care about your app, you should be able to read this lock file, and here is another post about this:

Yarn.lock: How to Read it

Ayc0 ・ Jul 27 '21

#yarn #config #lockfile

If you spot something weird in the lockfile, this article will tell you how to fix it.

Problem
Solutions
1. Manually editing the lock file
2. The resolutions field
3. Removing the yarn.lock file
4. yarn dedupe (recommended)
Bonus: listing all versions of a package
1. Yarn 1
2. Yarn 2+
Conclusion

Problem

Note: I'll use the semver syntax, more information on it here: https://jubianchi.github.io/semver-check/.

Let's say you depend on a module A that itself depends on B with the version ^1.1.1. When A will be installed, yarn will resolve the latest version of B matching this version range (let say here 1.1.4). Now you'll have in your lock file something like: "A depends on B@^1.1.1, resolved resolved to 1.1.4".

Later, you want to install a package C, depending on B@^1.1.5. And when C is added, B@1.1.5 just came out. So you end up with B@1.1.4 AND B@1.1.5 in your node_modules.

You ended up here:

But ideally, you should end up like that:

The behaviour is indeed intended: the main goal of lock file is to ensure that your dependencies won't change if you don't ask for it. As you didn't ask for an update of A, it shouldn't update neither it nor its dependencies. And as updating B from 1.1.4 to 1.1.5 could introduce some regression, yarn won't update it.

Real world example: you are using create-react-app, and you want to also to use xo, as both come with their own version of ESLint pre-installed, you could end up with 2 ESLint installed.

Solutions

Manually editing the lock file

I personally really like this solution, as this is the one that allows you to fully manipulate the resolution mechanism.

With our previous example, we should have something like the following in the yarn.lock file:

"B@^1.1.1":
  version "1.1.4"
  resolved "https://registry.yarnpkg.com/B-1.1.4.tgz#???"
  integrity sha512-???==

"B@^1.1.5":
  version "1.1.5"
  resolved "https://registry.yarnpkg.com/B-1.1.5.tgz#???"
  integrity sha512-???==

We can simply edit the file, and merge the 2 versions like that:

"B@^1.1.1", "B@^1.1.5":
  version "1.1.5"
  resolved "https://registry.yarnpkg.com/B-1.1.5.tgz#???"
  integrity sha512-???==

Once this has been changed, we just have to run yarn install and 💥, B@1.1.4 will no longer be installed, only B@1.1.5.

The `resolutions` field

Yarn comes with a custom resolutions field you can set in your package.json

{
  "resolutions": {
    "B": "1.1.5"
  }
}

This will force all versions of B to resolve to this one version 1.1.5.

I don't like this approach, as it'll force all versions (even incompatible ones like a potential v2 that could also be used in your deps) to be updated to this unique one. So I'd reserve this for modules you know cannot exist in multiple versions, but I wouldn't use it otherwise.

Removing the `yarn.lock` file

If you remove the lock file completely and then run yarn install, yarn will re-resolve all versions to the latest allowed by their specified ranges, and thus fix all those duplicated deps.

I don't recommend doing that as not all packages respect the semver convention. So you could introduce a lot of regressions in your code.

`yarn dedupe` (recommended)

If you're using yarn 2+, you have access to the command yarn dedupe B (to dedupe all the B packages).

If you're running on yarn 2+, I strongly recommend using this, as it's the easiest and safest method of all of those listed here.

https://yarnpkg.com/cli/dedupe

Bonus: listing all versions of a package

Yarn 1

If you using yarn 1, you can use yarn list --pattern <package-name> to see all the different versions (and where they are coming from) of a package:

https://classic.yarnpkg.com/en/docs/cli/list

Yarn 2+

Yarn berry (version 2 and above), has the command yarn why (it already existed in yarn 1, but the output was completely different).

", showing all the versions of this package installed, why it was installed, what version range was required each time, and which versions were resolved"/>

The main difference between yarn list in yarn 1 and yarn why in yarn 2+ is that, in addition to having the version installed + the parent that required this package, you also have the version ranges that were requested each time.

Also, the tree is flatten here to only have the most meaningful information. But if you want to have a deep tree (like in yarn 1), you can run yarn why <package> -R:

-R", showing the same results as before, but also including all of the parent deps of those deps, recursively"/>

Conclusion

When working on removing duplicated packages, knowing how to read and modify your yarn.lock file is quite empowering.

And if you're running yarn 2+, you can just use yarn dedupe <package>, which will save you a lot of work.

DEV Community: Ayc0

@blocz/react-responsive v4

Breaking changes

No more <Match>

Removal of CSS-in-JS support

Other changes

React 19 support

Node version

Bundle size

Intl.Segmenter(): Don't use string.split() nor string.length

TL;DR

Explanation

Definitions

UTF-16

String.prototype.length

Unicode composition

Emoji Sequence

Intl.Segmenter

Browser compatibility

TypeScript 5.0: new mode bundler & ESM

Problem

Introduction

ESM

Which extension should we pick?

.ts

.js

Why are extensions required in ESM?

Why isn’t the transform of the extension automatically done by TypeScript?

Summary of the issue

Solution: allowImportingTsExtensions

Solution: moduleResolution: bundler

Conclusion

How does CSS work? The specificity

Introduction

Specificity

General rule

Egality

How to compute the specificity

General rules

Edge cases

Examples

Combining selectors

Inline style

!important

Tools

Parsel

VSCode

How to learn CSS with games

Selectors

Flexbox

Grid

CSS :before vs ::before & :after vs ::after

A bit of history

:pseudo-class

Example

::pseudo-element

Example

Light/dark mode: Corrections

CSS color scheme

Light/dark mode: the lazy way

Ayc0 ・ May 29 '21

Native system colors

Light/dark mode: the lazy way

Ayc0 ・ May 29 '21

:root with class names

Light/dark mode: user input

Ayc0 ・ May 30 '21

Using data attributes instead of class names

Light/dark mode: user input

Ayc0 ・ May 30 '21

Real time system mode

Light/dark mode: system mode + user preferences

Ayc0 ・ May 31 '21

Light/dark mode: React implementation

Ayc0 ・ Jun 24 '21

Proper cross-fade in CSS

What is a proper cross fade?

How to achieve this

TypeScript 4.9: satisfies operator

Purpose

No more `<Match>`

`.ts`

`.js`

Solution: `allowImportingTsExtensions`

Solution: `moduleResolution: bundler`

`!important`

`:pseudo-class`

`::pseudo-element`

`:root` with class names

Combining `as const` and satisfies

The `resolutions` field

Removing the `yarn.lock` file

`yarn dedupe` (recommended)