```yaml
---
slug: expo-community-flipper-retired
published: 2023-08-04T18:19:00-07:00
description: Thoughts on "completing" an open source project
excerpt: That moment when you're comfortable putting a temporary project to rest.
changelog: ~
---
```

With [the release of Expo 48](https://blog.expo.dev/expo-sdk-48-ccb8302e231), `expo-community-flipper` (gh)[https://github.com/jakobo/expo-community-flipper] (npm)[https://www.npmjs.com/package/expo-community-flipper] can finally declare its purpose fulfilled. A year ago, I was trying to debug redux inside of the Chrome Debugger and nearly lost my mind. It wasn't just a bad experience. It was an **awful** experience, defined by `console.log` and prayers.

There was [react-native debugger](https://github.com/jhen0409/react-native-debugger) and [reactotron](https://github.com/infinitered/reactotron), but nothing that worked for me specifically. My setup was **weird** but not unlikely. WSL2, Windows 11, and the iOS app running via Expo's custom dev app. Only one thing really worked with this setup, and that was [Flipper](https://fbflipper.com/). Plus, I could finally see FPS information for animations as an added bonus (more on that later).

## Expo & Flipper in a Graph

![Download statistics for expo-community-flipper](https://user-images.githubusercontent.com/1795/222308501-930d3ee3-1121-4895-801d-0c3a544d7f88.png)

One of the problems with using Flipper was that it required editing the Podfile. This is all well and good if you're using react-native on a mac and love running XCode yourself. But if you're that weird-dev-guy with WSL 2, running XCode is ~~impossible~~ legally troublesome at best. As a lucky coincidence, Expo pushed out SDK 43 and began documenting their config plugin system: scriptable JavaScript that could edit & change build files as part of a remote CI or build pipeline.

And so, starting with SDK 43, I released the [first version of expo-community-flipper on npm](https://www.npmjs.com/package/expo-community-flipper/v/43.0.0) into the wild. With every subsequent SDK, I'd check the [expo base template](https://github.com/expo/expo/tree/main/templates/expo-template-bare-minimum/ios) and the [React Native Upgrade Helper](https://react-native-community.github.io/upgrade-helper/) and focus on changes to the `Podfile`.

It was a scramble. It wasn't always obvious _what_ changed. Sometimes a random `AppDelegate.m` was the culprit, other times it was the ruby scripts to include Flipper upstream in the React Native libraries. It got better though with every release.

* [I wrote a post for the Expo team](https://blog.expo.dev/developing-react-native-with-expo-and-flipper-8c426bdf995a) to go along with my WSL 2 article I did earlier for them
* [Alexandre Moureaux hooked performance monitoring in](https://www.youtube.com/watch?v=Yl6gj0ZLB3Y) and gave a talk
* [Abdulrahman wrote an article](https://medium.com/@abdulrahmanhashem/8-ways-to-debug-your-react-native-app-with-expo-the-comprehensive-guide-538655cf1684)

Debugging was finally _easier_. It would just be nice to get out of reaction-mode when new SDKs were imminent.

## Enter the Expo Team and Merging Up

SDK 47 marked the beginning of the end in a positive way. There were changes coming that would break `expo-community-flipper`, and the expo team wanted to be proactive about the changeset. This was the first time in the project's history that `expo-community-flipper` was going to be SDK ready on launch. This proactive outreach got the wheels turning though. What if expo just did the "Flipper bits" itself? They've got a much better testing suite, there are already plugins for modifying the `Podfile`, and then Flipper could get the attention it deserved.

Ideally, SDK 47 would be the last time we'd have to do this npm release dance. After talking with the Expo team, we [launched a plan to merge `expo-community-flipper` upstream](https://github.com/jakobo/expo-community-flipper/issues/41) into the `build-properties` plugin. [It landed in January](https://github.com/expo/expo/pull/20890) and Flipper support became an official part of the `expo-config-build-properties` plugin in SDK 48.

This section is pretty uneventful because the Expo team is just that good. I worked with [Kudo Chien](https://github.com/Kudo) for most of the PR and integration, and Expo had the infrastructure to absorb the changeset without issue. I was honestly impressed at how smooth everything went. I also like the "Why" and "How" sections they encourage on PRs for explaining their changes.

## Ending `expo-community-flipper`

Finally came the goodbyes. A README change, a release on SDK 48 with a `peerDependency` that keeps it from running against newer Expo versions, and an `npm deprecate`. And it was done. With Expo SDK 49 released and deprecating 46, and SDK 50 on the horizon, `expo-community-flipper` will be finally be archived and the project complete.

It's surreal. It feels good. Not many open source projects get a happily ever after.

The End of expo-community-flipper

```yaml
---
slug: tailwind-css-for-email
published: 2022-10-11T15:00:00-07:00
description: While this won't remove your dependency on table tags, at least you can reuse your Tailwind colors and spacing rules in email templates
changelog: ~
---
```

I can no longer count the hours [Tailwind](https://tailwindcss.com) saves me. I don't really _hate_ the state of CSS-in-JS. I just find it gets in the way of quickly saying "make this blue, put it in a flex box oriented by row, with the items centered." It's a preference thing, and my preference is towards utility class names at this point, letting React components do any reusable composition for me. It's been great, save for one quibble; email is awful. It's not really tailwind's fault, but emails are still table-based, inline styles, and generally everything awful we definitely thought we got rid of in 2002.

What follows isn't complex enough to justify an NPM module, but it is a pattern generally usable for getting Tailwind into your HTML emails. The short version is:

1. A very minimal `tailwind.email.css` is generated using the tailwind CLI. It contains `@tailwind utilities;` and any resets I'd like to do. Be sure you add your email templates to tailwind's config file, otherwise your styles won't be included.
2. We put the generated `tailwind.email.css` through a conversion of `rem` to `px` because it's 2022 and [outlook still does not support the `rem` unit](https://www.caniemail.com/features/css-unit-rem/)
3. [juice](https://github.com/Automattic/juice) inlines the tailwind styles for us where possible, keeping the media queries in the head for email clients that support it
4. A [rehype](https://github.com/rehypejs/rehype) pipeline replaces Tailwind `--tw-` variables with their resolved values

## On Generating the HTML
For what I'm currently doing, emails are built using everyday React and a renderer that calls `ReactDOMServer.renderToStaticMarkup(element)`. The complexities of `tr` and `td` nesting is easily hidden behind some common components, which I chose to name `Row` and `Column` respectively. They're nothing fancy and based on the reality we'll probably never get flexbox in HTML emails in my lifetime.

```tsx
const tableAttributes = {
  role: "presentation",
  cellPadding: 0,
  cellSpacing: 0,
};

interface EmailComponentProps {
  className?: string;
}

export const Row: React.FC<PropsWithChildren<EmailComponentProps>> = ({
  children,
  className,
}) => {
  return (
    <table
      {...tableAttributes}
      {...({ border: "0" } as Record<string, string>)}
      className={cx(className, "w-full")}
    >
      <tr>{children}</tr>
    </table>
  );
};

export const Column: React.FC<PropsWithChildren<EmailComponentProps>> = ({
  children,
  className,
}) => {
  return <td className={className}>{children}</td>;
};
```

Ultimately though, how you generate the HTML is up to you, as long as you have it as a string.

## Tailwind Configuration
To make Tailwind email friendly, we need to disable a bunch of core plugins that don't work well across email clients. A huge shoutout goes to [Can I Email](https://www.caniemail.com). Disabling these plugins is straightforward: add them to your theme's definition, and Tailwind will make sure not to generate CSS for them. Trying to use these CSS classes will just result in useless CSS classes with no style information & can be stripped later.

```js
module.exports = {
  content: [
    // put your email paths here
  ],
  theme: {
    corePlugins: {
      preflight: false,
      backgroundOpacity: false,
      borderOpacity: false,
      boxShadow: false,
      divideOpacity: false,
      placeholderOpacity: false,
      textOpacity: false,
    },
  },
  plugins: [],
};

```

## Converting `rem` to `px`

I wasn't keen on building a completely custom `tailwind.config.js` file, and the `rem` unit is easy enough to convert from as long as you specify a base value in pixels. Tailwind [uses a default base](https://tailwindcss.com/docs/customizing-spacing#default-spacing-scale) of `16px`, so we can convert all of our units via a regular expression.

```ts
const css = originalCSS.replace(
  /([\d.-]+rem)/gi,
  (_, value) => `${parseFloat(value.replace(/rem$/, "")) * 16}px`
);
```

## Applying juice

Our stylesheet is now email friendly, and it's time for [juice](https://github.com/Automattic/juice).

> Given HTML, juice will inline your CSS properties into the style attribute.

Cool. That sounds exactly what we're looking to do. We'll take our HTML plus our px-friendly CSS and ask juice to merge the two together into a final output.

```ts
const juiced = juice(html, { extraCss: css });
```

That's mostly it. Juice takes care of the inline style tags for us where it can, defaulting to a `<style>` tag in the head where it can't (ie media queries), and just generally does the right thing all the time. About the only thing it can't do is fix custom CSS variables, but [there's an issue for CSS variable support](https://github.com/Automattic/juice/issues/312) with a workaround. We'll use code similar to the workaround, but with a tool that's a bit faster than cheerio.

## Resolving CSS Variables

Resolving our CSS variables requires us to make a few assumptions about how email clients behave. First, if a client supports advanced CSS such as `@media` queries, they also support CSS variables. That means the only CSS variables we'll need to care about are those located inline and in the body. Second, we can assume that Tailwind isn't going to generate any weird syntax. CSS variables will be in the form of `--declaration: value`, and usage will be in the form of `var(--declaration)` with an optional fallback.

Replacing the variables will require two passes. On the first pass, we'll capture all our CSS variables assigned to the inline style, and on the second, we'll replace our `var()` statements with the resolved values. Using [`rehype`](https://github.com/rehypejs/rehype) and [`rehype-rewrite`](https://github.com/jaywcjlove/rehype-rewrite) makes this a straightforward task.

```ts
const variableDefRegex = /(--[a-zA-Z0-9-_]+)\s*:\s(.+?);/g;
const variableUsageRegex = /var$(\s*--[a-zA-Z0-9-_]+\s*)(?:$|,\s*(.*)\))/;
const hyped = rehype()
  .use(rehypeRewrite, {
    rewrite: (node) => {
      if (node.type !== "element") {
        return node;
      }
      const resolveVariables = (s: string): string => {

        // pass 1: pull definitions
        const defs = new Map<string, string>();
        let withoutDefs = s.replace(
          variableDefRegex,
          (_, def: string, value: string) => {
            defs.set(def.trim(), value.trim());
            return "";
          }
        );

        // pass 2: replace variables (maxCycles prevents Terrible Things from happening)
        let maxCycles = 1000;
        while (withoutDefs.match(variableUsageRegex)) {
          maxCycles--;
          if (maxCycles <= 0) {
            throw new Error("Max Cycles for replacement exceeded");
          }
          withoutDefs = withoutDefs.replace(
            variableUsageRegex,
            (_, def: string, fallback: string) => {
              const d = def.trim();
              if (defs.has(d)) {
                return defs.get(d) ?? "";
              }
              return (fallback ?? "").trim();
            }
          );
        }

        // return clean result
        return withoutDefs;
      };
      node.properties = {
        ...node.properties,
        style: resolveVariables(`${node.properties?.style ?? ""}`),
      };
    },
  })
  .use(stringify)
  .processSync(juiced)
  .toString();
```

## Wrapping Up

At this point, I'm pretty happy with where the code is. The generated tailwind output from the email.css is easy to understand and manage since it's just vanilla tailwind. Juice is doing what it does best, and the only manual adjustments in the code are converting the `rem` to `px` and fixing of inline CSS variables. That's a really small amount of maintained code relative to an email specific library and build system in exchange for the full power of Tailwind. Emails still suck, but hopefully they'll suck a little less. With the Libraries in place, we put together the Taskless Usage in about 20 minutes.

![image](https://user-images.githubusercontent.com/1795/193527500-a0ada56c-272b-4809-b886-8f112312ef5e.png)

And the associated code:

```ts
/* mailwindCss.ts */
import { readFile } from "node:fs/promises";
import juice from "juice";
import { rehype } from "rehype";
import rehypeRewrite from "rehype-rewrite";
import stringify from "rehype-stringify";

/** Cache of compiled tailwind files */
const twcCache = new Map<string, Promise<string>>();

/**
 * Originally based on The MailChimp Reset from Fabio Carneiro, MailChimp User Experience Design
 * More info and templates on Github: https://github.com/mailchimp/Email-Blueprints
 * http://www.mailchimp.com &amp; http://www.fabio-carneiro.com
 * These styles are non-inline; they impact UI added by email clients
 * By line:
 * (1) Force Outlook to provide a "view in browser" message
 * (2) Force Hotmail to display emails at full width
 * (3) Force Hotmail to display normal line spacing
 * (4) Prevent WebKit and Windows mobile changing default text sizes
 * (5) Remove spacing between tables in Outlook 2007 and up
 * (6) Remove table borders on MSO 07+ http://www.campaignmonitor.com/blog/post/3392/1px-borders-padding-on-table-cells-in-outlook-07/
 * (7) Specify bicubic resampling for MSO on img objects
 * (8) Media Query block - Pretty phone numbers in email: http://www.campaignmonitor.com/blog/post/3571/using-phone-numbers-in-html-email
 * (9) Media Query block - same as above, but for tablet sized devices
 */
const universalStyles = /*css*/ `
  #outlook a{ padding:0; }
  .ReadMsgBody{ width:100%; } .ExternalClass{ width:100%; }
  .ExternalClass, .ExternalClass p, .ExternalClass span, .ExternalClass font, .ExternalClass td, .ExternalClass div { line-height: 100%; }
  body, table, td, p, a, li, blockquote{ -webkit-text-size-adjust:100%; -ms-text-size-adjust:100%; }
  table, td{ mso-table-lspace:0pt; mso-table-rspace:0pt; }
  table td {border-collapse: collapse;}
  img{-ms-interpolation-mode: bicubic;}
  @media only screen and (max-device-width: 480px) {
    a[href^="tel"],
    a[href^="sms"] {
      text-decoration: default !important;
      pointer-events: auto !important;
      cursor: default !important;
    }
  }
  @media only screen and (min-device-width: 768px) and (max-device-width: 1024px) {
    a[href^="tel"],
    a[href^="sms"] {
      text-decoration: default !important;
      pointer-events: auto !important;
      cursor: default !important;
    }
  }
`;

/**
 * Inline reset styles
 * These set common defaults for a consistent UI. Their comments will be automatically stripped by juice
 */
const resetStyles = /*css*/ `
  /* default margin/padding, box sizing*/
  * { margin: 0; padding: 0; box-sizing: border-box; }
  /* height 100% all the way down */
  table, tr, td {height: 100%;}
  /* img behavior - bicubic ms resizing, no border, fix space gap on gmail/hotmail */
  img { outline: none; text-decoration: none; -ms-interpolation-mode: bicubic; display: block; }
  a img { border: none; }
  /* mso 07, 10 table spacing fix http://www.campaignmonitor.com/blog/post/3694/removing-spacing-from-around-tables-in-outlook-2007-and-2010 */
  table { border-collapse: collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt;}
  /* tel/sms links are unstyled by default */
  a[href^="tel"], a[href^="sms"] { text-decoration: none; pointer-events: none; cursor: default; }
`;

const variableDefRegex = /(--[a-zA-Z0-9-_]+)\s*:\s(.+?);/g;
const variableUsageRegex = /var$(\s*--[a-zA-Z0-9-_]+\s*)(?:$|,\s*(.*)\))/;

/** Juices the styles, and then resolves CSS variables and additional HTML adjustements via rehype */
const inlineStyles = (html: string, css?: string) => {
  const juiced = juice(html, { extraCss: css });
  const hyped = rehype()
    .use(rehypeRewrite, {
      rewrite: (node) => {
        if (node.type !== "element") {
          return node;
        }

        // inline styles into the <head>
        if (node.tagName === "head") {
          node.children = [
            ...node.children,
            {
              type: "element",
              tagName: "style",
              children: [{ type: "text", value: universalStyles }],
            },
          ];
        }

        const resolveVariables = (s: string): string => {
          // pass 1: pull definitions
          const defs = new Map<string, string>();
          let withoutDefs = s.replace(
            variableDefRegex,
            (_, def: string, value: string) => {
              defs.set(def.trim(), value.trim());
              return "";
            }
          );

          // pass 2: replace variables
          let maxCycles = 1000;
          while (withoutDefs.match(variableUsageRegex)) {
            maxCycles--;
            if (maxCycles <= 0) {
              throw new Error("Max Cycles for replacement exceeded");
            }
            withoutDefs = withoutDefs.replace(
              variableUsageRegex,
              (_, def: string, fallback: string) => {
                const d = def.trim();
                if (defs.has(d)) {
                  return defs.get(d) ?? "";
                }
                return (fallback ?? "").trim();
              }
            );
          }

          // return clean result
          return withoutDefs;
        };
        node.properties = {
          ...node.properties,
          style: resolveVariables(`${node.properties?.style ?? ""}`),
        };
      },
    })
    .use(stringify)
    .processSync(juiced)
    .toString();
  return hyped;
};

interface MailwindOptions {
  /** A path to your tailwind.css file, optimized for email */
  tailwindCss: string;
  /** The base px value for 1rem, defaults to 16px */
  basePx?: number;
  /** Set to `false` to disable extended resets */
  reset?: boolean;
}

const mailwindCss = async (email: string, options: MailwindOptions) => {
  const basePx = options?.basePx ?? 16;

  // cache promise for performance in serverless environments
  if (
    !twcCache.has(options.tailwindCss) ||
    process.env.NODE_ENV === "development"
  ) {
    // console.log("loading styles");
    const p = new Promise<string>((resolve, reject) => {
      readFile(options.tailwindCss)
        .then((buf) => {
          const s = buf.toString();
          // rem to px
          const pxed = s.replace(
            /([\d.-]+rem)/gi,
            (_, value) => `${parseFloat(value.replace(/rem$/, "")) * basePx}px`
          );
          resolve(pxed);
        })
        .catch((reason) => reject(reason));
    });
    twcCache.set(options.tailwindCss, p);
  }

  const s = await twcCache.get(options.tailwindCss);
  if (typeof s === "undefined") {
    throw new Error(`Could not load tailwind css from ${options.tailwindCss}`);
  }

  return inlineStyles(
    email,
    options.reset === false ? s : [resetStyles, s].join("\n")
  );
};

export default mailwindCss;
```


Tailwind CSS for Email

```yaml
---
slug: time-based-queues-serverless-docmq
published: 2022-08-31T12:39:00-07:00
description: Nerding out on time-ordered priority queues
changelog: ~
---
```

Building a [serverless-friendly queue system](https://taskless.io) continues to be an adventure. Recently, we had to say goodbye to our Redis queues and replace them with something more durable. The journey there involved a lot about time storage, visibility windows, and how the most popular queue solutions solve these problem. So, if you were curious what makes Taskless reliable, the short answer is a database optimized for time-based queries. For a longer answer, we need to go on a journey.

## First, it's Time for Events

The first rule of the JAMStack is that everything is an event. Because servers aren't standing by and waiting for your every request, events are the only way for a serverless provider to know your code needs to run. In practical terms, when you make a request to a Next.js app or AWS lambda, that small chunk of code is invoked in response to the URL request, executed, sends the reply, and then shuts down. This is well and good for operations like "forward this blog post to a friend" or "leave a comment about how you definitely wouldn't forward this blog post to a friend," given both examples begin with an obvious interaction. But what about an operation like "send this to my inbox tomorrow morning"?

It turns out, time ruins everything.

Time sucks, and if you don't believe me, go [read Zack Holman's excellent piece on the matter](https://zachholman.com/talk/utc-is-enough-for-everyone-right) and return once you've come to a similar conclusion. Now that we agree the concept of time was a mistake, let's talk about sending something to your inbox "tomorrow". To avoid headaches, we're going to make some poor assumptions about what tomorrow means. In Luxon, we can express this arbitrary definition of "tomorrow" as `DateTime.now().zone("America/Los_Angeles").plus({days: 1}).startOf("day").set({hour: 8})`. Bam. 8am "tomorrow" at of this exact moment. All we need to do is "event" at that time, and we're set!

## Store the Time in the Queue Itself - aka The SQS Experiment

The purest of serverless ambitions would be to never persist anything under our ownership. To that end, [Amazon SQS](https://aws.amazon.com/sqs/) and lambdas are an excellent fit. The platform has limitations, but those could be worked around with a bit of duct tape.

First, the maximum delay on a lambda is 15 minutes, so SQS would need to send the job to a lambda at the end of the maximum delay, which would only report success if it could requeue the job for another 15 minutes. We'd repeat this ad-nauseum until we reached our magical "8am tomorrow" requirement and then run our job.

This worked really well (and was insanely cheap). Each job would require a maximum of 96 SQS calls per day in a pending state, and it's only $0.50 per million requests. That's 10,000 jobs per month, delaying every job up to a maximum of one day, with just AWS tools. In practice, the system has a lot of opportunity to fail. Specifically 672 opportunities for every day the job sits in SQS and must be constantly requeued,

Honestly, if SQS didn't have an arbitrary 15 minute delay, we'd be done. But it doesn't so we're not.

## Tables, Indexed by Time

It turns out that databases are really good at time stuff, and not just because [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) is both readable and easy to sort by. But also because really smart people made time (and its storage) one of the primitives in their db systems.

Databases are also really good and indexing non-time things. So imagine you have a table

| column | type |
| :--- | :--- |
| id | any |
| failed | boolean = false |
| visible | time, nullable |
| deleted | time, nullable |
| ack | any, nullable, unique (on non-null) |
| payload | text, nullable |

Now it's easy to describe the operations in order to take, process, and report on jobs.

* Your next jobs are at `visible <= now() AND deleted IS NULL`
* Your failed jobs are at `deleted IS NOT NULL AND failed = TRUE`
* Your completed jobs are at `deleted IS NOT NULL AND failed = FALSE`
* You can retry a job by changing its `visible` time
* You can complete/fail a job by setting `deleted` and `failed` in the same transaction
* A unique `ack` value lets you find a single job in the table so that you are complete/fail/retrying only one specific job

As an added bonus, using just-a-database means that we have separated our queue (what do we need to run) from our worker (the actual running). The pattern was simple enough that I bundled it up as [DocMQ](https://github.com/jakobo/docmq). It has a persistent worker if that's something you want, or you can just run DocMQ for adding jobs to your queue database and process them on your own time.

## Time to Return to Events

The beautiful part about using a database is that once it's in the database, it's _there_. We don't need persistence unless we want it, and polling is good enough for most use cases. All we need to do is poll in response to an event; that event is _time itself changed_. 🤯

Stick with me here. Imagine if we have a cron job via [Netlify Scheduled Functions](https://docs.netlify.com/netlify-labs/experimental-features/scheduled-functions/) or [lambda cron](https://docs.aws.amazon.com/lambda/latest/dg/services-cloudwatchevents-expressions.html) that runs once per minute (or per-second if you'd like to YOLO). A single query tells you what capacity you need:

```sql
SELECT count(*) FROM your_table WHERE visible <= now() AND deleted IS NULL
```

You get 20 rows back, spin up 20 serverless functions, each to claim 1 row:

```sql
UPDATE your_table SET ack = gen_random_uuid(), visible = visible + interval '30 seconds'
WHERE visible <= now() AND deleted IS NULL
LIMIT 1
```

💥Instant scalability. If you need more granularity, tighten the cron. If you need sub-second control then you probably do want a server. Real talk though, if you're sending emails the latency isn't your job system.

## How This Relates to Taskless

At [Taskless](https://taskless.io) we ran on the cron job / polling design until we were invoking an unreasonable number of serverless functions on the minute and customers wanted sub-minute responses. Since our scheduled function infrastructure didn't let us go to per-second, we switched to persistence. In short, we ran the servers so you could go 100% serverless. 🎉

Because [DocMQ](https://github.com/jakobo/docmq) is on GitHub, you can replicate it yourself. There's even a [postgres prototype](https://github.com/jakobo/docmq/tree/labs-postgres) that will get merged down soon in case you're a fan of Neon, Supabase, or other serverless-friendly postgres instances.

### Some Quick Answers

Added because these came up in casual conversation

* Does the DB matter? - No, as long as your DB understands time
* Biggest drawback? - Performance. A relational db will be slower than an in-memory solution in almost every use case. Unless you're building a real-time application such as chat, the latency of a DB touching disk is not going to be why things are slow
* What DB does Taskless use? - We use MongoDB Atlas currently. We like their time series support



Hey 👋🏼, I’m Jakob

The End of expo-community-flipper

Tailwind CSS for Email

Designing A Time-Based Queue for Serverless