DEV Community: DevSnack

Building a token layer Material 3 actually respects

DevSnack — Tue, 18 Aug 2026 14:58:13 +0000

MaterialTheme takes three things: a ColorScheme, a Typography, and a Shapes. Your design system almost certainly has more than three things in it — a spacing scale at minimum, probably elevation semantics, maybe a density knob — so at some point you write a layer that carries the rest.

That layer is about forty lines. Three of the decisions inside it are the kind you discover you got wrong six months later, and one of them I did get wrong, in code that's published on Maven Central right now. This is the walkthrough I wanted when I wrote FormaUI's.

What you're actually filling in

Worth being precise about the gap, because it's smaller than the discourse suggests. MaterialTheme handles colour, type and corners properly — those are genuinely themeable and genuinely inherited. What it has no concept of is spacing (no dimension tokens at all; every component's padding is a private constant in androidx), elevation as a semantic (per-component defaults exist, but there's no theme.elevation.raised to point at), density, and anything domain-specific — chart series colours, a success role, a tabular-numeral text style.

So the layer's job is narrow: carry the tokens M3 doesn't model, and make sure the tokens M3 does model are actually reaching it. Both halves matter, and the second one is where most hand-rolled layers quietly fail.

The shape of it

Three pieces: composition locals to hold the values, a wrapper that provides them, an object to read them back.

internal val LocalFormaSpacing = staticCompositionLocalOf { FormaSpacing() }
internal val LocalFormaShapes = staticCompositionLocalOf { FormaShapes() }
internal val LocalFormaTypography = staticCompositionLocalOf { FormaTypography() }

@Composable
fun FormaTheme(
    colorScheme: FormaColorScheme = FormaTheme.defaultColorScheme(),
    typography: FormaTypography = FormaTheme.defaultTypography(),
    shapes: FormaShapes = FormaTheme.defaultShapes(),
    dynamicColor: Boolean = false,
    darkTheme: Boolean = isSystemInDarkTheme(),
    content: @Composable () -> Unit,
) {
    val dynamicScheme = if (dynamicColor) dynamicColorSchemeOrNull(darkTheme) else null
    val resolvedColorScheme = dynamicScheme
        ?: if (darkTheme) colorScheme.dark else colorScheme.light

    CompositionLocalProvider(
        LocalFormaSpacing provides FormaSpacing(),
        LocalFormaShapes provides shapes,
        LocalFormaTypography provides typography,
    ) {
        MaterialTheme(
            colorScheme = resolvedColorScheme,
            shapes = shapes.material,
            typography = typography.material,
            content = content,
        )
    }
}

That's the whole wrapper. The interesting parts are staticCompositionLocalOf, shapes.material, and one line that's a bug.

Decision 1: static or dynamic local?

compositionLocalOf tracks reads. Change the provided value and Compose recomposes exactly the composables that read it. staticCompositionLocalOf does not track reads — it's cheaper to read, and the price is that changing the provided value invalidates the entire content lambda beneath the provider.

For theme tokens, static is the right call, and the reason is a question about your app rather than about Compose: how often does this value change? A theme's tokens change essentially never — once at startup, maybe again when the user flips dark mode, which is a full-screen repaint anyway. Paying read-tracking overhead on every FormaTheme.spacing.md in the tree to optimise a transition that already redraws everything is the wrong trade.

It becomes the wrong call the moment a token is genuinely dynamic. If you ship a compact/comfortable density switch that users toggle in a settings sheet, or a per-screen spacing override, a static local means every toggle re-runs your whole app's composition. That's the case for compositionLocalOf, and it's worth knowing which of the two you signed up for before the feature request arrives.

Both of Material's own theme locals are static, for the same reason.

Decision 2: hand your tokens to `MaterialTheme` as well

This is the half people skip, and it's the one that decides whether the app looks designed or half-migrated.

Your components read FormaTheme.shapes.lg and get 12dp corners. Fine. But your app also contains M3 components you never wrapped — a DropdownMenu, an AlertDialog, a Surface someone reached for directly — and those read MaterialTheme.shapes. If you only provide your own local, those keep M3's stock 12dp/16dp/28dp and your carefully tightened corners stop at the boundary of your own component set.

So the token class exposes a translation:

@Immutable
class FormaShapes(
    val none: CornerBasedShape = RoundedCornerShape(0.dp),
    val xs: CornerBasedShape = RoundedCornerShape(4.dp),
    val sm: CornerBasedShape = RoundedCornerShape(6.dp),
    val md: CornerBasedShape = RoundedCornerShape(8.dp),
    val lg: CornerBasedShape = RoundedCornerShape(12.dp),
    val xl: CornerBasedShape = RoundedCornerShape(16.dp),
    val pill: CornerBasedShape = CircleShape,
    val full: CornerBasedShape = CircleShape,
) {
    val material: Shapes = Shapes(
        extraSmall = xs,
        small = sm,
        medium = md,
        large = lg,
        extraLarge = xl,
    )
}

Eight tiers down to M3's five slots:

Your tier	Value	M3 slot	M3 stock value
xs	4dp	extraSmall	4dp
sm	6dp	small	8dp
md	8dp	medium	12dp
lg	12dp	large	16dp
xl	16dp	extraLarge	28dp
none, pill, full	0dp / pill / pill	—	no slot

Two things fall out of that table. The first is that the mapping is lossy in both directions — you have tiers M3 has nowhere to put, and a semantic disagreement in the middle where your md is a control corner and M3's medium is a card corner. Pick which of your tiers is the least-wrong fit for each slot, then write the mapping down where someone can read it, because the next person will assume it's identity.

The second is that a stock DropdownMenu inside this theme comes out at 8dp instead of 12dp. That's not a leak; it's the entire point. Do the same for typography — a Typography handed to MaterialTheme — and every un-wrapped Text in your app inherits your type scale for free.

Decision 3: the accessor object, and `@ReadOnlyComposable`

The read side mirrors Material's MaterialTheme object convention, so it's already familiar:

object FormaTheme {
    val spacing: FormaSpacing
        @Composable @ReadOnlyComposable
        get() = LocalFormaSpacing.current

    val shapes: FormaShapes
        @Composable @ReadOnlyComposable
        get() = LocalFormaShapes.current
}

@ReadOnlyComposable is the part worth understanding rather than copying. It asserts to the compiler that this composable only reads — emits no nodes, introduces no group of its own — which lets Compose generate a cheaper call with no recompose scope attached. For a getter that returns SomeLocal.current it's free performance and exactly correct.

It's also a promise you can break silently, because putting a remember inside one is a lie about group structure that nothing will flag. The rule I use: if the getter's body is a .current, a constant, or arithmetic over those, annotate it. If it contains remember, LaunchedEffect, or anything that emits, don't.

The same annotation is what makes per-component defaults work as theme reads:

object FormaButtonDefaults {
    val shape: Shape
        @Composable @ReadOnlyComposable
        get() = FormaTheme.shapes.md
}

Which, incidentally, is the fix for M3's button shape not being themeable — ButtonDefaults.shape resolves to a hardcoded CircleShape rather than reading MaterialTheme.shapes. I wrote about that in more detail in the token-by-token comparison; the short version is that a default declared as a theme read is themeable and a default declared as a constant is not, and that distinction is most of what an opinionated layer is for.

What I got wrong: allocating tokens inside the provider

Look at that provider again:

CompositionLocalProvider(
    LocalFormaSpacing provides FormaSpacing(),   // ← new instance, every time
    LocalFormaShapes provides shapes,
    LocalFormaTypography provides typography,
) { … }

FormaSpacing() constructs a fresh object on every composition of FormaTheme. FormaSpacing is annotated @Immutable — but @Immutable is a promise to the compiler about mutation, not a generated equals. It's a plain class, so equality is identity, so every one of those fresh instances compares unequal to the last one.

Provide a changed value to a static local and the entire content lambda beneath it is invalidated. Which means: every recomposition of FormaTheme recomposes the whole app underneath it, forever, because of a constructor call in an argument list.

defaultShapes() has the same shape of mistake — fun defaultShapes(): FormaShapes = FormaShapes(), a new instance per call, used as a parameter default. Typography got it right, and the contrast is instructive:

@Composable
internal fun rememberBrandTypography(): FormaTypography {
    val family = rememberPublicSansFamily()
    return remember(family) { … }
}

That one is remembered, so it's the same instance across recompositions, so providing it is a no-op after the first pass. One of three tokens got the treatment all three needed.

How much does it actually cost? In the common case, close to nothing — and I'd rather say that than oversell my own bug. FormaTheme normally sits at the app root where its arguments are stable and isSystemInDarkTheme() flips maybe twice a day, so it seldom recomposes and the invalidation seldom fires. The case where it hurts is a FormaTheme nested inside a subtree that recomposes often, which is a legitimate thing to do for a themed section of a screen and is exactly where nobody would think to look for the cause.

The fixes are boring, which is the tell that the original code was carelessness rather than a trade-off: hoist the default to a top-level private val (or remember it) so one instance exists for the process, and give the token classes equals/hashCode — a data class, or @Immutable plus a hand-written pair — so even a fresh instance compares equal to the old one and the provider stops churning.

The general lesson, and the reason I'm writing it down: @Immutable and @Stable describe how a type behaves, not how it compares. Compose's skipping logic runs on equals. A token class without one reports "I changed" every time you build a new one, and a composition-local provider is the place where that becomes a whole-subtree cost instead of a single wasted recomposition.

If you're auditing your own layer today, that's the one-line check: are your token classes data classes, and is the instance you provide the same instance you provided last frame?

The limitation I can't design around

FormaTheme takes colorScheme, typography and shapes. It does not take spacing, and LocalFormaSpacing is internal. So FormaUI's 4dp grid — xxs 4, xs 8, sm 12, md 16, lg 24, xl 32, xxl 48, section 96 — is a fixed contract. You can read it. You cannot replace it.

FormaSpacing's own KDoc says "Every value is overridable; construct a custom FormaSpacing to retune the rhythm." You can construct one. There is no way to install it. That sentence is wrong, it's mine, and it's the sort of thing that only gets found when someone tries.

How it happened is ordinary and probably instructive. The hard requirement was that no component hardcode a dp value, which needs the scale to be ambient. Making it configurable was a separate piece of work with no internal customer, so it didn't ship. Ambient-but-fixed is a coherent stopping point that reads, from outside, like an oversight — because it is one.

If your product needs a 5dp or 10dp rhythm, that's a real reason to write your own layer instead of adopting this one, and I'd rather you knew before the dependency than after.

The checklist

If you're writing this layer today:

Static locals for tokens that never change; dynamic locals for anything a user can toggle. Decide deliberately — the failure mode is invisible until it's a jank report.
Provide your tokens to MaterialTheme too, or un-wrapped M3 components keep Google's defaults inside your app.
Write the tier→slot mapping down. It's lossy and nobody will guess it.
data class your token classes, and provide a stable instance. It's what stops a static local from invalidating your whole tree.
@ReadOnlyComposable on every pure token getter, and nowhere else.
Make every token a constructor parameter from day one, even ones nobody's asked to override. Retrofitting one changes a public signature, and by then people are calling it.

Colour, type and corners you get from Material for free if you wire them up. Everything else is yours, and the layer is short enough that the only real risk is being casual with it.

FormaUI is an opinionated Material 3 component library for Jetpack Compose — 40 components with the design work already done. The theme layer described here is dev.formaui:core; every token is documented on the theming page, and you can try the components live in your browser. Every API is @ExperimentalFormaUiApi pre-1.0, including the spacing gap above.

The press animation that never plays on a fast tap

DevSnack — Tue, 18 Aug 2026 14:57:17 +0000

FormaUI's buttons dip 3% when you press them. It's a small thing — a scale to 0.97 layered over the Material ripple — and the first implementation was two lines and obviously correct.

It worked in the interactive preview. It worked when I held a button down. It did nothing whatsoever when anyone tapped one, which is the only way anyone uses a button.

The version that looks right

Here it is, and I'd guess most Compose codebases contain something very close:

val pressed by interactionSource.collectIsPressedAsState()
val scale by animateFloatAsState(if (pressed) 0.97f else 1f)

Modifier.graphicsLayer {
    scaleX = scale
    scaleY = scale
}

Three idiomatic APIs, no cleverness, reads like a sentence. Hold the button and it dips exactly as intended. Tap it and you get a flicker of maybe a third of a percent, which on a real screen is indistinguishable from nothing.

Why: `animateFloatAsState` retargets, it doesn't queue

A tap is two interactions a few tens of milliseconds apart: PressInteraction.Press, then PressInteraction.Release.

animateFloatAsState is a single animation whose target you change. Press sets the target to 0.97 and the animation starts moving. Release sets it back to 1.0 — and retargeting doesn't restart or finish anything, it redirects the in-flight animation from wherever it currently is, preserving velocity. On a fast tap "wherever it currently is" is a couple of frames into a 3% journey. The animation dutifully turns around and goes home, having travelled almost no distance.

Springs make it worse in a way that's easy to miss: a spring approaches its target asymptotically and stops within a visibility threshold, so there is no moment where the value is 0.97 and could be observed. There's no "the dip happened" state to preserve, because the dip is an approach rather than an arrival.

None of this is a bug in animateFloatAsState. It is precisely correct for a value that tracks state — a colour that follows selection, a chevron rotation that follows expanded/collapsed. If the state flips back before the animation lands, cutting it short is what you want; the user changed their mind and the UI should follow.

A press dip isn't that. It's an acknowledgement of an event. The user tapped; the interface owes them a confirmation that it noticed; the confirmation has a minimum legible duration regardless of how fast they lifted their finger. Modelling an event as a state and interpolating toward it is the whole mistake, and it took me embarrassingly long to see because the code reads so well.

The reframe: a queue of events

val scale = remember { Animatable(1f) }

LaunchedEffect(interactionSource, pressedScale, downAnimationSpec, animationSpec) {
    interactionSource.interactions.collect { interaction ->
        when (interaction) {
            is PressInteraction.Press ->
                scale.animateTo(pressedScale, downAnimationSpec)

            is PressInteraction.Release, is PressInteraction.Cancel ->
                scale.animateTo(1f, animationSpec)
        }
    }
}

return graphicsLayer {
    scaleX = scale.value
    scaleY = scale.value
}

The load-bearing word is collect, and it isn't doing anything animation-specific.

Flow.collect's body is a suspend function, and a flow will not emit its next value until the current invocation of that body returns. Animatable.animateTo suspends until its animation finishes. Put those two facts together: a Release that arrives while the dip is still playing cannot be handled until the dip completes. It waits its turn in the collector, then the spring-back plays from the fully-dipped position.

The dip always plays in full — not because of a special case or a minimum-duration guard, but because sequential collection is what collect means. The mechanism transfers, which is why it's worth remembering: any "this feedback must complete even if the state that triggered it is already gone" problem has the same shape, and the answer is a queue of events rather than a function of state.

Animatable rather than animateFloatAsState because we now need to drive the animation from a coroutine and observe its completion, which is exactly the boundary between those two APIs.

Two specs, not one

Guaranteeing the dip plays in full has an immediate consequence: the dip's duration is now a floor on how long the whole interaction takes. A bouncy 400ms spring on the way down means every tap feels like the button is thinking about it.

So the motion is split, and the two halves want opposite things:

Phase	Spec	Why
Press dip	`tween(100ms, FastOutSlowInEasing)`	Deterministic and short. It runs under the finger where the user is already looking, and it's the part that can't be interrupted, so it has to be cheap.
Release	`spring(DampingRatioLowBouncy, StiffnessMedium)`	This one can be as expressive as you like — nothing is waiting behind it. The slight overshoot is what makes the release read as springy rather than mechanical.

A fixed tween on the way down and a bouncy spring on the way back was not the first thing I'd have guessed. It came out of the constraint rather than taste, which is usually a sign a decision is right.

One more case in that when: PressInteraction.Cancel shares the release path. A press that turns into a scroll emits Cancel, not Release, and if you only handle Release the element stays shrunk permanently. That's a bug you find on a list, not on a demo screen.

Why `graphicsLayer`, and why the lambda form

Two separate traps live here.

Don't animate size. The tempting alternative is to shrink the element for real — animate a padding, a heightIn, a requiredSize. Do that and the measured bounds shrink with the visual, which means the touch target shrinks mid-gesture. FormaUI enforces a 48dp minimum on every button; an animation that quietly violates it during the exact moment the user is touching it would be a genuinely bad accessibility bug, and it would never show up in a screenshot test. graphicsLayer transforms at draw time, so the measured size — and the 48dp floor — is untouched:

val buttonModifier = modifier
    .heightIn(min = FormaButtonDefaults.MinTouchTargetSize)   // 48.dp, measured
    .formaPressScale(interactionSource, pressedScale, pressAnimationSpec)  // draw-time only

Read the animated value inside the lambda. These two lines are not equivalent:

graphicsLayer(scaleX = scale.value, scaleY = scale.value)  // recomposes every frame
graphicsLayer { scaleX = scale.value; scaleY = scale.value } // draw-time read

The first reads scale.value during composition, so every frame of the animation invalidates the composable. The second defers the read into the layer block, which runs at draw — so a 60fps animation costs zero recompositions. The lambda overload of graphicsLayer exists for precisely this, and it's a free win on any animated transform.

Observe-only, which is the harder API decision

The modifier takes an InteractionSource, not a MutableInteractionSource, and it never detects input:

@Composable
fun Modifier.formaPressScale(
    interactionSource: InteractionSource,
    pressedScale: Float = FormaPressScaleDefaults.PressedScale,
    downAnimationSpec: FiniteAnimationSpec<Float> = FormaPressScaleDefaults.DownAnimationSpec,
    animationSpec: FiniteAnimationSpec<Float>? = FormaPressScaleDefaults.AnimationSpec,
): Modifier

It watches someone else's press interactions. The caller has to hand it the same source the element's clickable emits into — the pattern Modifier.indication already established:

val interactionSource = remember { MutableInteractionSource() }
Box(
    Modifier
        .formaPressScale(interactionSource)
        .clickable(interactionSource = interactionSource, indication = ripple()) { … }
)

Detecting presses inside the modifier would have been a friendlier API — one argument fewer, nothing to wire up. It would also mean two independent gesture detectors on the same element, racing the ripple and double-counting a press. Observe-only is the correct decision, and it's worth being honest that it comes with the worst class of failure mode: pass two different sources and you get silence, not an error.

Inside a component you own, the wiring is one line and invisible to your users — FormaButton remembers a source, hands it to formaPressScale, and passes the same one down to the underlying M3 button. Exposing the modifier publicly means exposing the footgun; I'd rather ship the reusable primitive and document the trap than hide it and re-implement the animation in five components.

The animationSpec = null escape hatch returns the receiver unchanged, so disabling it adds no modifier nodes at all rather than a node that animates to 1.0.

Testing an animation nothing can see

Here's the part that connects to an earlier post about Canvas tests: the scale lives in a graphicsLayer. It is not in the semantics tree. There is no assertion that reads it. You cannot test the value.

So don't test the value — test the regression class. The bug was "a fast tap skips the dip," which means the thing to reproduce is the interleaving, not the pixels:

@Test
fun quickTap_playsFullDipAndSettles() {
    // …setContent with a clickable Box carrying formaPressScale…

    // Pause the clock so Release is guaranteed to arrive before the dip has
    // played a single frame — the exact interleaving the old version broke on.
    composeRule.mainClock.autoAdvance = false
    pressable.performTouchInput { down(center); up() }
    composeRule.mainClock.advanceTimeBy(2_000)
    composeRule.mainClock.autoAdvance = true
    composeRule.waitForIdle()

    pressable.assertIsDisplayed()
    composeRule.runOnIdle { assertEquals(1, clicks) }

    // The queue must be fully drained and interactive again — this is what
    // would wedge if sequential collection misbehaved.
    pressable.performClick()
    composeRule.runOnIdle { assertEquals(2, clicks) }
}

mainClock.autoAdvance = false is what makes this a real test rather than a race. With the clock paused, down() and up() both land before any animation frame runs — a harsher interleaving than a human hand can produce, and precisely the one that used to fail.

The assertions are indirect on purpose. Still displayed, exactly one click, and — the important one — still interactive afterwards. A sequential collector that wedged, or an infinite spec that never completed, would block the flow forever and the second performClick() would fail. That's the real failure mode being guarded, and it's observable even though the animation isn't.

The companion test for the disable path leans on identity:

composeRule.runOnIdle { assertSame(Modifier, result) }

If animationSpec == null returns the receiver unchanged, and the receiver was Modifier itself, then identity equality proves no node was added. One assertion, no inspection of internals.

What generalises

Feedback about an event is not a function of state. If a piece of motion must complete regardless of how quickly the triggering state reverts, animateFloatAsState is the wrong tool and no spec tuning will save it.
collect gives you sequencing for free. A suspending collector body plus a suspending animateTo is a queue. You don't need a state machine or a minimum-duration timer.
Split interruptible motion from uninterruptible motion. If one phase blocks the next, make that phase short, fixed, and boring; spend the expressiveness on the phase nothing is waiting for.
Handle Cancel, not just Release. Scrolling a list over your component is the common path, not the edge case.
Transform at draw time, never at measure time, or your touch target animates along with your visual.
Read animated values inside the graphicsLayer lambda, not as arguments to it.
When the thing you changed isn't observable, test the failure it caused. Pause the clock, force the bad interleaving, and assert the component is still alive on the other side.

The final implementation is about thirty lines, five of the forty components use it, and it took considerably longer to get right than "scale the button a bit when you press it" has any business taking.

FormaUI is an opinionated Material 3 component library for Jetpack Compose — 40 components with the design work already done. Modifier.formaPressScale is public API, so you can put the interaction on your own components; it's on by default for buttons, icon buttons, cards, chips and FABs. Try them live in your browser — the dip is easier to feel than to read about.

Docs that run the real component

DevSnack — Mon, 10 Aug 2026 14:37:01 +0000

Documenting a UI library has three bad answers. Screenshots go stale by the next release. Videos don't let anyone interact. A separate demo app doesn't get installed, because the whole point of evaluating a library is that you haven't committed to it yet.

What you actually want is for the reader to click the button. Not a picture of the button.

So every component page on this site runs the real component. Same Kotlin source that compiles to the Android artifact, compiled a second time for the browser, rendering live on the page you're reading. Change a variant, disable it, flip it to dark — you're driving real Compose code, not a CSS class swap.

Here's how it works, what it cost, and the parts that were more awkward than they should have been.

Compiling the library twice

FormaUI ships to Android and only Android. But Compose has a wasmJs target, and the components are plain Compose, so the same source compiles for the browser too. That second compilation exists purely to build these docs. It isn't a platform you can ship FormaUI to, and I want to be unambiguous about that before "runs in the browser" reads as a support claim.

Compose on the web doesn't compile to DOM elements — it renders through Skia onto a single canvas. Your Column isn't a <div>; it's pixels, drawn by the same rendering path that draws them on a phone.

For a normal web app that's mostly a downside: no DOM means no browser text selection, a weaker accessibility story than real HTML, and a large runtime download before anything appears. For previewing a component library it's exactly right, because fidelity is the entire product. A DOM reimplementation of these components would be a second codebase that could drift, and the moment it drifts the preview is a lie. Rendering through Skia means what you see is what compiles to the artifact — bug for bug.

One bundle, not forty

This is the decision that made the whole thing viable.

The naive approach is one wasm build per component. It's a disaster: Skia's runtime is 8.3 MB and it would be in every single one of them. Instead there's a single parameterised entry point that reads a query parameter and looks the component up in a registry:

fun main() {
    val requestedId = componentQueryParam() ?: DefaultComponentId
    val entry = PreviewRegistry[requestedId]
    document.title =
        if (entry != null) "formaui-preview:$requestedId" else "formaui-preview:unknown:$requestedId"
    // …
}

Forty pages, one runtime, downloaded once and cached across every page a reader visits. Adding a component to the docs is adding an entry to PreviewRegistry — no new build target, no new bundle.

That document.title line is doing quiet work too: it means an end-to-end test can assert which component actually rendered inside the canvas, which is otherwise opaque from the outside. When your UI is pixels on a canvas, the usual DOM queries have nothing to grab.

The controls are HTML. The component is canvas.

The bit I didn't expect to build.

Each doc page has a control bar — variant tabs, a disabled toggle, a light/dark pill. The obvious approach is to draw those inside the canvas, since that's where the component lives. That's wrong: canvas controls aren't keyboard-navigable in the way the rest of the page is, they don't inherit the site's styling, and they're invisible to a screen reader.

So the docs page draws the controls in its own DOM, as ordinary accessible HTML, and drives the component through them over postMessage. State lands in a couple of holders created before composition starts:

val controls = mutableStateOf(PreviewControls())
val hostDark = mutableStateOf<Boolean?>(null)

installPreviewControlBridge(requestedId) { message ->
    val update = decodePreviewControls(message)
    controls.value = update.applyTo(controls.value)
    update.dark?.let { hostDark.value = it }
}

Writing Compose state from a JS event callback looks alarming and isn't, for a reason specific to this target: wasm is single-threaded here, so the write lands on the same thread the recomposer observes and the global snapshot picks it up like any other state write. On Android the same pattern would need thought about which thread you're on. Here there is only one.

Two details in that snippet are load-bearing.

Capability is announced, not assumed. Each registry entry declares which controls it honours, and the harness reports that to the embedder:

announcePreviewControls(
    component = requestedId,
    variants = entry.controls.variants.joinToString(ControlFieldSeparator),
    supportsEnabled = entry.controls.supportsEnabled,
)

The docs page renders tabs and the disabled toggle only for what's declared. So a control can never appear for a preview that would silently ignore it — the failure mode where a user clicks something and nothing happens is designed out rather than tested for. The variant lists are derived from the Kotlin enums rather than written by hand, so a new variant in the library can't go missing from the docs tab row.

hostDark starts null, and null means something. Not "light" — "no host is driving theme." While it's null the preview keeps its own in-canvas light/dark switch on screen. The moment a host sends a theme, that switch steps aside rather than sitting next to the page's theme pill doing the same job. The same principle applies to every host-driven value: they default to inert, so opening a bundle directly — no iframe, no docs site — still renders the full self-contained preview it always did.

That's a rule worth generalising. An embeddable thing that only works when embedded is much harder to debug than one that degrades to standing alone.

Getting the bundle to the build

The docs site is a separate repo from the library, and Vercel checks out only the docs site. It has no Gradle, no Kotlin toolchain, and no access to a build of the library.

So the library's CI publishes previews-<version>.tar.gz as a release asset, and the site's prebuild step resolves it from one of two places: a sibling checkout of the library repo when developing locally, or that release asset when building on Vercel. The tarball layout is a cross-repo contract — changing it means changing the workflow that produces it, the script that consumes it, and the test that guards both.

A missing bundle fails the build, loudly and on purpose. My first instinct was to make it a warning so builds would never break. That was wrong: a warning means you ship a docs site where every preview is a "not available" card, and you find out from a user. There's an explicit opt-out flag for the rare case where shipping without previews is genuinely what you want. Loud by default, quiet on request.

The assembled bundle lands in a directory named for a content hash of its own contents:

public/previews/b3483432795a/

A changed bundle always gets a new URL, so everything under that path can be cached forever — immutable, a year — including the entry HTML. Nothing ever needs revalidating, because a new bundle is reached by a new URL rather than by busting an old one. For a 39 MB payload that distinction matters more than it usually would.

About that 39 MB

Let's not bury it. The current bundles are 27.9 MB of wasm plus 8.3 MB of Skia, because they're development builds. That's a lot of bytes for a docs page.

Four things make it survivable:

Nothing is eager. Previews load on click or when an IntersectionObserver says they've scrolled into view — never on page load, and never on the component index, where forty of them would otherwise be in the DOM at once.
It's paid once per visitor, not once per component, because of the single-bundle decision above.
It's cached immutably, because of the content-hashed path.
None of it reaches a consuming app. This is a docs artifact. The Android dependency is an ordinary Compose library.

Release builds would be substantially smaller and I haven't done that work yet. I'd still rather ship an honest 39 MB preview than a fast screenshot that's lying.

Two smaller traps

Fonts don't come for free. The theme uses Public Sans, and on wasm that means the compiled resources have to ship alongside the wasm output so fonts load at runtime. Miss it and you get a preview that renders in a fallback font — which, for a library whose pitch is partly "the typography is better", is the worst possible failure mode. It looks fine. It's just wrong.

Browser support is narrower than you'd guess. The bundle needs WasmGC and JS string builtins — recent-Chromium-class, not "modern browsers." The check is pure feature detection with no network calls, so it can run before the bundle exists:

export async function isPreviewSupported(): Promise<boolean> {
  if (typeof WebAssembly === "undefined") return false;
  const [hasGc, hasJsStringBuiltins] = await Promise.all([gc(), jsStringBuiltins()]);
  return hasGc && hasJsStringBuiltins;
}

Unsupported browsers get a card that says so plainly. I decided against a screenshot fallback, because a screenshot silently standing in for a live preview is exactly the stale-screenshot problem this was built to escape.

One more, since it's easy to skip: the message listener checks the sender's origin. A same-origin postMessage from anywhere else on the site shouldn't be able to spoof preview state. It's a docs site, the stakes are low, and it's still four lines.

Was it worth it?

Yes, for a reason I didn't anticipate: it changed what I'm able to say.

The pitch for an opinionated component library is "this looks good, so you don't have to make it look good." That's a claim about aesthetics, which means every word written in support of it is worth approximately nothing. Nobody believes "beautiful defaults," and they're right not to.

Live previews replace the claim with the thing. A reader doesn't evaluate my adjectives — they click the button, drag the slider, flip to dark, and decide for themselves in about four seconds. It's the shortest possible distance between "I'm reading about a library" and "I know whether I want this."

That's also the honest test of an opinionated library, and I'd rather fail it in public than win an argument about it in a README.

FormaUI is an opinionated Material 3 component library for Jetpack Compose — 40 components with the design work already done. Try every one of them live, which is the entire point of the last two thousand words.

Your Compose Canvas tests are lying to you

DevSnack — Mon, 10 Aug 2026 14:35:23 +0000

A user opened an issue against FormaUI: the bar chart rendered nothing. Not an error, not a crash — a correctly-sized, perfectly empty rectangle where the chart should be. The layout was right. The space was reserved. Nothing was painted.

The uncomfortable part wasn't the bug. It was that the chart had tests, the tests were green, and they had been green the whole time.

What the tests were actually asserting

The chart's test suite looked reasonable. It rendered the component, found it by its semantics, and checked the things you check:

composeTestRule.onNodeWithContentDescription("Bar chart with 4 categories…")
    .assertExists()
    .assertIsDisplayed()
    .assertWidthIsAtLeast(200.dp)

Every one of those passed while the component drew nothing at all.

They passed because semantics and pixels are two different trees. assertExists asks whether a node is in the semantics tree. assertIsDisplayed asks whether that node's layout bounds intersect the visible window. assertWidthIsAtLeast asks about layout bounds again. Not one of them asks the only question that matters for a Canvas component: did anything get drawn?

For a Button, this distinction rarely bites, because a button that lays out correctly almost always draws correctly — its rendering is Material's problem, not yours. For anything you paint yourself, the gap is wide enough to drive a release through.

The actual bug

Here's the code that caused it, reduced:

Canvas(modifier = modifier.fillMaxWidth().height(180.dp)) {
    drawBars(entries, size)
}

Looks fine. It isn't, in the general case — and the reason is worth internalising: Canvas is a Spacer under the hood, and its measure policy reports zero for any dimension that isn't fixed. Give it a modifier chain where height resolves to a constraint rather than a concrete value and DrawScope.size comes back with a zero dimension, so every draw call is a no-op against an empty area. Meanwhile the layout slot is exactly the size you asked for, because the parent's constraints filled it in.

That is the precise shape of a bug semantics assertions cannot see. Layout bounds: plausible. Draw size: zero. Test suite: green.

The fix is to separate the two concerns — let a Box own sizing and semantics, and let the Canvas fill it:

Box(modifier = modifier.fillMaxWidth().height(180.dp).semantics { … }) {
    Canvas(Modifier.matchParentSize()) {
        drawBars(entries, size)
    }
}

But fixing the bug is the easy half. The question that actually mattered was: how do I write a test that would have caught this?

Why `captureToImage()` doesn't work under Robolectric

The obvious answer is pixel assertions. Compose ships captureToImage() for exactly this, and FormaUI's UI tests run on Robolectric — fast, on the JVM, no emulator. So:

composeTestRule.onNodeWithTag("chart").captureToImage()

ComposeTimeoutException: Condition still not satisfied after 2000 ms

Every time. Every component. Not just charts — a plain Text does the same thing. Changing GraphicsMode, setting robolectric.pixelCopyRenderMode, waiting for idle, none of it helps.

The reason is structural rather than a configuration mistake. captureToImage() captures the window, and before it does, it runs a forceRedraw step: it registers a frame-commit / onDraw callback and waits for a frame-driven draw pass to fire it. Under Robolectric there is no frame loop. Compose's own source says so, in RobolectricIdlingStrategy — "Draw passes don't happen." So the callback never fires, the wait always expires, and you get a timeout that looks like a flake and isn't one.

No amount of retrying fixes a callback that is never going to be called.

Calling `View.draw` directly

If the problem is that nothing will schedule a draw pass, the answer is to stop waiting for one and dispatch it yourself. View.draw(Canvas) renders synchronously, right now, on the calling thread — no frame loop involved:

internal fun SemanticsNodeInteraction.captureNodeToImage(): ImageBitmap {
    val node = fetchSemanticsNode("Failed to capture the node to a bitmap.")
    val view = (node.root as ViewRootForTest).view
    check(view.width > 0 && view.height > 0) {
        "Cannot capture: host view has degenerate size ${view.width}x${view.height}."
    }

    val fullBitmap = Bitmap.createBitmap(view.width, view.height, Bitmap.Config.ARGB_8888)
    view.draw(Canvas(fullBitmap))

    val bounds = node.boundsInRoot
    val left = bounds.left.roundToInt().coerceIn(0, view.width - 1)
    val top = bounds.top.roundToInt().coerceIn(0, view.height - 1)
    val width = bounds.width.roundToInt().coerceAtMost(view.width - left)
    val height = bounds.height.roundToInt().coerceAtMost(view.height - top)
    return Bitmap.createBitmap(fullBitmap, left, top, width, height).asImageBitmap()
}

Get the host View from the semantics node's root, draw it into a software bitmap, crop to the node's bounds. Thirty lines, no new dependency.

The trap underneath the trap

That still returned blank bitmaps.

Robolectric has two graphics backends. The default in many projects — including this one — is LEGACY, the shadow implementation, where drawPath, drawArc and drawLine are raster no-ops and rectangle fills rasterize as hairline outlines. Your capture is honest; there genuinely is nothing in the bitmap, because the drawing operations quietly did nothing.

This one is worth verifying yourself rather than believing me, because it invalidates a whole category of test. Take Compose out of the picture entirely, allocate an android.graphics.Canvas, draw a filled rect and a path onto it, and read the pixels back. Under LEGACY they aren't there.

The fix is one annotation:

@RunWith(RobolectricTestRunner::class)
@GraphicsMode(GraphicsMode.Mode.NATIVE)
@Config(sdk = [34])
class ChartPixelRenderTest { … }

NATIVE mode rasterizes every operation correctly using the org.robolectric:nativeruntime artifacts, which Robolectric has probably already cached. Tests run marginally slower. The bitmaps contain what was drawn.

What the test finally looks like

With capture working, the assertion is almost embarrassingly simple — and that's the point. It doesn't compare against a golden image, because golden images for charts are a maintenance tax that pays out mostly in false failures on font-rendering changes. It just asserts that the component painted something other than the background:

@Test
fun barChart_actuallyPaintsPixels() {
    composeTestRule.setContent {
        FormaTheme { FormaBarChart(entries = sampleEntries, animationSpec = null) }
    }

    val image = composeTestRule.onNodeWithTag("chart").captureNodeToImage()

    assertTrue(
        "Chart region contains only background pixels — nothing was drawn.",
        image.hasNonBackgroundPixels(),
    )
}

Note animationSpec = null. The charts animate on entry, so under test you want a deterministic final frame rather than a race against an 800ms tween. If your canvas component animates and doesn't offer a way to switch that off, that's a testability gap worth closing — you'll want it for screenshots too.

This assertion is deliberately weak. It cannot tell a correct chart from a wrong one. What it can tell you is the difference between a chart and an empty rectangle, which is the failure that actually shipped, survived a green test suite, and was found by a user.

The general rule

If a component paints its own pixels — charts, sparklines, progress rings, signature pads, custom dividers, anything holding a Canvas or a drawBehind — your semantics assertions are describing a component you have not verified renders. They're not worthless; they're just answering a different question than the one you think you asked.

The bar to hold for those components:

Assert on pixels, not only on semantics.
Don't reach for captureToImage() on Robolectric — it cannot work there, and the timeout will read as flakiness for as long as you let it.
Draw the host View into a bitmap yourself and crop to the node.
Run those tests in GraphicsMode.NATIVE, or your capture will be blank and you'll trust a blank capture.
Keep the assertion coarse. "Something was drawn" catches the bug that ships. Golden images mostly catch font updates.

FormaUI's charts now carry eight pixel-render tests built on that helper. They'd have caught the original bug in about a second — which is roughly how long it took a user to spot it, and considerably less time than it took me to work out why the obvious test infrastructure couldn't.

FormaUI is an opinionated Material 3 component library for Jetpack Compose — 40 components with the design work already done, including bar, line and donut charts with no third-party chart dependency. Try every component live in your browser.

How to Track MRR on Lemon Squeezy (Accurately) in 2026

DevSnack — Sun, 05 Jul 2026 02:29:47 +0000

Originally published on the Throughlines blog.

Lemon Squeezy is a great place to start selling — it's a merchant of record, so tax and compliance are handled for you. But once subscriptions start rolling in, one question gets harder than it should: what's my actual MRR, and can I trust the chart?

Here's how MRR works on Lemon Squeezy, the gotcha most people miss, and how to track it accurately — especially if you also sell on Polar or Paddle.

MRR = monthly recurring revenue, normalized

MRR is the recurring revenue you can expect each month from active subscriptions. The math is simple in principle:

A $20/mo plan contributes $20 to MRR.
A $240/year plan contributes $240 ÷ 12 = $20 to MRR (you normalize annual to monthly).
Sum that across all active subscriptions = your MRR.

The tricky part isn't the arithmetic. It's movement — how MRR changes over time — and what counts as a subscription ending.

The Lemon Squeezy gotcha: a snapshot isn't a history

Lemon Squeezy's built-in MRR/ARR has improved. Historically the charts were calculated in real time from the subscriptions active right now, which meant historical metrics weren't precise — they didn't properly account for subscriptions that were active in the past but have since cancelled. Lemon Squeezy now takes a daily snapshot of MRR/ARR to keep historical data accurate.

That's a real improvement, but it highlights the core issue: MRR is a story over time, not a single live number. To analyze trends, compare months, or explain a dip, you need a ledger of every change — not just today's total.

What accurate MRR tracking actually requires

To track MRR on Lemon Squeezy properly, you need to capture each event that changes recurring revenue and classify it:

Movement	Triggered by	Effect on MRR
New	First active subscription	+
Expansion	Upgrade to a higher-priced plan	+
Contraction	Downgrade to a lower-priced plan	−
Churn	Subscription actually ends / access revoked	−
Reactivation	A churned customer resubscribes	+

Two things people consistently get wrong:

Annual normalization. If you don't divide annual plans by 12, your MRR balloons every time someone buys a yearly plan, then looks like it crashes. Always normalize.
Canceled ≠ churned. This is the big one (next section).

The mistake that wrecks your churn number

On Lemon Squeezy, a subscription can be cancelled but still active until the end of the paid period. That customer is still paying you. If your tracking counts that cancellation as churn immediately, you'll:

Overstate churn.
Record the revenue loss too early.
Panic about a retention problem that hasn't happened yet.

Churn should only be recorded when the subscription actually ends and access is revoked (in Lemon Squeezy terms, when it expires/ends rather than when cancelled is simply flagged true). And if a customer reverses a scheduled cancellation, that pending flag should just clear — no movement at all.

Lemon Squeezy webhooks also don't ship the per-cycle price and interval inline on every event, so accurate tracking means looking up the related product variant to get the real recurring amount. It's the kind of detail that's easy to miss in a hand-rolled spreadsheet.

Three ways to track it

Lemon Squeezy's built-in charts. Good for a quick glance now that snapshots exist. Limited for deep trend analysis, and it only shows Lemon Squeezy.
Spreadsheet from CSV exports. Total control, total maintenance. You'll own the normalization and churn logic forever, and it won't update live.
A purpose-built MoR dashboard. Connect once, get correct movement automatically, and — crucially — combine Lemon Squeezy with your other platforms.

Tracking it accurately with Throughlines

Throughlines is a read-only dashboard built for merchant-of-record platforms, with Lemon Squeezy as a first-class integration.

Connect read-only. Paste your Lemon Squeezy API key; Throughlines backfills history and stays current via webhooks. It never modifies your store.
Correct movement, automatically. Annual normalized to monthly; new/expansion/contraction/churn/reactivation classified for you; variant lookups handled so per-cycle pricing is right.
Canceled ≠ churned, enforced. Pending cancellations keep counting until access is actually revoked.
Accuracy cross-check. Throughlines reconciles its computed MRR against Lemon Squeezy's own figure.
One number across platforms. Selling on Polar or Paddle too? See your consolidated MRR in a single view.

The takeaway

Lemon Squeezy's snapshot-based MRR is a solid glance, but accurate tracking means a proper ledger: normalize annual plans, classify every movement, and never count a scheduled cancellation as churn. Do that by hand and it's a chore that drifts out of sync; do it with a tool built for MoR platforms and you get numbers you can actually quote.

Track your Lemon Squeezy MRR in Throughlines →

Why 'Canceled' Isn't 'Churned' (and How It Wrecks Your Metrics)

DevSnack — Sun, 05 Jul 2026 02:25:21 +0000

Originally published on the Throughlines blog.

It's the single most common mistake in subscription analytics, and it quietly poisons the most important retention number you have. A cancellation is not churn. Treat them as the same thing and your churn rate becomes both inaccurate and early.

Here's the distinction, why it matters more than it sounds, and how to get it right.

The difference in one line

Canceled (scheduled cancellation): the customer has turned off auto-renew, but they're still paying through the end of the current period. They still have access. MRR is unchanged today.
Churned: the subscription has actually ended — the period lapsed, access was revoked, the money stopped. This is when MRR drops.

A customer who cancels on the 3rd but is paid through the 30th has not churned. They might even change their mind before the 30th. Counting them as churned on the 3rd is simply wrong.

Why this wrecks your metrics

If you record churn at the moment of cancellation instead of the moment the subscription ends, three things break:

Your churn rate is overstated. You're counting revenue as lost while it's still being collected.
Your timing is wrong. Losses show up days or weeks early, smearing your monthly cohorts and making trend analysis unreliable.
You react to phantom problems. You see a churn spike, scramble to fix "retention," and the customers in question were never actually gone — some renew or un-cancel.

Worse, the reverse error hides churn: if you only look at "active" subscriptions and never model the transition out of paying, you can miss churn entirely when access lapses silently.

The correct model: track the transition, not the flag

The reliable approach treats a subscription's state, not a single boolean:

A subscription is "paying" when it's active or pending_cancellation (scheduled to cancel but still within the paid period).
Churn fires only on the transition out of paying — when the state moves to ended / access revoked.
A reversal of a scheduled cancellation just clears the pending flag. No MRR movement, no churn, no expansion — nothing moved.

In ledger terms: a scheduled cancellation produces no delta. Only the actual end produces the negative churn delta. This is the rule that keeps churn honest.

How the platforms express it

Each merchant-of-record platform encodes this differently, which is part of why hand-rolled tracking gets it wrong:

Polar distinguishes subscription.canceled (still paying → pending, not churn) from subscription.revoked (access revoked → churn).
Lemon Squeezy can have cancelled = true while the subscription is still active until period-end; churn is when it actually expires/ends.
Paddle signals scheduled cancellations distinctly from the subscription actually ending.

If your spreadsheet just watches for the word "cancel," it will count all three platforms wrong.

A quick gut check

Ask yourself: "Is this customer still paying me right now?"

Yes → not churn, even if they've scheduled a cancellation. Flag it as pending and watch it.
No, access has ended → that's churn. Record the MRR loss now.

How Throughlines handles it

Throughlines enforces canceled ≠ churned as a core rule, identically across every platform:

It tracks each subscription's normalized state and only records churn on the transition out of paying.
A scheduled cancellation is flagged as pending and keeps contributing to MRR until access is actually revoked.
Un-canceling clears the pending flag with zero movement.
The result shows up in a clear MRR-movement waterfall, so you can see real new/expansion/contraction/churn/reactivation — not phantom churn.

Because the same logic runs across Polar, Paddle, and Lemon Squeezy, your churn number means the same thing no matter where the customer pays.

The takeaway

"Canceled" is an intention; "churned" is an outcome. Record churn only when the subscription actually ends — and treat scheduled cancellations as pending revenue that's still yours until proven otherwise. Get this one rule right and your retention metrics finally tell the truth.

See honest churn across all your platforms →

Consolidating MRR Across Merchant-of-Record Platforms (Polar, Paddle, Lemon Squeezy)

DevSnack — Tue, 16 Jun 2026 14:48:27 +0000

Originally published on the Throughlines blog.

A few years ago, "what's our MRR?" had one answer in one place. Now a growing number of founders sell through multiple merchant-of-record (MoR) platforms — Polar, Paddle, Lemon Squeezy — and the question suddenly has two or three partial answers, none of which is the whole truth.

This is the consolidation problem. Here's why it happens, why it's harder than it looks, and how to solve it cleanly.

Why founders end up on multiple MoRs

Each platform has a sweet spot, so spreading out is rational:

Lemon Squeezy is a fast, friendly place to start selling — popular with solo creators and indie hackers.
Polar is developer-first, with strong APIs and room to scale.
Paddle brings deeper subscription and tax tooling that tends to matter once you're past ~$10K MRR.

So you start on one, add another for a specific product or region, and now your revenue is genuinely split. Each platform handles its own sales, tax, and payouts as a merchant of record — which is great operationally, but it means your numbers are siloed by design.

Why incumbents don't solve it

The established analytics tools — Baremetrics, ChartMogul — were built around Stripe. Their integration lists reflect that: Stripe, Braintree, Recurly, Chargebee, the App Stores, and (for some) Paddle. Polar and Lemon Squeezy are barely covered, if at all. So the moment you adopt a newer MoR, the Stripe-era tools can't even see half your revenue, let alone consolidate it.

That leaves most multi-MoR founders doing it by hand: open each dashboard, copy each MRR, add them in a spreadsheet, repeat monthly. It's tedious and — as we'll see — often wrong.

Why naive consolidation is wrong

Adding two or three MRR numbers seems trivial. It isn't, because the inputs aren't consistent:

Different movement definitions. Each platform classifies new/expansion/contraction/churn its own way. Summing totals hides what actually changed.
Annual normalization. If annual plans aren't all divided by 12 the same way, every yearly sale distorts the combined figure.
Currency and rounding. Mixed currencies and per-platform rounding make the sum drift.
Snapshot timing. Platforms snapshot on different schedules; "today's MRR" isn't the same instant everywhere.
Churn timing. If one platform counts a scheduled cancellation as churn and another doesn't, your blended churn is meaningless.

The fix isn't better spreadsheet hygiene. It's a different architecture.

The clean architecture: normalize first, then sum

Consolidation works when you translate every event from every platform into one internal format before doing any math — a ports-and-adapters approach:

Adapters read each platform (Polar, Paddle, Lemon Squeezy) and emit a normalized event: a status plus a monthly-normalized amount in a single currency. No platform-specific quirks leak past this boundary.
One classifier turns state changes into signed movements — new, expansion, contraction, churn, reactivation — using identical rules everywhere.
One append-only MRR ledger holds every signed delta. Your MRR on any date is the sum of deltas up to that date; movement for a period is the deltas grouped by type.

Two invariants tell you it's correct:

Combined MRR = the sum of each platform's MRR.
Each platform's trend line sums to the combined trend line.

When those hold, the consolidated number isn't a guess — it's reconciled.

What good consolidation gives you

One MRR number for the whole business, with month-over-month change.
A per-platform breakdown (stacked area over time) so you can see who's growing and who's leaking.
A combined movement waterfall across all platforms at once.
Blended metrics — churn, ARPU, net revenue retention — computed over your entire customer base, not one silo.
Per-platform accuracy checks so each connection is validated against its own reported figure.

How Throughlines does it

Throughlines is built for this exact problem. It's a read-only revenue dashboard for merchant-of-record platforms, architected for N platforms from day one.

Connect each platform read-only (paste a token/key per platform). Throughlines backfills history and stays live via webhooks, and never writes to your accounts.
Consolidated MRR hero across Polar, Paddle, and Lemon Squeezy, with the delta vs. last month.
Per-platform stacked area + combined movement waterfall, reconciled so the parts always sum to the whole.
Canceled ≠ churned, enforced identically across every platform, so blended churn is honest.
Accuracy gate per connection. Each platform's computed MRR is cross-checked against the platform's own number.
Add a platform, not a migration. A fourth MoR is a new connection, not a re-tool.

The takeaway

If your revenue is spread across Polar, Paddle, and Lemon Squeezy, your true MRR isn't in any one dashboard — and you can't get it by adding numbers in a spreadsheet, because the inputs aren't consistent. Consolidation done right means normalizing every platform into one ledger so the combined number reconciles. That single, trustworthy number is the whole reason merchant-of-record-native analytics exist.

Consolidate your MRR across every platform →

DEV Community: DevSnack

Building a token layer Material 3 actually respects

What you're actually filling in

The shape of it

Decision 1: static or dynamic local?

Decision 2: hand your tokens to MaterialTheme as well

Decision 3: the accessor object, and @ReadOnlyComposable

What I got wrong: allocating tokens inside the provider

The limitation I can't design around

The checklist

The press animation that never plays on a fast tap

The version that looks right

Why: animateFloatAsState retargets, it doesn't queue

The reframe: a queue of events

Two specs, not one

Why graphicsLayer, and why the lambda form

Observe-only, which is the harder API decision

Testing an animation nothing can see

What generalises

Docs that run the real component

Compiling the library twice

One bundle, not forty

The controls are HTML. The component is canvas.

Getting the bundle to the build

About that 39 MB

Two smaller traps

Was it worth it?

Your Compose Canvas tests are lying to you

What the tests were actually asserting

The actual bug

Why captureToImage() doesn't work under Robolectric

Calling View.draw directly

The trap underneath the trap

What the test finally looks like

The general rule

How to Track MRR on Lemon Squeezy (Accurately) in 2026

MRR = monthly recurring revenue, normalized

The Lemon Squeezy gotcha: a snapshot isn't a history

What accurate MRR tracking actually requires

The mistake that wrecks your churn number

Three ways to track it

Tracking it accurately with Throughlines

The takeaway

Why 'Canceled' Isn't 'Churned' (and How It Wrecks Your Metrics)

The difference in one line

Why this wrecks your metrics

The correct model: track the transition, not the flag

How the platforms express it

A quick gut check

How Throughlines handles it

The takeaway

Consolidating MRR Across Merchant-of-Record Platforms (Polar, Paddle, Lemon Squeezy)

Why founders end up on multiple MoRs

Why incumbents don't solve it

Why naive consolidation is wrong

The clean architecture: normalize first, then sum

What good consolidation gives you

How Throughlines does it

The takeaway

Decision 2: hand your tokens to `MaterialTheme` as well

Decision 3: the accessor object, and `@ReadOnlyComposable`

Why: `animateFloatAsState` retargets, it doesn't queue

Why `graphicsLayer`, and why the lambda form

Why `captureToImage()` doesn't work under Robolectric

Calling `View.draw` directly