DEV Community: Daniel Vivar

Your TanStack tests don't need the whole route tree

Daniel Vivar — Tue, 27 Oct 2026 21:15:47 +0000

TL;DR: Route tests on big TanStack Router apps import every route. tanstack-router-scoped-trees generates one route tree per section with TanStack's own generator, so a test loads only its section. That saved 0.8 to 1.6 s per test file on a 1,000-route app. Install: npm i -D tanstack-router-scoped-trees (npm · GitHub)

The app I work on has more than 2,500 tests. Most of them are route tests so each of those started like this:

import { routeTree } from "../routeTree.gen";

That one import pulls in every route in the app. So a test for the invoices page also loads settings, admin, onboarding, everything. Every test file pays for it, again and again.

Hand-made test trees don't last

The obvious fix is to build a tiny route tree by hand for each test. I tried it. It's fast, but it's a second copy of your routes, and it stops matching the real ones the first time someone adds a layout or renames a file. Then your tests pass against routes that don't exist anymore.

I wanted the small tree without the second copy.

One tree per section, built by TanStack

So I made tanstack-router-scoped-trees. On the first run it detects your sections and writes a config like this, which you then own:

import { defineConfig } from "tanstack-router-scoped-trees";

export default defineConfig({
  sections: {
    billing: ["/billing"],
    settings: ["/settings"],
  },
});

and it writes one route tree per section.

The important bit: it never edits TanStack's generated file. It hands just that section's routes to TanStack's own generator, and a parity check proves the result is identical to what TanStack makes from only those files. You get exactly the tree TanStack Router would make. Parent routes come along too (the root, any layouts above), so nested routes still work.

Your billing test now imports the billing tree and nothing else:

import { routeTree as billingRouteTree } from "./route-trees/billing.gen.js";

const router = createRouter({
  routeTree: billingRouteTree,
  history: createMemoryHistory({ initialEntries: ["/billing/invoices"] }),
});

Setup takes a few minutes

Install it, plus the generator at the exact version your router plugin already uses (otherwise npm may install a second copy and the trees may not match):

npm i -D tanstack-router-scoped-trees
npm ls @tanstack/router-generator
npm i -D @tanstack/router-generator@<the version router-plugin uses>

Add the plugin after tanstackRouter():

import { tanstackRouter } from "@tanstack/router-plugin/vite";
import react from "@vitejs/plugin-react";
import { scopedRouteTrees } from "tanstack-router-scoped-trees/vite";
import { defineConfig } from "vite";

export default defineConfig({
  plugins: [tanstackRouter(), scopedRouteTrees(), react()],
});

Start the dev server once. It guesses your sections from the first part of each URL (/billing, /settings) and writes the config. From then on the config is yours. Commit it with the generated trees.

CI catches drift

Generated files that silently go stale would be worse than slow tests, so CI checks two things.

npx tanstack-router-scoped-trees generate --check fails if a tree is out of date, or if someone adds a route that's in no section. The error names the route and gives you the config line to paste.

And one parity test rebuilds every section in memory and compares it with what TanStack generates from the same files:

import { checkScopedRouteTrees, formatParityDifferences } from "tanstack-router-scoped-trees";
import { expect, it } from "vitest";

it("keeps every scoped tree in parity", async () => {
  expect(formatParityDifferences(await checkScopedRouteTrees())).toBe("");
}, 60_000);

0.8 to 1.6 seconds per test file

To measure it outside my work app, I generated one with 1,000 routes (40 sections of 25) and ran the same test against the full tree and a section tree, 5 runs each, alternating. The section tree saved 0.8 to 1.6 s per test file process, 25% to 46% of the wall time.

That's my laptop, not CI, and your mileage depends on how big your app is. The benchmark is in the repo, so you can run it yourself with npm run bench.

What it won't do

Import only one tree per test file. TanStack's trees share the root route, so a second import breaks the first. If a test redirects out of its section, give it its own file and use the full tree there.

It's file-based routing only for now, and apps using virtualRouteConfig aren't supported yet.

Try it on a big app

It's a community package, not an official TanStack one. If your app has a few hundred routes, I'd really like to know how much it saves you, and where it gets in the way. Issues and PRs welcome: https://github.com/jdvivar/tanstack-router-scoped-trees

Here's a minimalist no-frills Redux Toolkit & LitElement example

Daniel Vivar — Sun, 21 Feb 2021 10:11:29 +0000

Picture by @16pxl

Tired of full boilerplate Redux examples? What about all the Redux Toolkit examples that try to explain how much complexity is now reduced into opinionated functions... based on your knowledge of Redux?

I believe it's the most minimalist examples based on the simplest systems which tell you all.

The way to build a complex system that works is to build it from very simple systems that work.
— Kevin Kelly

Here I present you a simple system of a Redux Toolkit store and two LitElement based Web Components.

The Components

Our system is based on 2 components: one to control a variable and another one to show the state of the variable. As simple as it can get.

Of course you won't use Redux Toolkit to do that if you have just 2 components, but that's not why you're here, isn't it?

I've called them auth-control and auth-info, it's a dumb system to sign in and sign out just by clicking on buttons that say "Sign in" and "Sign out". See? No frills as promised 😂

`<auth-info>`

This component just shows a salute if you're signed in, based on an isAuthenticated property.

import { LitElement, html } from 'lit-element'

class AuthInfo extends LitElement {

  static get properties() {
    return {
      isAuthenticated: Boolean,
    }
  }

  render() {
    if (this.isAuthenticated) {
      return html`
        <p>Hi, you're signed in</p>
      `
    }
  }
}

window.customElements.define('auth-info', AuthInfo);

`<auth-control>`

Here's the controlling component. As you can see, they have a property with the same name: isAuthenticated.

import { LitElement, html } from 'lit-element'

class AuthControl extends LitElement {

  static get properties() {
    return {
      isAuthenticated: Boolean
    };
  }

  handleSignIn () {
    this.isAuthenticated = true
  }

  handleSignOut () {
    this.isAuthenticated = false
  }

  render() {
    if (this.isAuthenticated) {
      return html`
        <button @click=${this.handleSignOut}>Sign Out</button>
      `
    }
    return html`
      <button @click=${this.handleSignIn}>Sign In</button>
    `
  }
}

window.customElements.define('auth-control', AuthControl)

The Store

The goal is to share the state of the property isAuthenticated from a global state store. We will use Redux Toolkit to accomplish that:

import { createSlice, configureStore } from '@reduxjs/toolkit'

const { actions: authActions, reducer: authReducer } = createSlice({
  name: 'isAuthenticated',
  initialState: false,
  reducers: {
    signIn: () => true,
    signOut: () => false
  }
})

const { signIn, signOut } = authActions

const store = configureStore({
  reducer: {
    isAuthenticated: authReducer
  }
})

export { store, signIn, signOut }

Note the neat use of destructuring to obtain all the necessary information from createSlice. If you want to add more data to the store: just create a new slice, add the obtained reducer to the list of reducers to feed to configureStore and export the actions so that your app can update the state.

The connection

Now we need to connect the store with both components. In order to do that we'll use a connect mixin from Polymer project pwa-helpers.

This mixin will add logic to our component that will end up calling stateChanged every time the state changes, so to complete the connection we have to implement this callback function as well.

Connecting `<auth-info>`

...
import { connect } from 'pwa-helpers'
import { store } from './state.js'

class AuthInfo extends connect(store)(LitElement) {
...
  stateChanged(state) {
    this.isAuthenticated = state.isAuthenticated;
  }
...

That's it. You don't even need a constructor, as the store dispatches the initial state on connection.

Connecting `<auth-control>`

...
import { connect } from 'pwa-helpers'
import { store, signIn, signOut } from './state.js'

class AuthControl extends connect(store)(LitElement) {
...
  stateChanged(state) {
    this.isAuthenticated = state.isAuthenticated;
  }

  handleSignIn () {
    store.dispatch(signIn())
  }

  handleSignOut () {
    store.dispatch(signOut())
  }
...

Same here, plus we imported the actions to dispatch when handling the events for the sign in and sign out buttons.

Final touches

An HTML page to hold the components together and a build process to resolve the dependencies for LitElement and others is all you might need. We're using Snowpack for that.

Buildless anyone?

You could perfectly use packages from a CDN like Skypack or UNPKG and skip the build process altogether if you fancy. Like so:

-- import { LitElement, html } from 'lit-element'
++ import { LitElement, html } from 'https://cdn.skypack.dev/lit-element'

Having a well thought buildless process have great benefits. In fact, Snowpack has an option to do just something like we just did there, using CDN packages instead of installing them manually. It's called Streaming Imports in case you're interested 😉.

Complete example

Please dig in the whole example I've done for you in Glitch. Feel free to remix it there and leave feedback in the comments 👇 Any question or comment will be welcome!

Resetting styles inside Lit-Element Web Components

Daniel Vivar — Sat, 30 Jan 2021 23:46:18 +0000

Photo by Michele Blackwell on Unsplash

So you are working on your Web Components and soon enough you realize they are really good at encapsulating stuff. That's the goal. Check out this Web Component:

There are 2 p tags. On the one hand, we have one declared entirely inside the Web Component, the one with inner content:

...
render() {
  return html`
    <div>
      <p>Inner content</p>
    </div>
    <div>
      <slot></slot>
    </div>
  `
}
...

And on the other hand, we have a p tag declared as part of the body which is moved in as part of the slot functionality of our Web Component:

...
<div>
  <my-element>
    <p>Slotted content</p>
  </my-element>
</div>
...

We have a reset rule declared for p tags:

p {
  margin: 0;
}

As you can see, the p tag declared outside gets the style applied and moved in without margins. However the p declared inside is "protected" from the page styles and so it gets general treatment: user agent styles. That's why they look different.

How do we solve this problem?

So far, I think there's only one way to solve it: declaring the reset styles within the Web Component as well. In our Web Component, the styles static class getter will looke like so:

static get styles() {
  return css`
    div {
      border: 1px solid red;
    }
    p {
      margin: 0;
    }
  `;
}

Here is our updated pen:

Solved, right? Well, it works, but this is far from optimal. Firstly, we should have this reset styles outside the Web Component itself, that way you can share the reset styles amongst other components. Something like this:

...
const resetStyles = () => css`
  p {
    margin: 0;
  }
`
...
static get styles() {
  return [
    resetStyles(),
    css`
      div {
        border: 1px solid red;
      }
    `
  ]
}
...

But secondly and more importantly, as a good rule of thumb in software development: never have the same stuff repeated.

We still have a reset styles stylesheet, let's call it reset.css, and an object with the reset styles which is returned by resetStyles(). That means we have the reset styles both as a LitElement's css object and as an independent stylesheet.

The cool thing would be to have the reset stylesheet and that's it.

How do we do that?

We can process the stylesheet and create a CSS object, just how LitElement understands them. There are many ways to do this, I'll use Rollup for my example.

Let's Rollup! Using a simple config like this:

import litcss from 'rollup-plugin-lit-css'

export default {
  input: 'src/reset.css.js',
  plugins: [
    litcss({ uglify: true })
  ],
  output: {
    file: 'reset.css.lit.js',
    format: 'es'
  }
}

Here we're using Rollup's great rollup-plugin-lit-css plugin by

Benny Powers 🇮🇱🦁️Follow

Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git. *Opinions posted are my own*

Our src/reset.css.js is super simple:

export { default } from '../reset.css'

That's it!

Now we can use it in LitElement:

...
import reset from "./reset.css.lit.js";
const resetStyles = () => reset
...

We'll need something more advanced than CodePen for this, let's use Glitch and voilá! Now we only have one place where our reset styles are written (reset.css). Check it out:

Remember in this example the file reset.css.lit.js has been created by Rollup.

Minireset.css

A similar approach than the one just explained I used to improve minireset.css in this PR and provide an additional LitElement compatible file other people can use in LitElement Web Components. minireset.css is a great (and very tiny) reset you can use at production sites, which I recommend, check it out:

https://jgthms.com/minireset.css/

Install it on your project:

npm install --save minireset.css

Then in LitElement Web Components where you want to have the styles reset, import them:

import { minireset } from 'minireset.css/minireset.css.lit.js'

And then either use them as part of an array CSS result, like so:

static get styles() {
  return [
    minireset,
    ... your other styles
  ]
}

or directly in your styles:

static get styles() {
  return css`
    ${minireset}

    ... your other styles
  `
}

That's a wrap!

I hope you found this article useful. Questions and feedback are very welcome 🙂