DEV Community: Daniel Macák

How to test TanStack Router

Daniel Macák — Wed, 16 Apr 2025 08:32:08 +0000

Disclaimer: I talk primarily about the code-based routing using React.

I recently rewrote an app to use a TanStack Router and naturally wondered how to test our routing.

We are on our own here 😮

To my surprise, the official docs don't mention testing at all. I found some mentions on GH but these are just indirect hints. That might be because they think there is nothing special about the test setup, but it still leaves people confused about best practices or just a basic setup.

So I took a quick stab at this challenge and figured out a couple things that will hopefully make it work for you.

Complete example

example.test.ts

import { createMemoryHistory, createRouter, RouterProvider } from '@tanstack/react-router';
import { render } from '@testing-library/react';
import { act } from 'react';

it('renders app', async () => {
  const { app } = await setUp();

  expect(app).toBeTruthy();

  const heading = app.getByRole('heading', { name: 'Hello Router' });
  expect(heading).toBeTruthy();
});

async function setUp() {
  const router = createRouter({
    // Very important to prevent test slowdown
    defaultPendingMinMs: 0,
    routeTree: rootRoute.addChildren([TEST_INDEX_ROUTE, ...realRoutes]),
  });
  const app = render(<RouterProvider<typeof router> router={router} />);

  // Either you can make this part of setup, or call it in each test manually
  await act(() =>
    router.navigate({
      search: { account_uuid: 'account_uuid' },
      to: '/account',
    }),
  );

  return {
    router,
  };
}

// Optional, if you want to prevent real components from loading initially
const TEST_INDEX_ROUTE = createRoute({
  component: () => <div>Dummy index</div>,
  getParentRoute: () => realRootRoute,
  path: '/',
});

With a code snippet out of the way, let's talk details and some important principles.

Keep it real

You might have noticed that I am using real routes for both the root route and the routes under test. This is exactly what you want in order to keep your tests as close to the production environment as possible.

Ideally, I wouldn't need the TEST_INDEX_ROUTE either and I'd just use the production routes, but I didn't want to navigate to a real "/" route and initialize components I didn't want to test. That's why I am using this dummy as a starting point.

In doing so, my testing router now differs from the production one. So I need to hint this fact to my router provider as it would expect the production router type by default and TS would produce a type mismatch error.

const router = createRouter({
    defaultPendingMinMs: 0,
    routeTree: rootRoute.addChildren([TEST_INDEX_ROUTE, ...realRoutes]),
  });
// Let TS know we are using a different router
const app = render(<RouterProvider<typeof router> router={router} />);

The alternative way is to use the real routes but set the initial route to something else than / using custom memory history:

  const memoryHistory = createMemoryHistory({
    initialEntries: ['/account?account_uuid=account-uuid'],
    initialIndex: 0,
  });

  const router = createRouter({
    defaultPendingMinMs: 0,
    history: memoryHistory,
    routeTree: rootRoute.addChildren(refundRoutes),
  });

Not bad, but I don't like that the initial URL has to be specified as a URI string without any type guarantees. On the other hand, calling navigate explicitly gives you full control and type safety. Just don't forget to wrap it in act since navigation often changes React state and you'd get warnings and perhaps wrong state if you didn't.

Beware the pending state

Maybe you wondered what this setting is about:

const router = createRouter({
    // Very important to prevent test slowdown
    defaultPendingMinMs: 0,

The default value is 500ms and it's the time during which the route is in a pending (not displayed) state. I gathered that it should make people navigating between pages aware that the page changed. This to me sounds like a hard to justify slow down and I always recommend setting it to 0 in production code.

But it's easy to forget that you need the same setting in tests as well, otherwise it can prolong each of your test cases by 500ms 🙈.

Performance

I found that tests involving Tanstack Router and full route rendering tend to be pretty slow - couple 100s ms. I'd recommend writing such tests only for the complex parts of your navigation and perhaps use shallow rendering to improve performance if absolutely necessary.

The good news is that lazy routes are respected in that they are not loaded until used. That isn't really surprising since the lazy loading, using the dynamic import() is pure JS and nothing specific to Tanstack Router.

Final thoughts

As you see, there is not much test specific set up needed, and it's indeed the best strategy to change as little as possible for the sake of tests.

Let me know if you found a better way to set the tests up with Tanstack Router, especially regarding the performance. Cheers.

Astro + Vercel Serverless API

Daniel Macák — Tue, 03 Sep 2024 07:48:47 +0000

I recently decided to create a portfolio since I never had one. It would be a static content mostly with a few dynamic islands here and there. Namely I'd like to dynamically fetch my Dev.to blogposts, and I don't care how I do it as long as I stay on the cheap side.

Since I mentioned islands, you probably guessed I picked Astro. And since I like using Vercel, I thought I could use an Edge Function to make the Dev.to articles fetch.

Edge Functions didn't work

I found this the hard way. Even though Vercel's docs mention Edge Functions don't work natively with Astro, in the same breath they say you can get it to work by following Functions Quickstart. But I just couldn't.

First problem was the vercel cli. It uses ts-node to compile the functions defined in /api. For that purpose it needs tsconfig.json but it couldn't use the Astro's one - it couldn't find the referenced parent tsconfig.

So I figured I could use the parent config directly. But it turns out Astro's and Vercel's TS configs differ a lot and one can't use 1 config for both. My idea to create separate tsconfig.api.json didn't meet with success either - Vercel always looks for tsconfig.json and one can't configure it otherwise.

At this point I thought this DX wasn't great for such a simple task and I began looking for alternatives.

Serverless Functions to the rescue

I found Serverless Functions with a Vercel Adapter are better supported and easier to set up. Following the link I had to do these steps:

pnpm astro add vercel

And in my astro.config.ts:

import { defineConfig } from 'astro/config';
import vercelServerless from "@astrojs/vercel/serverless";
import vercelStatic from "@astrojs/vercel/static";

export default defineConfig({
  output: 'static', 
  adapter: vercelServerless(),
});

And then I could happily define my functions not in /api but in pages like src/pages/blogposts.ts:

export async function GET() {
  const articlesResponse = await fetch("https://dev.to/api/articles/me", {
    headers: {
      "api-key": "[API_KEY]",
    },
  });

  const articles = await articlesResponse.json();
  return Response.json(articles);
}

to which I can the just GET /blogposts and voila, there they are! The bonus is of course that I don't need any server with serverless (duh) and can stay on my Hobby Vercel plan, yay!

Wrap up

Of course I now feel naive that I went for Edge Functions at first. They are a different beast compared to Serverless Functions deployment-wise. But the thing is I didn't care; I just wanted some quick and dirty API asap.

Me not being very experienced in Astro + Vercel definitely made things harder. It took me some time to wrap my head around the Vercel ecosystem and how to put things together. That's why I hope this post helps you if you struggle with the same thing ❤️.

MVC in Frontend is Dead

Daniel Macák — Wed, 28 Aug 2024 13:53:54 +0000

I watched a video from Theo about MVC and how it sucks and it got me thinking. We have been using MVC as the go-to frontend architecture in our company for quite some time. But no one ever questioned if it's the right approach; on the contrary, some people just loved it!

Since it still remains popular, and I didn't find any solid critique on the web, I decided to write one.

MVC what?

By MVC (model-view-controller) I mean the "classic" way of writing frontend apps you might remember from Angular.js (I am old I know).

Short description:

The View consists of UI components, let's say built with React.
When user performs an action, like a click, the View delegates to a Controller which does the heavy lifting - it might create a record in DB by calling an API and update the Model as a result.
When Model, which holds the application state, updates, the View reflects the changes.

Now when you put it like that, it sounds simple enough so why wouldn't we want to use it? Well, after spending years maintaining MVC apps, I am skeptical MVC is worth the effort. Let's go through:

the main arguments for MVC which I'll mark with ❌ as debunked
the things MVC generally sucks at, marked with 👎
comparison to alternatives like Tanstack Query

MVC makes for a clean code ❌

The assumption is that if you divide your code into neat boxes with distinct responsibilities, it makes the whole codebase better. That sounds logical, but does it really? Put shared state aside and have a look at a simple example: A component for showing and creating posts, talking to a backend API. See how it's handled with and without MVC:

MVC

// View
// Has to be made aware of reactivity, therefore `observer` from MobX
import { observer } from 'mobx-react-lite';

export const Posts = observer(({ controller, model }) => {
  createEffect(() => {
    controller.fetchPosts();
  }, []);

  function createPost(newPost) {
    controller.createPost(newPost);
  }  

  return <>
    <PostCreator onCreate={createPost} />
    {model.posts.map(p => <article>{p.content}</article>)}
  </>
})

// Controller
export class PostsController {
  constructor(private model: PostsModel) {...}

  async fetchPosts() {
    const posts = await fetchPostsApi();
    this.model.setPosts(...posts);
  }

  async createPost(newPost) {
    const createdPost = await createPostApi(newPost);
    this.model.addPost(createdPost);
  }
}

// Model
import { action, makeObservable, observable } from 'mobx';

export class PostsModel {
  // has to be reactive, using MobX for that
  @observable posts: Post[];

  constructor() {
    makeObservable(this);
  }

  @action
  setPosts(posts) {
    this.posts = posts;
  }

  @action
  addPost(post) {
    this.posts = [...this.posts, post];
  }
}

And now without MVC.

No MVC

export const Posts = () => {
  const [posts, setPosts] = useSignal<Post[]>([]);

  createEffect(() => {
    async function fetchData() {
      const posts = await fetchPostsApi();
      setPosts(...posts);
    }
    fetchData();
  }, []);

  async function createPost(newPost) {
    const createdPost = await createPostApi(newPost);
    setPosts([...posts, createdPost]);
  }  

  return <>
    <PostCreator onCreate={createPost} />
    {model.posts.map(p => <article>{p.content}</article>)}
  </>
}

I am past the point of calling a code bad just because it's a bit longer, but in this instance the MVC code is 3x times longer 🚩. The more important question is Did it bring any value? Yes, the component is a little cleaner by not having to deal with the asynchronicity, but the rest of the app is quite wordy. As a result, when you add new features and perform code changes, the commits are accordingly bigger.

As for the No-MVC snippet, I purposefully made it simplistic and didn't use TanStack Query which would make the code even more reasonable.

Organizing Controllers is complex 👎

Over time, your controllers will amass a huge number of dependencies.

Why? First of all, many components might depend on them to handle their events and get access to the Model data.

Secondly, controllers are the glue of the app, meaning they directly mutate models to change the state, call services to perform server mutations and selectively expose Model to View. In other words, they hold the complex business logic.

Inevitably, they become quite heavy and the time comes to split them up. The question is along which lines do you split them:

per domain
per view
per component (Jesus 🙈) ...?

The answer is not obvious and a bad call will lead to sizeable refactorings and rewrites later on.

As if that wasn't complicated enough, you'll find there are dependencies among controllers - parent controller initializes child controller, instructs it to fetch data at a certain point, child needs to notify parent about new developments etc. It gets very complex very fast just to keep the touted promise of "clean, separate boxes" architecture.

MVC doesn't help with Caching 👎

Caching is one of the hardest things to do correctly in CRUD apps and an important problem to solve given today's computation like AI prompts and media generation can be very expensive. Yet, MVC isn't helpful here:

export class PostsController {
  constructor(private model: PostsModel) {...}

  fetchPosts() {
    const posts = await fetchPostsApi();
    this.model.setPosts(...posts);
  }
}

If 3 separate components call fetchPosts(), the fetch happens 3 times although logically just 1 fetch would have sufficed. You probably don't want that, so how do you optimize? There are basically 2 options with MVC:

Ad-hoc caching

Write code like this:

  fetchPosts() {
    if (this.model.posts?.length > 0) {
      return;
    } 
    const posts = await fetchPostsApi();
    this.model.setPosts(...posts);
  }

Which is brittle, not centrally handled and very limited in its capabilities. If you'd like stale timeouts, cache evictions etc., you'd have to write it yourself or bring a library onboard which handles it. That doesn't sound so bad, but given MVC separates the Model from the other layers, you'd still need a lot of code for the V and C to have some say in the M's caching state.

Data fetching caching

The other option is caching on the data fetching layer, either using Service Worker (which isn't very flexible solution) or some fetch-caching lib. Same as with the ad-hoc caching above however, the problem remains that the fetch calls and the models are disconnected and the controllers need to keep them in sync at all times.

MVC makes for a Better Testing ❌

The argument tends to be two-fold here:

Because the app layers are so well defined, it makes the (unit) testing cleaner and therefore easier.
Since View is devoid of its own state, one should hardly need the View layer to be unit and integration tested. That saves testing complexity by removing the UI lib from the equation.

Let's see how it is in reality.

It makes unit testing harder

The first argument is a false promise. Since the View is dull (remember, it's the Controller calling the shots) and the Model usually doesn't contain much business logic (Controllers do), there indeed isn't much to unit test in the View.

However, that means all weight is on Controllers, with their many dependencies and complex logic. If you want to unit test them, you'll have a lot of mocking to do which in turn makes testing very labourious and the testing conditions so unrealistic that it's borderline useless.

The other option is to test Controllers only in integration tests where the bulk of the app is initialized, but that requires a proper set up and upfront planning to architect the app accordingly.

No you can't just forget about UI in tests

The second argument about leaving out the View from tests is even bigger Fata Morgana. Even if the View layer was "dull", there is always some logic in there whether you want it or not - handling user events, conditional display of content, UI updates through state changes, reactivity, you name it. And there can be bugs in all of these, possibly making the UI unusable.

That only shows that leaving out UI unit tests is a gamble, and E2E can't fully offset it.

But then I need to include React in my tests

So? It will bring you and your tests closer to your users. It's a breeze to test with the Testing Library and given how many starter tools we have nowadays, it's no problem to include the UI framework in your tests as well.

I absolutely love this notion from a random person (don't remember where I saw it :/) on the internet on the topic of performance:

If the added React layer significantly increases the tests execution time, it's not the tests that are to blame, it's your bloated UI.

State is in the Model 👎

Separating state away from components is completely arbitrary. Don't get me wrong, shared state of course should be made accessible to components that need it. But if a state concerns just one part of the view, it should be co-located with its component, simple as that.

The reason is that it's much simpler to grasp how a component and its state influence each other if the two are in a direct relationship, even in the same file.

In MVC, the View has to trust the Controller to give it the right state and handle the state mutations correctly since it has no direct influence on the Model itself. And of course you need to inspect at least 3 files instead of 1 to understand how components and state interact. This becomes even more evident when you throw state management solution like Redux into the mix.

State should be in the Model ONLY ❌

This is such a strict measure and no wonder @markdalgleish apologized for enforcing it in the distant past through a Lint rule. I am firmly convinced putting ALL state to central places and interacting with it only through controllers leads to bloated, hard to understand and hard to change code.

You can easily switch to different UI framework ❌

Emphasis on the word framework. Frameworks are usually opinionated about the app architecture, and use their own kinds of primitives for building apps. Take Angular's DI and RxJS, or Solid's Signals as an example.

If you use MVC and want to do a rewrite, say, from React -> Angular, well first why on Earth would you do that, and second, Angular is so different from React that you'd probably have to do a large rewrite. Such a rewrite would ripple through all the parts of your MVC architecture, even wannabe framework-agnostic controllers.

Is the touted case for an easy rewrite even valid?

It's questionable if a rewrite of such parameters where you only swap the UI framework and leave the rest largely intact isn't just a chimera. The most common reasons for a rewrite are in my experience:

The need for a refresh of a legacy UI, providing new and updated features. Here, it's usually easier to start from scratch due to legacy baggage.
Rewrite out of frustration with unmaintainable code base, leading to a complete overhaul of the app's architecture.

Neither would leave the MVC architecture intact and it turns this supposed benefit on its head.

So what's the better alternative? ✅

I am tempted to say anything else than MVC, but I don't want to overreach. I'd say a very solid approach is to use the already mentioned TanStack Query, since it solves most if not all the discussed problems. Let's see some code:

import { useQuery } from '@tanstack/react-query'

export const Posts = () => {
  const { isPending, refetch, data: posts } = useQuery({
    queryKey: ['posts'],
    queryFn: fetchPostsApi,
  })

  async function createPost(newPost) {
    await createPostApi(newPost);
    refetch();
  }  

  return <>
    <PostCreator onCreate={createPost} />
    {posts.map(p => <article>{p.content}</article>)}
  </>
}

So you can immediately see that instead of interacting with a controller or fetching data directly, I define a Query which does that for me. When I create a new post, there is a convenient refetch method that performs the query again.

Now there is a lot to talk about regarding TanStack Query but I'll concentrate only on the points discussed above.

Code being clean ✅

I say the code is much cleaner by the mere fact that we got rid of Controller completely and in this instance of the Model as well. Of course if you need to extract business logic or state and make it shared, do that, but there is no reason to follow the rigid MVC structure.
And of course, as a bonus, there is much less code.

Organizing Controllers ✅

Not an issue anymore, Controllers are gone.

Caching ✅

This is a staple feature of TanStack Query. All requests are recorded, cached and deduplicated automatically as needed. You can set cache expiration time, invalidate, refetch and much more, very easily, just check their docs.

Testing ✅

Testing is pretty easy I'd say, as only 2 steps are required in the particular architecture I am using:

  const fetchPostsSpy = vi.spyOn(postsApi, 'fetchPostsApi');

  render(() => (
    <QueryClientProvider client={queryClient}>
      <Posts />

Mocking the API to provide dummy data and providing the QueryClient.

You only test what the particular component needs, nothing more, no big chunk like with MVC Controllers.

State placement and syncing ✅

State is co-located with the components through the Query and synced automatically with the data (state) provided by the backend, all in one objects.

This is of course not to say that you should have all your business logic in your components or that all state should be inside components as well. On the contrary, it absolutely makes sense to extract this where needed. My point is however that this should be done with judgement in the simplest way possible rather than blindly follow MVC everywhere.

Wrap up

I am pretty certain the case for MVC in the Frontend is weak and there is no good reason to use it, as there are much superior alternatives.

I'd love to know what you think, do you like using it, or did you wave it good bye and never looked back?

5 most frequent A11y Mistakes

Daniel Macák — Tue, 30 Jul 2024 08:56:45 +0000

1. Always relying on `aria-label` 😳

If you are guilty of this mistake, I don't blame you since I fell into the same trap myself. People are only too readily using aria-label whenever they want to provide additional context, but they underestimate how careful they have to be with it.

First of all you might not even need it at all. Consider this:

<section aria-label="Quiz answers">
  <h2>Quiz answers</h2>

This example is pretty simplistic, but it goes to show that your HTML structure is often enough to provide screen reader (SR) users the needed context. A <section>, as MDN and the HTML Standard tell us, is usually accompanied by a heading and SRs rely on that. In practice, even when a SR user navigates a webpage by regions instead of headings (regions are special areas on the page like <nav>, <main>, <section> etc.) the <h2> will be read together with the <section> by the SR even without the aria-label.

But there is a much more sinister side of things than just needlessly slapping useless aria-labels everywhere, they can actually betray you! 😕 Check this out:

<ul>
  <li aria-label="Option 1 is the correct answer, and you did not vote for it">
    <span aria-hidden>Option 1</span>
  </li>

This looks completely valid right? We provide additional context in aria-label and hide the <span> because we don't want 'Option 1' to be read twice. But guess what, the whole list will be completely ignored in both NVDA and JAWS screen readers! Now why the hell is that?

The issue has 2 components:

The list item has no SR-visible content thanks to aria-hidden. That's I guess anticipated, but...
The aria-label, which was supposed to work around the hidden content, is actually invalid on <li>!

Not only isn't aria-label compatible with the list item element, it usually can't be used on such ubiquitous elements like <div> and <span> either! I bet you didn't see that coming, and I certainly hadn't in the past.

So when can you use it then? MDN says it clearly (emphasis mine):

... in practice however, it is supported only on interactive elements, widgets, landmarks, images, and iframes.

Meaning that if your <div> has eg. a role="button", aria-label is gonna work, but if it is plain old div, the aria-label will be disregarded. And as my example shows, this can go beyond the SR not providing the additional context, it can actually lead to a whole section of content being hidden from the SR user when particular conditions are met.

2. Disabling form elements

A lot has been written on this topic and I recommend Adrian Roselli's article for summary. I have basically 2 issues with disabling form elements which imo are relevant to both SR and non-SR users.

They are hard to see 🙈

For some reason, Web Content Accessibility Guidelines (WCAG) don't require the same color contrast standard for disabled elements as for the rest of the page, which then allows for such designs:

If your sight is 20/20 you'll have no problem reading this button but so many other people just won't see the text and neither even the button itself, given its low contrast with the white background.

They provide no explanation

Ask yourself an honest question: How often, when you disable form elements or any controls for that matter, do you also provide an explanation on why they are disabled? Exactly.

It's super annoying and confusing not to know why and not just for assistive tech users, though it of course hits them the hardest. It might be logical and perfectly understandable to us, programmers, that eg. a submit button should stay disabled until all form fields are valid, but it's not as cut and dried for our users.

3. Underestimating SR differences

There are big differences between SRs on multiple levels. The obvious one is the way SRs read webpages. Remember that aria-label gotcha from #1 above? It actually worked in VoiceOver on Mac and the aria-labeled content was read just fine but it was completely broken in the Windows SRs - NVDA and JAWS. Other times when I coded the first version of one highly interactive feature and used primarily NVDA to develop it, it worked great there but didn't work at all with VoiceOver.

In terms of development, your best bet is to follow the WAI-ARIA standard and use the Authoring Practices Guide and you should be in the clear in most cases.

But that doesn't mean you can skip the testing and you should absolutely test on multiple platforms and SRs:

Windows, ideally both NVDA and JAWS due to their big market share, based on the WebAIM 2024 Survey
Mac with VoiceOver
iOS with VoiceOver
Android, eg. with Talkback

I'd say this is the minimal suite but I totally understand if it's too much for one developer to do every day, because of course it is. What helps is that over time you'll learn which things require a full (re)test and of course your company's a11y testing/auditing process should have your back, but that's its own big topic which I won't expand on here.

4. Not knowing how users use SR 🤔

I see it a lot with people who are just starting to play with screen readers, be it developers or designers, having a very fuzzy idea of how one navigates the presented content beyond pressing the Tab key. This of course leads to less than ideal implementations, same as with building a product and not understanding your audience.

There are many ways to navigate a webpage or any other content with screen readers. Most people use headings to make sense of the content. Jumping to specific regions, navigating by links, forms or the Find feature are all important tools for the SR users.

But it's not just about which content "anchors" can be utilized. If we come back to the SR differences for a second, we'll discover very different techniques of navigating. VoiceOver users can use a so called Rotor to switch between different types of "anchors" (regions, links, headings, ...) and even search among them to reach their desired destination. NVDA on the other hand works very different to VO in that it doesn't operate in one all-encompassing mode but rather in multiple and when a user eg. wants to operate a form, she needs to switch from browsing to interactive.

SRs on mobile are their own chapter because users operate them very differently to desktop and without going into much detail, they really put things into perspective (more on that in #5).

Understanding all this is key in order to implement accessible apps and it will help you know what and why you are doing when addressing a11y issues. Luckily, there are great resources on getting this kind of understanding:

WebAIM's 2024 Screen Reader survey detailing how and which SRs people use
Stories of assistive tech users
Channels like Blind Life going into detail on how tech is really used by users with disability

5. Misunderstanding the purpose of the Tab key

This is kinda my favorite one since I see it quite a lot and I also feel understanding it will make the lives of us all so much easier. So let's join hands and say it all together: Tab key is not for navigating all interactive elements! 🤯

Feeling funny now? Once the dizziness passes, you might be thinking "What the hell did I just say?". It might make no sense to you. But in reality it makes a lot of sense. Consider the example below; just click into the Codepen (I stole it from MDN) and Tab all the way through to the current tabpanel (content of the current tab).

That took a little too many Tab presses didn't it? Sure, all tabs are interactive and should be focusable but did we need to go through all of them? And now imagine there were 10 tabs, not 5. Or even better, imagine you'd be trying to get over a list of 1000 emojis to reach a content below it. And imagine doing that on mobile, where Tab is performed by swiping left and right! 🤯 That'd be more than a little tedious, right?

This example gets to show that it's actually NOT the purpose of the Tab key to go through all interactive elements on the page, but rather browse quickly through the page's content. If the user decides to interact with the content like the tablist from above, she can do so with the arrow keys.

It's like walking down a street, knocking on the door of the houses alongside it and deciding on the spot whether to enter or go to the next one. Going from house to house is the Tab key pressing and entering the house is the Arrow keys (don't quote me on that once they apprehend you for trespassing).

So this is how it should look in practice, the first Tab keypress moves focus to the currently active tab, second Tab press goes to the tabpanel (tab content). Neat!

Again, a great resource on how to get this kind of interactivity is the Authoring Guidelines from W3C and I can't recommend it highly enough.

That's it!

Alright, lemme know which a11y transgression bothers you the most and what you would put into your Top 5 list!

Solid's Resource is great!

Daniel Macák — Tue, 07 May 2024 09:21:52 +0000

When you say Solid, Signal usually comes to mind, but there are many more great APIs there. One of them is Resource:

const fetchPosts = () => 
  fetch(`https://jsonplaceholder.typicode.com/posts`)
    .then(r => r.json());
};

const App = () => {
  const [posts] = createResource(fetchPosts);

  return <span>Number of posts: {posts()?.length}</span>;
}

As you can see, Resource basically does 2 things:

Manages an async operation, like a fetch
Binds the result of that operation to Solid's reactive model

Therefore, it makes an async operation appear synchronous. See? I haven't used await anywhere in the App component.

You can also connect the Resource to a Signal. Every time the latter changes, Resource performs the async operation again.

const fetchPost = async (id) => (
    await fetch(`https://jsonplaceholder.typicode.com/posts/${id}/`)
  ).json();

const App = () => {
  const [postId, setPostId] = createSignal();
  const [post] = createResource(postId, fetchPost);

  function onOpenPost(id) {
    setPostId(id);
  }

Pretty neat. However, sometimes you need a bit more control over the encapsulated data, and that's where refetch and mutate come in.

const App = () => {
  const [postId, setPostId] = createSignal();

  const [post, { mutate }] = createResource(postId, fetchPost);
  const [posts, { refetch }] = createResource(fetchPosts);

  async function onCreatePost() {
    const newPost = await createPostInDB();
    refetch();
  }

  async function updatePost(updatedPost) {
    await updatePostInDB(updatedPost);
    mutate(oldPost => ({ ...oldPost, ...updatedPost });
  }

As their names tell, refetch makes the Resource, in our case, call the backend API again. This can be handy anytime it's more consistent to get fresh new data from the backend rather than modify it in place on the frontend.
mutate on the other hand lets you modify the data in place without calling backend API. The one thing I'd love and I am missing at the moment would be to have the same capabilities to mutate the Resource as with Solid Stores as that would make the mutations much easier to perform.

To wrap the nice features up, there are loading and error properties on the Signal produced by Resource which make it super easy to track the fetch's status:

const App = () => {
  const [postId, setPostId] = createSignal();
  const [post] = createResource(postId, fetchPost);

  return <span>{post.loading && 'Loading...'}</span>

There are more interesting Resource options and properties like state which you can find in the docs.

Alternatives

When I was listing all those advantages of Solid's Resource, I bet many of you thought Tanstack Query. And they are indeed similar in many ways, although the latter is much more powerful. That's why it's so nice there is an official distribution for Solid as well!

yarn add @tanstack/solid-query

I'd say use the built-in Resource as long as you can and only when you need to manage your queries in a more complex fashion switch to Solid Query.

There was some talk of Solid + MobX in the past but to me, in case of async resources, I still prefer Solid Resource since it encapsulates both the fetch and the data in one easy to manipulate object.

Architecture

That's all nice, you might say, but having those Resources in components is not great, I'd like to extract them outside to make them more testable and maintainable. Well, there is nothing stopping you form doing exactly that!

I like to put them outside components like this:
post-resource.ts

const [postId, setPostId] = createSignal<number>();
const postResource = createResource(postId, api.fetchPost);

export const getPost = (id: number) => {
  setPostId(id);
  return postResource[0];
};

export const updatePost = async (
  postPatch: Partial<Post>
) => {
  const success = await api.updatePost(postPatch);

  if (success) {
    const { mutate } = postResource[1];
    mutate(p => ({ ...p!, ...postPatch }));
  }
}

And then in the component I just use those exposed functions:

const PostDetail = () => {
  const postId= +params.id;
  const post = getPost(postId);
  ...
}

That means you can build an entire frontend architecture around the Resources! No need to sync API calls with Redux or other complicated solutions, you can just use the Resource and expose as much or little as you want.

One benefit of extracting the Resources from components is that they can then be easily tested on their own. The only thing you should be careful about is not to forget createRoot. It sets up reactive context inside which updates to reactive state are detected. This context normally gets set up when calling render, but we are not rendering anything when testing just Resources. Therefore, you should wrap the part that creates Resources in createRoot.

test('resource fetches from api', async () => {
  const { postResource } = setup();
  ...
})

function setup() {
  return createRoot(() => initResources(testApi));
}

If you are wondering what the setup function is about, check out my article 5 steps to better unit/integration testing.

That's it folks

How do you like Solid Resource so far, and do you use it yourself? Which other architecture do you use in your Solid apps? I'd love to know!

5 steps to better unit/integration testing

Daniel Macák — Sun, 07 Apr 2024 19:49:35 +0000

1. Use setup functions

Setup functions are much better pattern than using test lifecycle methods like beforeEach, beforeAll and the rest. What do I mean by setup functions?

it('should do something with current user', () => {
  const { userService } = setup();
  ...
  expect(userService.getUser()).toBe(...);
});

function setup() {
  const userApi = new UserTestApi();
  const userService = new UserService(userApi);
  return { userService };
}

They do as their name says, they set up everything that's needed to run your tests, including mocks, stubs, populate models, you name it.

Why is using test lifecycle methods an anti-pattern?

They create hidden dependencies for all test they apply to.
They are inflexible. If you need different behavior for some of your tests, you have to put them in a different describe with a different lifecycle method implementation. Their number can really explode if the test vary a lot.
They are rigid, since they can't be parameterized from the individual tests.

Setup functions don't suffer from these problems. On the contrary, they allow to overcome them easily. In the same order:

Hidden dependencies - not a problem. You can have various setup methods, or just parameterize them and then the tests position in the file doesn't matter. You can move it elsewhere, even outside of top level describe and it won't break the test.
They are flexible for the reasons mentioned above.
The aren't rigid since you can pass unique arguments from inside each of your tests.

2. Prevent nesting

Nesting is one of the most wanted bandits in any kind of code, as it makes code less readable and harder to reason about. This is no different for tests. If you nest multiple describes and aggravate the problem by layering test lifecycle methods as well, you've got a serious problem on your hands.

describe('My component', () => {
  beforeAll(() => {...});

  describe('in read-only mode', () => {
    beforeEach(() => {...});

    describe('on touch device', () => {
      beforeEach(() => {...});

      it('poor me if you want to change the setup!', () => {...});

Reading and thus maintaining this code is hell. If you want to move the actual test case elsewhere, or change the way it's set up, good luck!

The solution is easy. Don't nest, don't divide the setup into multiple layers, just keep it shallow as much as you can.

3. Treat your tests same as your production code

We programmers are used to caring a lot about our production code. We refactor it, divide it into neat modules, extract reusable parts, make sure it's commented and nicely readable. But honestly, do you treat your tests the same way? The truth is that you probably don't, at least according to my experience from many companies.

We programmers often treat tests as necessary evil that we want to be done with asap. This is partly due to the tests often being a kind of an afterthought. Lot of people tend to write production code, refactor it, test it manually, and only when thinking they are finally done do they realize they should write tests for their code as well.

I am not the kind of guy who will tell you to do TDD, because in many situations it simply doesn't make sense. If you want to improve however, be more conscious of the principles you apply to your production code and apply them to your tests too. Are your tests not DRY? Just extract common steps into reusable functions. Are your test files too long and unwieldy? Split them up into multiple logical units (files). And refactor your tests every time you feel like you don't know understand what the hell is going on there.

4. Find the right balance

Finally getting to the juicy stuff. This might be controversial, but I don't care. Let's just forget once and for all about the mythical 100% test coverage. It's a lie and you will never achieve it, whatever your code coverage tool or Uncle Bob says. Even if people accept this, they sometimes hold it as an ideal which they strive towards. I think this leads only to a lot of irrelevant and/or unmaintained tests and therefore to a great time waste.

The bigger your project, the more impractical this ideal is. The reality is that you have to prioritize the same way as you would with the rest of your code base and your project in general. You can't write test for everything the same way as you can't implement all the features you'd like nor perform all the refactorings you wish.

There is an important caveat to this though. Most of us work on projects that are not terribly important, sorry, and the agility in development and good real-time monitoring is of more value for us than high code coverage. That said, there are programs that people's lives depend on, and any mistake can be fatal to its users. This can be software used in aviation, medicine or weapon systems. It goes without saying, that making sure the program works correctly is of essence and testing everything is absolutely necessary.

So the takeaway is following: Judge the importance and ROI of your tests, but most importantly use common sense, and choose your desired coverage accordingly.

5. Prefer integration over unit

Again, this is highly contextual, but in my experience for most apps created today, unit tests make less sense. If you have a unit, be it class or function, which does something either very technically involved, or encapsulates important business logic on its own, unit test is useful. But let's be frank here, most of the time, our units are not that interesting, and creating unit tests for them is waste of time.

One other aspect is that if you want to change your unit, even if you took great care writing your test properly, you are probably gonna break it. And we change units often. There is nothing worse than being slowed down by tests breaking left and right when you know it's just the implementation changing, not the resulting system behaviour. Such DX often leads to people ditching tests altogether.

That's the reason I prefer integration tests, ideally such that create the whole app in headless mode, so without the UI, but otherwise with full functionality! Here is an example:

it('should sign in user', async () => {
  const { userController } = await setup();
  await userController.signIn(...);
  expect(userController.getUser()).toBeDefined();
  ...
});

async function setup() {
  return await initTestApp();
}

In this setup, I like to test the high level system behaviour instead of the implementation details. Because of this architecture, if I change my units, but the resulting behaviour is still the same, the integration tests don't care. I can change the signIn's implementation, but as long as it populates the current user in the model, the test is still gonna pass.

But this is not all! By using the holistic approach instead of the pretty low-level focus on units, we are testing much closer to what really matters to users - that the system works as a whole. Which means such tests bring much more value than unit tests, which exist in completely mocked and therefore detached environment.

That's all folks

Let me know if you agree or if your approach is different. I am happy to discuss.

5 Most common AB Testing Mistakes

Daniel Macák — Fri, 22 Mar 2024 09:17:07 +0000

Running AB tests seems easy at first. After all, you just divide users into 2 groups and compare the results, right? Not quite. Designing, running and evaluating many AB tests, I realized that as many things in life, it's not that simple. Let's have a look then at how to identify some big mistakes you might be making and prevent them.

Concluding tests too early

This happens when people get excited about preliminary results before the AB test reaches statistical significance. In other words, it happens all the time. And it's not like people don't know they should be patient, but it's hard to get there (same with holding stocks and watching the prices fall... yikes).

This is especially true if you are using Frequentist approach, and Evan Miller provides great reasoning for why it's bad in his article. Basically, Frequentist approach requires reaching a predetermined sample size (typically users in both Treat and Control variant), otherwise the results can't be considered trustworthy, and the chance of picking the wrong variant increases from the standard 5% up to 27.5%. Quite a high false positive rate, isn't it?

Bayesian is much better in this regard as there is no predetermined sample size you need to wait for, though you still should respect relevant seasonality, typically weekly.

Ignoring Twyman's Law

This happens to everyone who's starting with AB tests. You run it, are careful not to fall into the trap of concluding it too early, check the results ... and they are amazing. The data shows your feature is a great success!

Unless it isn't. It turns out, most of the time, the results are not significant and there is a bug in play. Time for Twyman's Law citation:

"Any figure that looks interesting or different is usually wrong"

Most likely, either the bug is in your feature, tracking, the way you evaluate the AB test or just the experiment design. Either way, you need to double check before you present your results to the rest of the company, which is something I wish I knew earlier.

No Triggering

Imagine you have a site which both anonymous and registered users can visit, and you introduce a new feature only for the registered users there. The act of making sure you evaluate the experiment only with users who were impacted (or could have been if they weren't in control variant) is called Triggering.

Without it, you'd factor in also anonymous users which would dillute the results, decrease sensitivity and prolong the test runtime, if not make it impossible to evaluate properly.

Incomparable variants

Let's imagine you introduce a new banner saying "20% OFF" in your online shop, but, and this is important, it's meant only for new users on their first purchase.

Tracking users in Treatment is easy; if the banner gets displayed, you know they entered the experiment. So far so good.

But when does the Control enter the experiment? After all, there is no banner to track. If you factor in all users, both new and existing, you'll get the No Triggering problem from above, but even worse, only for your Control group now. So you end up comparing apples to oranges, and will get invalid results.

The solution is to take the same Treatment condition, apply it in Control and track as if the new banner was displayed for Control too, but without actually displaying it. This technique is called Counterfactual tracking and is indespensable in such scenarios.

Sample ratio mismatch

SRM describes a situation when you have, let's say, 2 variants - Control and Treat - but there is a big discrepancy in user allocation between them, perhaps 60:40. Same as with AB test results, this discrepancy can be either insignificant, in which case you are fine, or significant and then you have a problem.

Having SRM means there is probably a bias in how you allocate users to the A/B/n variants and it can have a significant impact on your results to the point of invalidating the AB test completely. Finding out its root cause is key.

While writing this piece I discovered there are many more AB testing pitfalls so maybe I'll do a part 2. Let me know in the comments if you made those mistakes yourself and which one tripped you up the most.

The most anticipated JS conference in 2024, for you

Daniel Macák — Wed, 06 Mar 2024 14:13:07 +0000

I haven't been to a JS conference for a while, and I'd like to attend one or two in 2024. But there are so many! Which one are you looking forward the most to, and what excites you about it?

Why you should NOT use Jest w/ Solid

Daniel Macák — Wed, 06 Mar 2024 07:18:13 +0000

When I was wondering how to introduce testing to my small Solid app which is not that small anymore, hence the need for tests, and also which testing framework to use, I mostly bumped into Jest. Solid's official guide recommends it too. We use it in bigger projects with NX and are somewhat content with it, so I thought, why not?

Jest

The official guide suggests both Jest and Uvu. I didn't consider the latter at all since the maintenance has been sporadic at best since 2020, so Jest was a clear choice. I followed their advice to

npx degit solidjs/templates/ts-jest my-solid-project

and copy the generated configs into my existing project.

The first thing I noticed was that Babel was used. I have nothing against Babel at all, but I don't like when the way testing code is processed differs from the "production" setup, because it creates room for differences and mistakes. Indeed, they even mention it in the guide that the tests won't be typechecked in this setup, only transpiled.

Secondly, I was shocked by the sheer number of dependencies. See for yourself:

    "@babel/core": "^7.23.7",
    "@babel/preset-env": "^7.23.8",
    "@babel/preset-typescript": "^7.23.3",
    "@solidjs/testing-library": "^0.8.5",
    "@testing-library/jest-dom": "^6.2.0",
    "@types/jest": "^29.5.11",
    "@types/testing-library__jest-dom": "^5.14.9",
    "babel-jest": "^29.7.0",
    "babel-preset-jest": "^29.6.3",
    "babel-preset-solid": "^1.8.9",
    "jest": "^29.7.0",
    "jest-environment-jsdom": "^29.7.0",
    "jsdom": "^23.2.0",
    "solid-jest": "^0.2.0",
    "solid-testing-library": "^0.5.1",

This is bad on so many levels. First of all, having so many dependencies is a recipe for problems when so many moving parts have to stay in sync. Secondly, I wasn't even sure what at least half of them was for! Frankly, it's a mess.

Indeed, I got to appreciate all this very soon because running pnpm test produced SyntaxError: Unexpected token 'export'. To keep this short, I can tell you I tried all the suggestions Jest gives on this topic but nothing worked. Jest claims to have experimental support for ES6 modules, but it's not exactly easy to use it, and it didn't help. And again, this could have been so easy, given my production setup already worked, only if Jest could use it without introducing its own.

After trying to get it work for an hour, I decided to give up on Jest and the official testing guide and try something else.

Vitest

I am sure you knew where this is going. Vitest is a Vite-native test runner, meaning if you already are using Vite, you can use the same pipeline for your production and testing code. Solid's starter template even uses Vite by default, so it fits in naturally.

Solid even has a template for this exact setup, but I decided to keep things absolutely simple, and followed Vitest's installation guide. This boiled down to installing these dependencies:

   "@solidjs/testing-library": "^0.8.6",
   "jsdom": "^24.0.0",
   "vitest": "^1.3.1"

Solid's testing-library for utilities, jsdom to be able to mount components, vitest as the testing engine. And to put cherry on top, I didn't have to change any configuration. Beautiful!

Key takeaways

Just use Vitest! Jest did a lot for us in the past years, but it can be a real pain to set up and packs too many dependencies.
Vitest should be the preferred testing solution in Solid's docs.

PS. I'll go down to Solid's Discord and suggest the change in the docs.

When NOT to use A/B tests

Daniel Macák — Mon, 05 Feb 2024 07:32:50 +0000

A/B testing is de facto the standard for determining which experience (treatment or control) is better. If you can, I definitely recommend running them, as it makes your launch/no-launch decision grounded. But even with enough users and proper setup, there are cases where A/B testing is not the answer. Explore with me why this might be the case and what are the alternatives.

When A/B is not the best idea

Sometimes it's better to use a different experimental method, other times an experiment is not needed or even possible at all. Let's see the cases in which a developer like you and me can question the need of A/B.

Not enough units

As I have highlighted in my previous article, one doesn't need that many users to run A/B tests. However, it might happen the circumstances lower the number of experiment randomization units (usually users) so much that A/B test can't be run.

Picture that you have enough users, but a certain experiment requires that you randomize by accounts instead, say because the experience must remain consistent between account members. Depending on the average size of the accounts, this can dramatically reduce number of units on which you can experiment, and it could take too long to gather any significant results.

Just launch already!

Here we are talking a situation where it's clear that the treatment experience is superior.

Imagine you have an online product which users can procure on your payment site. The product is great but the payment site not so much because when the payment fails, it gives the user no explanation why. This is frustrating since users don't know what to do next. Call the bank, recheck their billing details, or something else?

Now let's say you decided to solve this problem by displaying a nice dialog with an useful explanatory message and your first instinct is to A/B test it. You might think that users hate dialogs, therefore you would like to be sure it performs well. Or you just got into the habit of A/B testing everything and you love the dopamine rush when you've improved key metrics. No worries, it's addictive alright.

But the thing you might not realize is that while running the experiment, say for 2 weeks, the control group is exposed to objectively worse experience. Not only are your users frustrated but your business is losing them every day. While a dialog might not be the best UI widget to communicate payment failure, it's miles better than having no failure communication at all. In other words, you make the UX worse only to receive test results that are clearly expected. And since the launch/no-launch decision is clear upfront, and there is no learning to be made, running an A/B test is a waste here.

Large UI redesigns

Unless such redesigns are approached in step-wise, widget-by-widget fashion, big bang introduction of a new design probably doesn't make sense to be A/B tested.

Design phase

That doesn't mean you shouldn't keep control in other ways. First of all, you should have a clear goal in mind. Is it just a design refresh, or a larger overhaul of the UX to reduce friction? And is redesign needed at all? User Research will help you clear up these questions.

Whichever way you decide to go, it's always a good idea to start testing your designs asap to uncover problems and frictions, usually by using qualitative methods. So far, no quantitative experimenting is generally needed, unless you'd like to target specific areas of the UI and compare pre and post redesign components. This is not always possible as introducing newly designed components might be perceived as disturbing in context of the old design, but can otherwise be great at providing early learning and confidence in the redesign's direction.

Roll out phase

Generally it makes sense to gradually roll it out by traffic % and segments, eg. first to beta users, afterwards to new users only. So now is the time to launch the A/B test right? Not really, consider this:

The treatment UI can be so different from the old that you would be comparing apples to oranges
For that reason, your findings might not be actionable. If a certain widget underperforms, is it due to the widget itself, its surroundings or something user has/hasn't seen before?
If treatment underperforms as a whole, what do you do? Revert the treatment roll out until you fix it? How are users going to react to their UI switching from new to old and back? And isn't it too late for such findings anyway?

That brings us to an important point - A/B tests actually align with the Agile philosophy. They should make it easy, cheap and quick to test ideas and throw them away if they don't perform. A/Bing whole new UI after months of work isn't cheap nor quick, and lot of times the interested parties know that throwing away the new shiny UI is just not an option either.

Therefore, don't allow it come this far without knowing your redesign is a good idea. Validate it and test your concepts and designs early to keep the cost down should your approach be wrong. Once you start rolling out, by all means track both old and new UI and even compare them to eg. discover seasonality effects on your metrics.

If no A/B, what then?

Let me start by saying that even though A/B might not be possible in certain cases, you still have to retain control. It goes without saying that you should have solid monitoring in place in order to detect failures of all kinds. But equally important, you need a comprehensive tracking to keep an eye on the important metrics. If the number of purchases drops below acceptable threshold, you need to know about it asap in order to properly react.

But besides that, how do you make that launch/no-launch decision without an A/B test?

Interrupted time series (ITS)

Enter ITS. It is a quasi experimental design, one of most more reliable and universal to use in this class. I say quasi because control and treatment can't be randomized properly with it.

It works by measuring period before intervention (control), projecting it into the future (counterfactual) and comparing it with measurement after the intervention (treatment). The difference between the projection and actual treat measurements is the outcome of this method. The intervention is performed for all your users, that means control and treatment never exist at the same time.

The forecast should be done using an ML model to get the best precision.

Using ITS, you can work around cases where A/B is not possible or desirable and still compare control and treatment, yey! However, as most things in life, ITS is not a silver bullet, far from it actually. All quasi experimental designs have a common weakness - it's very easy to make a mistake and completely invalidate the results. In fact, it's not uncommon for quasi experimental methods to get their results completely refuted by a proper experimental designs later on.

In the case of ITS, you have to account for confounding effects, seasonality being the most obvious. To mitigate, the interventions can be toggled multiple times to explore seasonality's impact on the results. Still, there can be other confounds at play, and as such ITS requires great care when designing to discover those early on.

Long term holdouts

This term describes a situation where the new experience is rolled out to most people, typically around 90%, and the rest is left with the old experience for a longer time.

As you have probably guessed, this is in no way an experiment approach, but rather a verification step. It is usually used to spot novelty or other long-term effects (and as such can be used after an A/B test), but in my opinion it can be also used to give a peace of mind when rolling out treatment experience to almost all users without prior verification in an A/B test. An example could be that if you launched to 100%, and suddenly met with a dip in important metrics, you might be unsure if the treatment experience or other factors like seasonality are to blame. In contrast, having a small long term hold out might clear this question up.

However, it's important to say that withholding treatment from the holdout users, knowing it is superior, can be unethical, so use it wisely.

Conclusion

There are many cases where A/B tests are not possible or desirable. While it's definitely possible to keep control over launching new experiences without them, they are still superior to alternative methods of conducting experiments and should be preferred where possible.

Let me know what you think and I'll see you in the next one ❤️.

Sources

Kohavi R, Tang D, Xu Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press; 2020.
https://towardsdatascience.com/sample-size-planning-for-interrupted-time-series-design-in-health-care-e16d22bba13f

SolidJS: Purpose of the `keyed` attribute in

Daniel Macák — Tue, 02 Jan 2024 14:44:08 +0000

If you are like me, you are thoroughly confused by the keyed attribute in the <Show> control flow component from Solid's core library. Well not anymore since I'll explain everything. Let's talk why you should care and how to use it properly.

I first met with keyed when I wanted to use <Show> in a more convenient way. So typically one uses Show like this:

<Show when={currentUser()}>
  {children}
</Show>

And indeed if that's all you need, you don't have to care. The problem is that, if you are using any static type checking like TypeScript, the currentUser() part can at least in theory return falsy value. So if you plan to use it inside <Show>, you'd have to check for truthiness all the time.

<Show when={currentUser()}>
  <>
    <span>{currentUser()?.name}</span>
    <span>{currentUser()?.age}</span>
  </>
</Show>

Which is inefficient and tedious, but even worse it's logically unnecessary because you already know inside the <Show> that the currentUser() exists, otherwise it wouldn't get displayed. But since the type system doesn't have the guarantee that each call to currentUser() returns the same value, ie. it can be impure, it has to assume that subsequent calls to currentUser() can still return falsy value. And calling it inside <Show> JSX tag doesn't change that fact in any way, because <span>{currentUser()?.name}</span> is not scoped to <Show>, but rather to the whole component.

Enter the `keyed` attribute

There is actually great solution and that's using so called type narrowing render function, which looks like this:

<Show when={currentUser()}>
  {user => <>
    <span>{user().name}</span>
    <span>{user().age}</span>
  </>}
</Show>

It narrows the type of user to truthy value since it already knows it's truthy by showing Show's children. Perfect!

But wait a second, how's this connected to the keyed attribute? Well before Solid 1.7.0, it wasn't possible to use this render function without using keyed as well.

<Show when={currentUser()} keyed>
  {user => <>
    <span>{user.name}</span>
    ...

This, and the fact the docs don't explain keyed led to developers thinking this attribute is just about being able to use the render function, but that's wrong! Starting with Solid 1.7.0 the render function can be used also without keyed, but what's its purpose then?

Purpose of `keyed`

If you have experience with React, keyed is somewhat similar to React key. React uses it to keep track of DOM elements so that it can efficiently reuse them instead of destroying and recreating.

And so does Solid. If you don't use keyed, when you change currentUser to someone else, Solid expects the Show's content not to have radically changed and it reuses the already existing component references and their respective DOM nodes instead of destroying and recreating them, but it of course updates the content based on the changed reactive properties.

However if you use keyed and the value in when attribute has changed, Solid will actually recreate the Show's children from scratch. You can see it in this example:

Every time you click 'Change current user', currentUser's reference changes, which causes Show's children to be recreated and <UserDetails> prints 'mounted' to the console. But if you remove keyed from Show (don't forget to also rewrite user() to just user inside Show), it doesn't get mounted more than once.

Usage of `keyed`

I'd say you don't want to use keyed in most cases. First of all you might lose the benefit of type narrowing:

<Show when={currentUser()?.id} keyed>
  {id => <>
    <span>{currentUser()!.name}</span>
    ...

Notice that when now uses the id, not just the object reference. That's because in practice the currentUser() reference can change even though the user properties used inside <Show> can stay the same. As a result, the render function now accepts just the id parameter and not the whole user, which is not necessarily very helpful.

Secondly it can lead to unnecessary re-renders of <Show>'s content, typically when you use object references in when attribute. This can lead to undesired side effects. If your component performs initialization like fetching and it gets created from scratch every time the Show's when attribute changes, it can get pretty inefficient.

So much for dissuading you from using it. However, keyed can be still very helpful. If <Show>'s content needs to be completely recreated, keyed is a neat way to do so:

<Show when={currentUser()}>
  {user => 
    <Show when={user().id} keyed>
      <StatefulComponentXY user={user()} />
      ...

If it's not simple to accommodate StatefulComponentXY to a new user due to its state or the fact that the component shouldn't be visible with the previous user shown (the old user might be cached in a resource, waiting for refetch in the meantime), keyed is a simple way to ensure that. For this purpose, I use this perhaps strange pattern with <Show keyed> only checking the identity, not reference, of the principal object and when it changes, it recreates its content entirely.

Why do A/B testing?

Daniel Macák — Mon, 01 Jan 2024 16:16:47 +0000

I bet you have heard about A/B testing before, but are you actually using it? If not, maybe because it doesn't fit your project, but for a great number of developers controlled experiments (experiments which run A/B tests) are definitely relevant. In this piece I'd like to go through some great reasons to try them out!

We don't have enough users!

First of all, let me debunk the myth that controlled experiments are suitable only for tech giants, on the contrary!

The key point to understand is that these big companies are looking for small, incremental conversion rate (CR) improvements somewhere between +0.1-2%. But if you are a startup and you want to get that additional funding, you are looking for rapid, big improvements on the scale of 10% and (much) more which require proportionately less users to verify in an A/B test.

Example: You have CR rate 20%. To detect an absolute 0.1% improvement, you'd need 2.500.000 users. But to see a 5% (25% relative) you'd need only 1.000 users over the course of a few weeks! That's absolutely doable even for small startups.

Improve decision culture

With that out of the way, let's talk decision culture. Unfortunately, in many companies a (no)launch decision is being made based purely on opinion without any backing in the data. This of course can lead to launching features that worsen UX.

Using A/B tests to validate new features shifts the decision culture from opinionated to proof-based, which brings confidence into improving the product. Moreover it ends unproductive arguments in the team by providing evidence of which features work the best.

Lastly, A/B test results are often interesting for the stakeholders and increase management's trust in feature team's decisions since they are backed by data.

Learn

Learning from your experiments is at least as important as making that (no)launch decision. Each experiment tests a certain hypothesis and the outcome should say in detail whether it was correct and why. Over time, you'll be able to accumulate enough learnings to have an intuition of what works and what doesn't, which makes developing new features more effective.

Also, should someone else have the same initiative in mind that you already performed a while back, going back to those learnings will steer her in the right direction.

I also think that articulating the hypothesis and looking for the learning during the experiment helps the team understand better how their initiative ties to the company's strategy, which helps teams focus and work on things that really matter. This fact is incredibly important for companies big and small.

Conclusion

A/B testing is an important tool and a de facto standard when validating product's features. Using it will help you make better product decisions and improve communication inside and outside your team.

Sources

Kohavi R, Tang D, Xu Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press; 2020.
https://blog.statsig.com/you-dont-need-large-sample-sizes-to-run-a-b-tests-6044823e9992

Tools

https://www.growthbook.io/
https://www.evanmiller.org/ab-testing/sample-size.html

DEV Community: Daniel Macák

How to test TanStack Router

We are on our own here 😮

Complete example

Keep it real

Beware the pending state

Performance

Final thoughts

Astro + Vercel Serverless API

Edge Functions didn't work

Serverless Functions to the rescue

Wrap up

MVC in Frontend is Dead

MVC what?

MVC makes for a clean code ❌

MVC

No MVC

Organizing Controllers is complex 👎

MVC doesn't help with Caching 👎

Ad-hoc caching

Data fetching caching

MVC makes for a Better Testing ❌

It makes unit testing harder

No you can't just forget about UI in tests

But then I need to include React in my tests

State is in the Model 👎

State should be in the Model ONLY ❌

You can easily switch to different UI framework ❌

Is the touted case for an easy rewrite even valid?

So what's the better alternative? ✅

Code being clean ✅

Organizing Controllers ✅

Caching ✅

Testing ✅

State placement and syncing ✅

Wrap up

5 most frequent A11y Mistakes

1. Always relying on aria-label 😳

2. Disabling form elements

They are hard to see 🙈

They provide no explanation

3. Underestimating SR differences

4. Not knowing how users use SR 🤔

5. Misunderstanding the purpose of the Tab key

That's it!

Solid's Resource is great!

Alternatives

Architecture

That's it folks

5 steps to better unit/integration testing

1. Use setup functions

2. Prevent nesting

3. Treat your tests same as your production code

4. Find the right balance

5. Prefer integration over unit

That's all folks

5 Most common AB Testing Mistakes

Concluding tests too early

Ignoring Twyman's Law

No Triggering

Incomparable variants

Sample ratio mismatch

The most anticipated JS conference in 2024, for you

Why you should NOT use Jest w/ Solid

Jest

Vitest

Key takeaways

When NOT to use A/B tests

When A/B is not the best idea

Not enough units

Just launch already!

Large UI redesigns

Design phase

Roll out phase

If no A/B, what then?

Interrupted time series (ITS)

Long term holdouts

Conclusion

Sources

SolidJS: Purpose of the `keyed` attribute in

1. Always relying on `aria-label` 😳

Enter the `keyed` attribute

Purpose of `keyed`

Usage of `keyed`