Skip to content

Instantly share code, notes, and snippets.


Sunil Pai threepointone

View GitHub Profile
threepointone /
Last active Oct 25, 2020
Notes on Durable Objects. Part 1 - Migrations.

Note: Since writing this, I've been pointed to some exciting new research/tooling called Project Cambria I'll likely have to rewrite this article taking that into account. Leaving this up for posterity's sake.

(This series isn't meant to be a primer/tutorial, though we might do something regarding it in the future. For official documentation and starters, see

Further - these are my personal views; I expect to be wrong about a lot of them. Indeed, I'm not paying much attention to presenting these well at the moment, simply writing down thoughts. As such, expect these writeups to change often, particularly as the platform takes shape. I'm also mostly a front end guy, so don't get mad if I get it very wrong. Give me feedback! Always happy to learn and make changes.)

Durable Objects are a fascinating new storage primitive from cloudflare for their workers platform. There's a lot of 'cool'

View something.test.ts
import tree from "./tree";
test("it should serialise the tree", () => {
expect(tree("path/to/folder")).toMatchInlineSnapshot(); // jest will fill this in automatically
threepointone /
Last active Oct 25, 2020
Feature flags: why, how, all that

(I'm enjoying doing these raw, barely edited writeups; I hope they're useful to you too)

Feature flags

This is my own writeup on feature flags; for a deep dive I'd recommend something like Martin Fowler's article (

So. Feature flags. The basic idea that you'll store configuration/values on a database/service somewhere, and by changing those values, you can change the user experience/features for a user on the fly.

Let's say that you're building a new feature, called 'new-button' which changes the color of buttons, which is currently red, to blue. Then you'd change code that looks like this -


(This is a draft for something I'm writing internally but figured it would be useful for everyone.)

tl;dr -

  • make sure git --version returns 2.27.0 or higher.
  • git clone --filter=blob:none --sparse <repo> --depth=1
  • cd <repo>
  • git sparse-checkout set <path> <path> <...path>

View download-zoia-patches.js
import "isomorphic-fetch";
import https from 'https'
import fs from 'fs'
async function get(url) {
return await (
await fetch("" + url)
View console-function-names.js
const bypass = [
// function names to avoid logging
const collapsed = [
// function names to groupCollapsed
module.exports = function(babel) {
const { types: t } = babel;
const wrapFunctionBody = babel.template(`{
threepointone /
Last active Aug 4, 2020
Ember's settled() test helper, for React


Stealing an idea from ember's settled test helper.

Assuming these conditions are true in your unit tests -

  • you're using Jest
  • and Jest's fake timers
  • and all your data requests are happening via fetch
threepointone / count-alts.js
Created May 15, 2019
count the number of images with alts on a page
View count-alts.js
function count(){
const images = [...$('.stream-item img')].filter(x => {
let classList = [...x.classList]
return !(classList.includes('avatar') || classList.includes('avatar--circular') || classList.includes('Emoji'))
const alts = => x.alt).filter(x => !!x)
return Math.ceil(alts.length/images.length*100) + '% coverage'

good doc! some quick answers -

It seems like act() is being recommended for wrapping all state updates in React tests, but is it necessary to use it everywhere if you can use waitForElement to turn the whole test async?

This is a very good question, and something I grappled with earlier. A couple of things that stood out for me -

  • waiting for an element is indeed pretty close to what a user's experience is like; ie - a user 'waits' for the form to show itself, after which they fill it in and click a button, then 'wait' for the success screen etc. Ultimately, act() makes this test stronger - it'll ensure that effects, and queued promises, have been flushed before you interact with the element. wrapping waitForElement with act() (the async version, ie), will make this invisible to the user, but with the guarantee that their UI is 'stable'.

  • I couldn't assume that all tests would use waitForElement. For example, using timers is common for testing transitions and such. In these scenarios too, ac


‪“‬In what way is JS any more maintainable than CSS? How does writing CSS in JS make it any more maintainable?”

‪Happy to chat about this. There’s an obvious disclaimer that there’s a cost to css-in-js solutions, but that cost is paid specifically for the benefits it brings; as such it’s useful for some usecases, and not meant as a replacement for all workflows. ‬

‪(These conversations always get heated on twitter, so please believe that I’m here to converse, not to convince. In return, I promise to listen to you too and change my opinions; I’ve had mad respect for you for years and would consider your feedback a gift. Also, some of the stuff I’m writing might seem obvious to you; I’m not trying to tell you if all people of some of the details, but it might be useful to someone else who bumps into this who doesn’t have context)‬

So the big deal about css-in-js (cij) is selectors.

You can’t perform that action at this time.