Forem: 𒎏Wii 🏳️‍⚧️

Controller Registry: adding behaviour to any HTML elements

𒎏Wii 🏳️‍⚧️ — Mon, 11 Aug 2025 19:21:32 +0000

Web Components

Custom elements are cool; I use them for plenty of things, but there is one thing about them that makes them unsuited for many problems: they take full control over an element and correspond to that element's main purpose.

This is perfectly reasonable for actual components, when one wants to define a completely new type of element with one clear functionality.

They don't, however, allow combining more than one custom element in one HTML tag, and while builtin custom elements are technically a thing, in practice they aren't viable (thanks, safari) and so attaching custom behaviours to built-in HTML elements isn't possible in practice either.

Enter Controllers

Or traits, or whatever else one wants to call them.

The idea here is simple: instead of the custom behaviour existing in the tag itself, it exists in an external object (or other entity), which is attached to an HTML tag and controls it.

Controller-Registry

As a prototype to play around with this idea, I implemented controller-registry (repository, github mirror).

The API is similar to custom elements wherever it makes sense, but is still different in many ways due to the differing requirements.

In summary

In HTML, controllers work like classes: one attribute that's a whitespace-separated list
In JavaScript, there is one central registry associating names to behaviours
Adding a controller to an element's attribute attaches a new controller automatically, while defining a new controller automatically upgrades all elements that already have that name in their list.
Unlike custom elements, controllers can also be removed from elements (and re-added, as many times as desired)

Playground

Here's a codepen I prepared from the example file in the repository for anyone who wants to just play around with it before reading on.

Feel free to also open up the dev tools and manually tinker with the controller attribute of the elements; their behaviours should be updated automatically.

Implementation

All things considered, the implementation is surprisingly simple.

Most of what matters happens in the ControllerRegistry class, and its one global instance. Creating new registries is possible, but I won't focus on that here.

The class itself holds a couple of internal data structures to keep track of elements and controllers. Weak maps are really convenient here: they allow associating data with an object but still let the object be garbage-collected if it doesn't have any other references.

The registry also has a MutationObserver that listens for both DOM insertions to keep track of new nodes as well as attribute changes specifically on the controller attribute.

How much optimization happens here is up to the browser, but using the attributeFilter, I've at least given the browser all the information it needs to treat this attribute the same way it does class, and internally hook into it without even considering where in the DOM it happens. That's as much as an implementation in JS can achieve.

The define function is mostly quite simple, in that it just takes its arguments as key and value to insert into a map; but before doing that it also checks if any element is already waiting for a controller of that name to be defined so that can be attached immediately.

A little bit of extra code at the start of the method checks for functions that are constructors, and transforms them into a wrapper function that calls the constructor with new and the element as its argument, then waits for the controller to be detached again and tries calling a detach method on the controller object if it is defined. Technically the constructor only receives a revocable proxy to the element, but I am not sure if I want to keep that in the code.

Some of the functions simply mimic the public API of CustomElementRegistry; keeping things similar to what developers already know reduces friction, after all.

The update and attach methods are where most of the magic happens:

It extracts controller names from the controller attribute of the elements, then looks those up in the controller list and either attaches them or adds the element to the waiting list if a controller by that name is not yet defined.

When a controller is attached, a little bit more magic happens: A new promise is created that fulfills when the controller is detached. An abort controller is also created which will abort on disconnect. Its signal is then saved as a signal property on the promise object. In fact, the abort controller is what resolves the promise in an event listener.

This means that the promise can also be passed as the third argument to element.addEventListener to automatically remove the listener when the controller is detached. Pretty neat, isn't it? You can see this in the codepen example above.

And that is most of the exciting parts. At the top of the module there is also a helper that works a bit like a DomTokenList, so controllers can be manipulated just like classes; but its implementation isn't very complicated.

Conclusion

All in all, the proof of concept took a couple of hours to implement and maybe two or three more of tweaking, documenting and playing around with it.

What do you think? Should this be a native feature of browsers? Are custom elements already enough? They can totally be combined, by the way: you can add controllers to custom elements too :)

Whatever your thought, let me know in the comments, and feel free to pick the code apart.

Up and down again: A missing feature in front end event propagation?

𒎏Wii 🏳️‍⚧️ — Sun, 06 Oct 2024 07:51:20 +0000

JavaScript and the DOM use the Event API to let elements inform their ancestors of things that happen. This works well because each element only ever has exactly one parent (up to the document root), so the path an event takes is linear and reasonably short relative to the size of the document.

But there is no analogue mechanism to propagate events downwards through the DOM:

For a simple example, one can imagine a scenario like this:

<product-search>
   <search-box></search-box>
   <product-card></product-card>
</product-search>

The API of the search-box element is easy to build with generic DOM APIs: whenever it internally determines that a user's input should start a search, it emits an event of some sort, presumably something like framework:search.

The product-search can then simply listen for said event on itself and automatically becomes very resilient to nesting and other weird HTML shenanigans; users can even use different search components if they're feeling extra creative that day.

Once the product-search component has received the search event, it needs to propagate the state change back down to the product-card. This is surprisingly difficult to do using a generic mechanism.

The problem here is that a) product-search might not want to limit itself to only product-card children but work with any element that conforms to some generic API, b) the element that needs the notification might be deeply nested within the product-search, and c) the component might have a large number of children, making a shotgun approach risky from a performance perspective.

As far as I am aware, there is no feature in the DOM API that fully addresses this. Am I just making things too complicated here? Is there an easy way around it?

My best idea here is a compromise that achieves a) and b) by using querySelectorAll("*") and dispatching a non-bubbling event on every child element indiscriminately.

What do y'all think?

One thought I forgot to add is the possibility to shift the responsibility for the communication to the product-card; it could, when connected, inspect its own context and install an event listener on product-search. This ends up causing the same problems as before: We might want to use a different wrapper, the search wrapper might be at any point in the ancestor chain and installing event listeners everywhere might degrade perforamance and respond to events the component actually doesn't care about.

How I write CSS selectors

𒎏Wii 🏳️‍⚧️ — Mon, 02 Sep 2024 19:29:17 +0000

There's many CSS methodologies out there, and I hate them all. Some more (tailwind & al.) and some less (BEM, OOCSS, etc.). But at the end of the day, they all have flaws.

People use these approaches for good reasons, of course, and many of the problems addressed are ones I have also encountered. So in this post, I'd like to write down my own guidelines for how I keep CSS organised.

This isn't a fully described CSS methodology that anyone could just start using. Maybe it could be turned into one with some extra work, but the purpose of this post is simply to show how I make these decisions when writing CSS.

Builtin Elements

As a rule of thumb, I try to use builtin element types as much as possible, and with as little extra fluff as possible.

Having a need for a thousand different types of button is a sign that there might be something wrong with the design on a deeper level, so while in some cases I get the appeal of CSS being inert until framework-specific classes are used, in most cases I see it as ideal when a button is just <button>Click Me!</button> and looks like a button without any further magic.

div.btton should turn into button

Custom Elements

Not all design elements have a semantically fitting HTML equivalent, and for these cases, I usually resort to custom elements.

I haven't seen many instances of custom element names being used without any accompanying javascript, but it has proven to be a surprisingly solid choice for writing clear HTML that also looks the way I want.

Entirely separate elements in terms of design are also more likely to, over time, develop requirements that can only be implemented with JavaScript, which leaves you with a clear path to implementing those that doesn't need any changes in the HTML nor the CSS.

div.vsep should turn into vertical-separator

Classes

Classes should work as modifiers of the existing node name, rather than entirely new element types, and often have similar but different effects on different element types.

A dangerous button is a button.danger

Attributes

Some ways of modifying elements aren't simple on/off switches that classes are useful for, but behave more like key-value pairs.

In these cases, custom attributes with matching selectors have proven to be the best option almost every time I've used them. Unlike hyphenated classes, they show on a syntax-level which is the attribute and which is the value, making it easier for editors to highlight them, easier for the human eye to quickly parse, and easier to interface using JavaScript.

For those of us who still have hope that the attr() function might one day make its way into CSS for more than just content, this is also an extra layer of future-proofing.

IDs

IDs are, by definition, unique inside the document. As such, any rule targeting a particular ID will be limited and may require refactoring if it later turns out there should be more than one element of this type on the lage after all.

As such, IDs should be used sparingly and only when it makes no sense to ever have more than one element in one document.

The benefits over classes in both a practical and readability sense are rather small, so erring on the side of classes is usually the best idea when no clear 1-to-1 relation between element and styling can be identified.

Inline CSS

Any real-world application will at some point have elements that simply require individual tweaking in order to make them more aesthetically pleasing in the context they appear in.

In these cases, the style attribute is the way to go. Any reason why using it is considered bad practice applies to any sort of inline-styling, including utility classes. The problem isn't the attribute, it's mixing styling and markup.

The one difference between style and class for inlining styles is that one indicates purpose, allows using plain CSS and is mostly universal, while the other isn't.

Put simply, width: 100px has a universally defined meaning, whille .width-100 could mean anything.

Utility Classes

In very rare occasions, element-specific styles get so complex that inlining them explicitly would harm readability, or is even impossible (for example if it requires media queries).

In these cases, utility classes are basically the only option, even if they're ugly.

In an ideal world, these could be handled separately from specific mixin classes, and I have even considered using prefixing to more easily tell them apart, but ultimately haven't found a good way to make these not be ugly.

I like the idea of prefixing utility classes with a + to represent that they add some sort of functionality to the element, in contrast to normal classes, that specify what type of an element is.

<button class="danger +floating">Red floating button</button>

And that was about it. Of course, no two projects are the same, and sometimes rules have to be bent a little to remain practical, but overall, that's my framework for deciding how to make a thing on the screen look a certain way.

What are your thoughts? Do you hate it? Do you think it makes sense? Let me know in a comment 💜

What's on your desk that makes it your desk?

𒎏Wii 🏳️‍⚧️ — Mon, 02 Sep 2024 13:47:29 +0000

Most of us spend a lot of time at our desks. So I'm curious, what do y'all have at your desks that truly makes it your desk? Anything goes, no matter how fancy or mundane it is!

I recently treated myself to this semi-cheap tea set, because sometimes it's nice to just take my head out of the code, make some nice tea, and just get a bit of a mental reset before continuing with work.

CSS needs a name prefix selector

𒎏Wii 🏳️‍⚧️ — Tue, 27 Aug 2024 08:30:24 +0000

I love working with custom elements for all kinds of things, but sometimes I just want to hide stuff until it is loaded or do something else with it in CSS.

A simple solution looks like this:

framework-button:not(:defined) {
   display: none
}

Put that in a <style> tag in the HTML and the button will just appear once it's loaded.

But with larger frameworks, this becomes really annoying. Sometimes you can get away with simply selecting :not(:defined), but that's not always viable.

An obvious (at least to me) fix: CSS needs a name prefix selector, so you can just do this

framework-*:not(:defined) {
   display: none
}

It's not like this would be an entirely new thing. We can already kind of do this with attribute selectors.

And I'm sure allowing splits only at - in an element's name would make it reasonably easy to implement this effectively in browsers too.

What do y'all think? Would this be useful? Are there easier solutions that already work?

Faking sessionStorage to keep sites from crashing

𒎏Wii 🏳️‍⚧️ — Fri, 10 May 2024 08:15:49 +0000

The Problem

So I have cookies disabled by default in my browser. The reason should be obvious: some sites just have no business saving data on my PC. Yes yes, cookies are cool for safety and performance stuff, but site owners couldn't handle their toy responsibly, so I'm taking it away.

Now, the problem is that the modern web isn't built for privacy-valuing users. Sites often use frameworks intended for highly interactive applications, even when all they do is display static content.

So I often end up seeing pages like this

This is nextjs.org, by the way. Looking into the console, here's what happens:

Cool. This site doesn't really "do" anything, I just want to read some text and ideally have some images in between. You know, a classic static website. And yet, it wants storage.

The Solution

Okay, challenge accepted.

Object.defineProperty(window, "sessionStorage", {
   get() { return 20 }
})

console.log(sessionStorage) // 20

Cool, looks like chromium lets me overwrite this property. And considering there's a flicker before the error appears, I bet I can inject a fix using an extension before the application even has a chance to fail.

const fakeSessionStorage = {/* TODO: Implement */}
Object.defineProperty(window, "sessionStorage", {
   get() {
      return fakeSessionStorage
   }
}

Wait, but this is going to reset sessionStorage on every website, even if I enable cookies manually. Ooooops

Guess I'll have to wrap the whole snippet in some more code:

try {
    window.sessionStorage
} catch {
    // inject custom sessionStorage
}

Looks good. What does the website do now?

Perfect! Looks like I'm making progress. Now I face a different problem: I actually need to fake the sessionStorage object somehow.

What... what does that even do? MDN to the rescue!

It looks like the list of methods I'd have to fake is somewhat reasonable.

Storage.key()
Storage.getItem()
Storage.setItem()
Storage.removeItem()
Storage.clear()

Honestly, this looks like a Map. The functions are just named differently, but that's about it. I just have to map (no pun intended) the methods to each other like this:

getItem(key)        -> get(key)
setItem(key, value) -> set(key, value)
removeItem(key)     -> delete(key)
clear()             -> clear()

Then just re-implement the key method using Map's keys method. Sounds easy :)

The Result

And after a bit of tinkering, here's the entirety of my resulting code:

class FakeStorage {
   #map = new Map()

   getItem(key) { return this.#map.get(key) }
   setItem(key, value) { this.#map.set(key, value) }
   removeItem(key) { this.#map.delete(key) }
   clear() { this.#map.clear() }
   key(n) { return this.#map.keys()[n] || null }
}

const fakeLocalStorage = new FakeStorage()

try {
   window.sessionStorage
} catch {
   Object.defineProperty(window, "sessionStorage", {
      get() {
         return fakeLocalStorage
      }
   })
}

I inject this into the page using the "User JavaScript and CSS" chrome extension, but I'm sure most other extensions will work too.

And voilà:

A working next.js website without any pesky cookies. Would it have been so hard to build this fallback into their page in the first place? 😩

Note: I have not thoroughly tested my fake storage object. Don't just copy-paste this into your application without making sure it doesn't have any subtle bugs.

CSS Hack: "Named Layers"

𒎏Wii 🏳️‍⚧️ — Fri, 03 May 2024 10:49:12 +0000

The Problem

When elements overlap on a website, the CSS property z-index lets us decide which should be drawn on top.

But this property only uses plain numbers, which will usually appear spread out through countless CSS files.

This is both difficult to keep track of and hard to read.

The Solution

Stop using numbers directly when setting the z-index on a selector. Instead, put something like this at an easy to find spot, like a separate layers.css file:

:root {
   --layer-overlay: 2;
   --layer-floating: 1;
}

Then, when you want to assign one of these "layers" to an element, simply use the custom element as its z-index:

.overlay {
   z-index: var(--layer-overlay);
}
my-floating-component {
   z-index: var(--layer-floating);
}

This way, you can just number your layers starting at one, without having to leave gaps in case you ever want to add something in between. The numbers are now all in one place and easy to update.

Say you want to add a header layer in between the existing two. You just increase the overlay layer to 3 and add the header in between:

:root {
   --layer-overlay: 3;
   --layer-header: 2;
   --layer-floating: 1;
}

Note: This is different from "CSS Layers", which change the order in which rules are applied. Those are "layers" in the cascade, these are "layers" in the rendered webpage.

I've been using custom properties for many years now, and only recently figured out I can just use them to organise my z-indices like this.

Did you think of doing this too? Have you seen it out in the wild? Please leave your thoughts in the comments <3

Sh*t, I didn't mean to commit that!

𒎏Wii 🏳️‍⚧️ — Fri, 05 Apr 2024 10:40:15 +0000

We've all been there 😖

When working on a project, specially in a team, and doubly so if there's other things that occasionally distract us from the task at hand, it is easy to commit changes that were meant to stay local.

One may add a line that wipes a database at the start of an import for a tighter testing cycle, add debug outputs, etc.

As life gets in the way, we take breaks, coworkers want other things from us, or we simply have our head filled with other aspects of the task, one can easily forget to remove these things before committing and pushing.

But it doesn't have to be this way 😮

Git hooks can help us with this. We just have to think up a way for us to mark changes that should never make it into a commit and write a hook to detect them.

Here, I will use the string "nocommit": if this appears anywhere in the changes I'm going to commit, I want git to reject my commit and tell me where it was found.

Let's get to work 😀

Writing git hooks is surprisingly easy: They're really just shell scripts that run in the project directory. Some get arguments, but we don't need them here.

We care about the pre-commit hook. To enable it, just write a file to .git/hooks/pre-commit in your git repository and set its executable permission. To make it reject all commits, put this in the file:

#/bin/sh
exit 1

To accept all commits, just have it return 0 instead.

Now, to get to the interesting part:

Get our files 📂

For starters, we'll need access to the files as they will get committed. We don't want our entire commit to fail if a there's a file with a nocommit mark that isn't even going to get committed.

Luckily, this is relatively easy to achieve. We can check out the index of the repository into a temporary directory like this:

tmp_dir=$(mktemp -p /dev/shm -d -t "git-index.XXXX")
git checkout-index -a --prefix="$tmp_dir"/

The first command just gives us a temporary directory in /dev/shm and makes sure it is unique.

The second command checks out the entire index into this temporary directory.

But there isn't really much of a point in checking every file in the repository; we can just limit our search go the files that have been modified. To list these, we can use this command:

git status --porcelain | cut --bytes 4-

Get our marks 🔖

Now comes the juicy part. Having our files, we want to scan them for a keyword. For better readability, we can put this part in a function:

get_marks() {
    git status --porcelain | cut --bytes 4- | while read file
    do
        if [ -e "$tmp_dir/$file" ]
        then
            grep -n -i nocommit "$tmp_dir/$file" | sed "s/:/ /" | while read line
            do
                echo "$file:$line"
            done
        fi
    done
}

We start with listing the files as described above, then pipe that into a sh while loop that reads each individual line.

We then use the grep command to search for "nocommit" in our target $file in the $tmp_dir directory, ignoring case (-i) and prepending the line number (-n). The result then gets piped though sed to turn the single colon : separating the line number from the line into a normal space. This last part is just a matter of taste, honestly.

The results are then again piped into another loop, which simply prints the file name and the line. The resulting lines would look something like this:

path/to/file.js:14 console.log("I hate my job") // nocommit

Evaluate the results 🔍

Now that we can extract the lines we care about, it's time to decide if the commit is good or not.

We can do this with a simple if:


marks=$(get_marks)
if [ -n "$marks" ]
then
    /bin/echo -e "\x1b[31m'no$THEWORD' mark(s) found:\x1b[0m"
    echo $marks
    status=1
else
    status=0
fi

First we call our function to get the marks and save its output into a marks variable. If it's empty, we set a status variable to 0. We can't exit yet because we still need to clean up after ourselves. If marks isn't empty, we print a warning, then the marks, and set our status to 1.

Cleanup 🧹

After this we're basically done with the important part; but the temporary directory is still around and we should delete it now that we're done with it. After that, we can just exit with the status we decided on earlier.

rm -r $tmp_dir
exit $status

And there you have it 😁

Here's the finished script. I made one more modification to make sure the script itself can actually be committed without problem 😅

#!/bin/sh

export THEWORD=commit

tmp_dir=$(mktemp -p /dev/shm -d -t "git-index.XXXX")
git checkout-index -a --prefix="$tmp_dir"/

get_marks() {
    git status --porcelain | cut --bytes 4- | while read file
    do
        grep -n -i no$THEWORD "$tmp_dir/$file" | sed "s/:/ /" | while read line
        do
            echo "$file:$line"
        done
    done
}

marks=$(get_marks)
if [ -n "$marks" ]
then
    /bin/echo -e "\x1b[31m'no$THEWORD' mark(s) found:\x1b[0m"
    echo $marks
    status=1
else
    status=0
fi

rm -r $tmp_dir
exit $status

Title: Top 20 JavaScript One-Liners That Don't Actually Work

𒎏Wii 🏳️‍⚧️ — Thu, 15 Feb 2024 10:37:26 +0000

Generative AI has blessed the world with many listicles, some helpful, some less so. But with all that focus on having AI do actual work, we are missing out on the fun side: Making AI do dumb stuff. So for this post, I asked ChatGPT to give me 20 JavaScript one-liners that don't actually work.

This post has been copied as-is from ChatGPT with two changes:

I added some notes in between using quote blocks so they can be easily identified
To prevent markdown resetting all the counters to 1, I had to add a zero-width space between the numbers and the .; otherwise all of them would have said 1.

Title: Top 20 JavaScript One-Liners That Don't Actually Work

JavaScript, with its versatility and simplicity, often lends itself to concise, one-liner solutions to common programming problems. However, not all one-liners are created equal. In this blog post, we'll explore some JavaScript one-liners that may appear to work at first glance but actually fail under closer scrutiny. Let's dive in and unravel the mysteries of these seemingly innocent lines of code.

1. The False Truth:

   const truth = true;
   if (truth = false) console.log("This will never be executed");

A common mistake of using assignment (=) instead of equality (== or ===). The condition will always be false, leading to confusion.

Human Note: Starting off strong with a two-liner. I guess the first line is just the preamble for the actual example, but I still find it funny.

2. Infinite Loop Illusion:

   for (let i = 0; i != 10; i--) console.log(i);

Despite the intent to count down from 0 to 9, i will decrease infinitely due to i--, never reaching the loop exit condition.

Human Note: There's no deeper wisdom to be found in this one, it literally just is a broken for loop. Try this with a char in C and it might actually work.

3. Truthy Falseness:

   if ([]) console.log("This will be executed");

An empty array is truthy in JavaScript, contrary to some expectations.

Human Note: I had to double-check this one and yea, it's actually true. See? I already learned something. And within 10 minutes, I will already have forgotten it again.

4. The NaN Trap:

   if (NaN === NaN) console.log("This will never be executed");

Comparing NaN with anything, including itself, always returns false. Use isNaN() for NaN checks.

Human Note: Quality advise. But if you wanna be extra fancy, you can compare a value to itself to check if it's NaN. Your coworkers will thank you.

5. Function Overload:

   const foo = () => console.log("foo");
   const bar = () => console.log("bar");
   const baz = () => console.log("baz");
   const qux = () => console.log("qux");
   const func = foo() && bar() && baz() && qux();

All functions will be called regardless of their return values. To stop on the first false value, use the logical OR (||) operator.

Human Note: I tested this in the browser and looked it up on mdn. As far as I can tell, ChatGPT is straight up bullshitting us here; only the first function will be called.

6. The Lost Context:

   const obj = {
     value: 42,
     getValue: () => this.value
   };
   console.log(obj.getValue());

Arrow functions don't have their own this context, leading to undefined.

Human Note: This is misleading. Arrow-functions don't set their own this context when called, but they save the surrounding this. So if this object is defined wherever a this exists, it will refer to that this. Sometiems this is exactly what the programmer wants. In fact, this is partly the point of arrow functions.

7. The Illusion of Privacy:

   const mySecrets = {
     password: "12345",
     getSecrets: () => this.password
   };
   console.log(mySecrets.getSecrets());

Similar to the previous example, arrow functions inside objects don't provide privacy as expected.

Human Note: I legit have no clue what ChatGPT is even trying to tell us here. If you care about privacy, you will be excited about the sponsor of this video... Wait, wrong script.

8. Looping Headache:

   const arr = [1, 2, 3];
   for (var i = 0; i < arr.length; i++) {
     setTimeout(() => console.log(i), 1000);
   }

The closure captures the reference to i, which is hoisted and becomes 3 by the time the callback executes.

Human Note: Yes, that's what var does. This is why you use let instead unless you specifically want var.

9. Promise Trap:

   Promise.resolve('foo').then(console.log);
   console.log('bar');

then expects a function as an argument. console.log gets called immediately, not when the promise resolves.

Human Note: I have no clue what the toaster is trying to tell me. Maybe it's time for the airlock.

10. String Reversal Sorrow:

```javascript
const reverseString = str => str.split('').reverse().join('');
console.log(reverseString('hello'));
```

This approach doesn't work with Unicode characters or emoji.

Human Note: Ah yes, a true classic. Literally every "top 10 one-liners" listicle here on dev has this code, and literally every one of them has at least a million comments pointing out the unicode issue.

... (Continuing with more examples)

Human Note: Note how the title says 20, but there's actually only 10. This "AI" can't even count past 20 and people are trusting whatever it spits out without even double-checking.

In conclusion, while JavaScript one-liners can be elegant and efficient, they often hide complexities that may lead to unexpected behavior. It's crucial to thoroughly test and understand each line of code, especially when condensed into a single line. Remember, readability and clarity should never be sacrificed for brevity.

Human Note: And hopefully, I've been able to show that this is even more important when relying on code you get from some random AI chat.

So there you have it. 20 10 javascript one-liners that don't actually work. Except some do. I hope this silly little post has been at least somewhat amusing, and above all else, that I've been able to show why AI generated content shouldn't be trusted blindly. More importantly, I hope I've made clear how AI generated posts like this one can contain both obvious and very subtle mistakes, and posting them on the internet without even fact-checking them can seriously mess with people who are honestly trying to learn JavaScript.

Callbacks and References: Allowing the Garbage to get Collected

𒎏Wii 🏳️‍⚧️ — Wed, 07 Feb 2024 13:05:15 +0000

JavaScript being a garbage-collected language, we don't usually have to concern ourselves with questions of allocating and releasing objects. But occasionally, specially when dealing with callbacks, it is easy to keep objects alive indefinitely, even if there are no longer any meaningful references to this.

There's several tools the language provides us to deal with these situations:

WeakRef to store a single weak reference to an object
WeakMap to associate values with objects only as long as they exist
WeakSet to remember objects as long as they exist
FinalizationRegistry to do something when an object gets collected

Depending on the situation, one may need one or another of these features, but the case I want to describe today will make use of the first and the last.

A common case is for objects to care about certain external state changes for as long as they exist. For example, a custom element might want to listen for "scroll" events on the window object. But naively adding an event listener to window means to keep a reference to the object. If these custom elements are short-lived but many in numbers, then they will accumulate in memory, and the additional event listeners will also pile up and waste processing power.

Here's a simple example of something like this:

class MyElement extends HTMLElement {
   constructor() {
      super()
      window.addEventListener("scroll", event => {
         this.handleScroll()
      })
   }

   handleScroll() {
      this.classList.toggle("top", window.scrollY == 0)
   }
}

What we want is to remove the event listener by the time the object gets garbage-collected. To achieve this, we can make use of two features:

Firstly, replacing the strong reference to this in the event listener with a WeakRef will prevent the event listener from keeping the object alive if no other references to it exist. Once the object has been collected, the deref() method will just return undefined.

const ref = new WeakRef(this)
window.addEventListener("scroll", event => {
   ref.deref()?.handleScroll()
})

This will allow the object to be garbage-collected, but will keep the event listener attached, meaning it will still fire on every scroll event, fail to deref the reference and therefore do nothing.

An easy way to clean up event listeners is to combine AbortController with FinalizationRegistry.

The former lets us pass a signal to an event that will remove the event, while the latter allows us to run some code when certain objects get collected.

The interface for this is relatively basic: We create a new FinalizationRegistry and pass it a callback. Then we register an object A and an associated (different) object B. When A gets garbage-collected, it obviously can't be passed to the callback, so instead, the callback is passed B.

const abortRegistry =
   new FinalizationRegistry(c => c.abort())

This abortRegistry now allows us to register an object and an associated AbortController, and will call abort() on the controller whenever the object gets collected.

Now we just need to register our object on creation, and pass the controller's signal to the event listener.

Here's the complete code:

const abortRegistry =
   new FinalizationRegistry(c => c.abort())

class MyElement extends HTMLElement {
   constructor() {
      super()
      const ref =
         new WeakRef(this)
      const controller =
         new AbortController()
      abortRegistry.register(this, controller)

      window.addEventListener("scroll", event => {
         ref.deref()?.handleScroll()
      }, { signal: controller.signal })
   }

   handleScroll() {
      this.classList.toggle("top", window.scrollY == 0)
   }
}

Comparing to lifecycle hooks

An easy point of criticism against the example above is that, whenever possible, resource cleanup should be achieved via the custom element API's lifecycle hooks connectedCallback() and disconnectedCallback().

Two reasons why this may not be a viable alternative are that

This kind of cleanup might be necessary for objects that aren't DOM Elements and therefore cannot rely on their DOM connection for cleanup.
There may be cases where it is necessary to continue sending signals to a custom element even while it is disconnected from the DOM, usually because it might be inserted again at a later point in time.

In either case, the only option for cleanup is keep the object set up until it actually becomes inaccessible and therefore couldn't possibly be needed anymore.

And that's it 😁

Did you learn something new? Was this old news to you? Let me know with a comment, and feel free to share how you handle cases like these in practice 👍

Cover Image: Jilbert Ebrahimi (Unsplash License)

DOM is easy: Just make it work like an Array 👍

𒎏Wii 🏳️‍⚧️ — Fri, 12 Jan 2024 13:41:06 +0000

Modifying DOM elements without a framework can be tedious. The method names are long, and simple common tasks are split into tiny steps.

Wouldn't it be nice if the DOM was a bit more like an Array? Just push a new element, call sort or even reduce all the values into one.

As part of a larger project, which I'm writing a longer post about at the moment, I built this convenient little helper that works well enough on its own that I want to write a separate little post about it.

domLense is a module of less than 100 lines that lets you pretend a DOM element is actually an array. You can index it, push and pop values, loop it with forEach and even map, reduce, etc. it to get new values.

The way it works is simple: You tell the module how to get the interesting data from an element, and how to deposit different data back to it. Optionally, you define how new elements should be created.

const transforms = {
   get(li) { return li.innerText },
   set(li, text) { li.innerText = text },
   new() { return document.createElement("li") }
}

In this case, our "interesting data" is just the text content of a bunch of <li> elements.

All that's left now is to call domLense on an unsuspecting list element, and we'll be able to treat it just like an array:

const listElement = document.createElement("ol")
const list = domLense(listElement, transforms)

list.push("First item on the list")
list.push("Another item on the list")
list.reverse()
console.log(list.map(text => `* ${text}`).join("\n"))

I've prepared a small codepen demo to play around with this.

The way this works isn't really that complicated. The helper simply creates a proxy that redirects integer indices to the element's child list applying the provided transformations. For any other keys, it tries looking them up in Array.prototype.

Extracting a JS library from a snippets repository

𒎏Wii 🏳️‍⚧️ — Fri, 29 Sep 2023 14:36:23 +0000

Context

A couple of years ago, I created a repository for all those JavaScript snippets and files that were were too small to turn into their own project, and could just be copy-pasted into wherever they were needed, or imported via services like jsdelivr directly through github.

As some of these files grew in size and scope, this approach started to be less and less convenient, and eventually it became clear that to continue to use and maintain these bigger libraries, it would be better to just migrate them into their own repository.

In principle, it would have been good enough to simply copy the files into a new repo, check them in with an "Initial Commit 🎉" and refer to the collection repository where their original development history resides.

But that would be boring, and I like to make things look neat, so I decided I wanted to migrate the commit history of these individual files into their new repositories.

How did I do it?

The first file on my migration list is skooma.js, a JS port of a Lua-library of the same name that I had gotten so used to that I wanted to use it in my front-end code as well.

This file is a good case-study because it started out as render.js, but got renamed to skooma.js after only a few commits. This isn't too much of a problem, it just means that I also had to keep all commits including the original render.js file, as well as skooma.js, and its corresponding skooma.md file explaining what it does.

As a starting point, it was clear that the best tool for the job would be git rebase in some way; maybe there are other git commands to get this done with an even higher degree of automation, but for a one-off task all I needed was to automate ca. 90% of the work so I wouldn't have to cherry-pick commit by commit.

Starting by just running git rebase --root --interactive and having a look at the output and the available commands (I have used interactive rebase many times, but seeing the output of the to-do file before me just helped thinking about how to best handle it), I wasn't really sure if it'd be possible to really automate the entire process, so I went for the simpler and only partly automated option:

Start an interactive rebase
Run a script over the to-do file
Run the rebase and intervene manually where needed

The script

This is the part where the magic happens. When you call git rebase --interactive, you get an editor window listing everything the rebase will do, a "program" in the classic sense, which you can edit to make git do different things. The syntax looks something like this:

pick 2c5a6d3 Initial commit 🎊
pick 1e6c0de Add template module to more easily write templates
pick bbbb234 Add Better HTML element class for custom elements
pick c8fd5b1 Refactor scripts into ES6 modules
pick 79af2b7 Add skooma-like functional DOM rendering helper
pick da2f082 Improve HTML render helper
pick 24ee30f Add special case for templates to render script
pick 7a61b96 Rename render to skooma.js
pick 7e72b33 Remove uppercase node special case from skooma.js
pick f97ae06 Remove setup function from template.js
...

The first word is the command of what will be done. pick means it just uses the commit as-is. A complete list of commands can be found in a commit that git adds at the bottom of the to-do file.

The second word is the commit hash, which is needed because you can move lines around in this file to re-order commits (this may of course cause conflicts that will require manual intervention, but git is smart enough to pause the rebase when that happens, give you a rough description of what's confusing it, and tell you what to do and how to continue after fixing it).

Anything after that is the commit message. This only gets added to make it easier to edit the file interactively, but git itself will ignore these. Nevertheless, it would be nice to preserve these messages after modifying the to-do program to make it easier to check what is ultimately going to happen.

To build my script, I decided to use Lua, for no other reason than it being the language I use for most scripting I do at home and I didn't want to bother with something exotic. I could probably have done the same with a lot less code in Ruby, but since I mostly use that at work for bigger projects, I'm used to using only the kinds of features that Lua also has, and almost never have any contact with the more Perl-like features that make Ruby good for ad-hoc scripts; so ultimately, so the advantage isn't all that big in the end.

Before I break this up and explain what everything does, here is the finished script:

#!/usr/bin/env luajit

local function files(commit)
   local handle = io.popen("git diff-tree --no-commit-id --name-only " .. commit)
   return handle:lines()
end

local wanted = { "render.js", "skooma.js", "skooma.md" }
for i, file in ipairs(wanted) do
   wanted[file] = i
end

for line in io.stdin:lines() do
   local commit, message = line:match("pick ([0-9a-f]+) (.*)$")
   if commit then
      local changed = {}
      for file in files(commit) do
         table.insert(changed, file)
         changed[file] = #changed
      end

      local want for i, file in ipairs(changed) do
         if wanted[file] then
            want = true
         end
      end

      if want then
         print(string.format("pick %s %s", commit, message))
         for i, file in ipairs(changed) do
            if not wanted[file] then
               print(string.format([[exec if [ -f "%s" ]; then git rm %s && git commit --amend --no-edit; fi]], file, file))
            end
         end
      else
         print(string.format("drop %s %s", commit, message))
      end
   end
end

Ignoring the files function for now, I start by defining a list of files that I want to keep. The for loop is only there to make the table function as a set as well as a list, which is a neat feature of Lua that I won't get into detail here.

The script loops over all of its input lines (so I can just pipe the whole file through it from vim), and parses out a commit hash and the following commit message, discarding the "pick" at the start of the line.

When the line matches (which excludes empty lines and comments), it first collects a list of changed files, using the helper function from earlier. This is done using the git diff-tree command (admittedly, I just googled this after spending a minute or two trying to find out how to do this from the git manpages). When given the --no-commit-id and --name-only flags, as well as a commit hash, it essentially just lists all the files that were changed, added, deleted, etc. in that specific commit. Exactly what I needed.

After collecting the list, I loop over it again and look for each file name in the list of wanted files. If it appears, a flag is set to true, otherwise I can just drop this commit. This could have been merged into the first loop, but I'm not gonna win any prizes for making a script that's gonna run 10 or 20 times in total run a few milliseconds faster.

When the commit modifies one of the files I want, I add a new pick command for it to keep the commit.

At this point, there's a bit of a problem: Most commits creating new files will usually not touch any of my relevant files. Skooma is its own thing, and I usually try to keep the git history clean. But I don't bother splitting "housekeeping" commits by file, so things like running a linter over the whole project and fixing all the warnings. This will create commits that 1. modify files I want to keep and 2. modify unwanted files which, at this point, aren't part of the repository anymore, as the commits creating them have been dropped.

This is the part where git will pause the rebase, show a description of what's wrong, and ask the user to fix it. Luckily for me, and anyone who might want to do something similar, this almost always follows the same pattern: The commit says to modify a file, but the file is no longer known to git. The fix:

Call git status to see what files are no longer there
Call git rm on all of the files, or just git rm -r <dir> if they're all in a subdirectory
Call git rebase --continue to tell git all is fine now

This leaves me with only one possible problem: If any file was, hypothetically, created in a commit that modifies one of my wanted files, then git would have no problem with that, and I'd end up with an extra file in my repo. So I added a little loop that, after each commit gets picked, loops over all the extra files, and adds an extra command for each of them which deletes them if it still exists. Since git updates the working directory as it applies commits, I only need to check for the actual file, without any git magic to see if it exists in the last applied commit. I'm fairly sure this wasn't the case in my repo, but I just wanted to add that check while I was at it to make the script a bit more robust.

Here's what the resulting to-do file looks like, after feeding it through the script:

drop 2c5a6d3 Initial commit 🎊
drop 1e6c0de Add template module to more easily write templates
drop bbbb234 Add Better HTML element class for custom elements
drop c8fd5b1 Refactor scripts into ES6 modules
pick 79af2b7 Add skooma-like functional DOM rendering helper
pick da2f082 Improve HTML render helper
pick 24ee30f Add special case for templates to render script
pick 7a61b96 Rename render to skooma.js
pick 7e72b33 Remove uppercase node special case from skooma.js
drop f97ae06 Remove setup function from template.js
drop d703ae1 Refactor BetterHTMLElement with more meta-magic ✨
pick 5f27242 Fix checking for template objects in skooma.js
pick c16eb29 Extend skooma to support SVG as well as HTML
pick 6f85103 Fix skooma.js syntax for strict mode
pick 60af077 Make hyphenation in consistent with browser APIs
exec if [ -f "BetterHTMLElement.js" ]; then git rm BetterHTMLElement.js && git commit --amend --no-edit; fi
drop 137f586 Add option for customized built-in elements
pick fb6b86b Fix undefined variable in skooma.js
drop 63a85b7 Fix undeclared variable
pick 0448cd2 Update skooma.js to handle numbers
drop be31d1f Add mutation observer to BetterHTMLElement
...

Forem: 𒎏Wii 🏳️‍⚧️

Controller Registry: adding behaviour to any HTML elements

Web Components

Enter Controllers

Controller-Registry

In summary

Playground

Implementation

Conclusion

Up and down again: A missing feature in front end event propagation?

How I write CSS selectors

Builtin Elements

Custom Elements

Classes

Attributes

IDs

Inline CSS

Utility Classes

What's on your desk that makes it *your* desk?

CSS needs a name prefix selector

Faking sessionStorage to keep sites from crashing

The Problem

The Solution

The Result

CSS Hack: "Named Layers"

The Problem

The Solution

Sh*t, I didn't mean to commit that!

We've all been there 😖

But it doesn't have to be this way 😮

Let's get to work 😀

Get our files 📂

Get our marks 🔖

Evaluate the results 🔍

Cleanup 🧹

And there you have it 😁

Title: Top 20 JavaScript One-Liners That Don't Actually Work

Callbacks and References: Allowing the Garbage to get Collected

Comparing to lifecycle hooks

DOM is easy: Just make it work like an Array 👍

Extracting a JS library from a snippets repository

Context

How did I do it?

The script

What's on your desk that makes it your desk?