phryneas.de

Talks & Slides for React Advanced 2024 - Beyond React Testing Library: Testing React Libraries (and library-like code)

Fri, 25 Oct 2024 00:00:00 +0000

And another visit to London and the amazing React Advanced conference, where I announced @testing-library/react-render-stream to the world.

Beyond React Testing Library: Testing React Libraries (and library-like code)

Abstract (click to expand)

When it comes to testing library code, the (usually amazing!) “Testing Library” approach quickly hits its limitations: We often need to test hot code paths to ensure additional guarantees, such as a specific order of DOM changes or a particular number of renders.

As soon as we start adding Suspense to the picture, it even gets almost philosophical:

How do we count a render that immediately suspended, and how do we distinguish it from a “committed” render?
How do we know which parts of the Component tree rerendered?

In the Apollo Client code base, we’re using the React Profiler to create a stream of render events, enabling us to switch to a new stream-based testing method.

After testing this approach internally for a year, we have released it in a library that we want to present to the world.

Video

Talks & Slides for enterJS React 19 day - Was passiert eigentlich in einer App mit RSC so unter der Haube?

Thu, 17 Oct 2024 00:00:00 +0000

A very fun remote deep dive I did in German at enterJS React 19 day. Unfortunately I don’t think it has been recorded, but the slides should tell a story on their own.

Was passiert eigentlich in einer App mit RSC so unter der Haube?

Abstract (click to expand)

Nehmen wir an, wir haben eine App mit ein paar Serverkomponenten und ein paar Clientkomponenten. Was passiert da eigentlich auf dem Weg vom Server zum Server (ja, richtig!) zum Browser?

Ein paar kleine Spoiler: Es gibt mindestens einen Stream im Stream. Manchmal transportiert der Stream im Stream sogar noch weitere Streams. Darüber hinaus spielen noch eine Handvoll neuer Pakete (manchmal auch dasselbe Paket in unterschiedlichen Ausführungen) und Bundler-Plug-ins eine Rolle.

Wir schauen uns das an, und wenn die Zeit reicht werfen wir sogar einen Blick in den React SourceCode.

Slides

Talks & Slides for React Advanced London 2023 - The Rocky Journey of Data Fetching Libraries in React’s New Streaming SSR

Mon, 23 Oct 2023 00:00:00 +0000

I was at React Advanced to talk about all the stuff data fetching library authors have to do to support streaming SSR.

The Rocky Journey of Data Fetching Libraries in React’s New Streaming SSR

Abstract (click to expand)

If you use the Next.js app directory, you might not even have noticed it, but you are not only using React Server Components, but you are also using the new streaming SSR feature of React.

That means that on first page load, your Client Components will now be server-side rendered, suspense boundary by suspense boundary, and constantly streamed to the client, where they are rehydrated piece-by-piece.

If you combine that with suspense for data fetching in your client components, you will suddenly be facing hydration mismatches - as your client components will start fetching data on the server, but the data will not be transported to the client.

In this talk, I will go over the rocky journey that we had to go through to support suspense for data fetching in Streaming SSR with Apollo Client, looking at all the curious timing problems that come up with these technologies, and how we try to solve them as best as we can - always with the best possible user and developer experience in mind.

My take on the current React & Server Components controversy

Wed, 05 Jul 2023 00:00:00 +0000

There has been a lot of frustration in tech Twitter over the last few weeks.
Some people are frustrated with React Server Components, and some are frustrated with the way the React team communicates.
The React team is frustrated with that “pile-on” they are facing.
And everyone is right on their own terms, but we all communicate it in the most unproductive ways.

Twitter is notorious for this kind of discussion because nuance is lost due to its 280-character limit. But I still would like to explain my take on all of this.
So I’ll try to write a blog post instead.

Disclaimer: I’m explaining how things feel or felt to me. A lot of this is highly subjective. Other people might feel differently about the same things. I might just not have noticed things happening, which could have saved me a ton of frustration. This is my personal story, how I experienced it.

I love React Server Components

I love React Server Components. They are a super cool feature. It’s an amazing step forward.
But I am also super frustrated by the place I find myself in right now, wanting to support them.

I want you to understand my frustration

I’m a library maintainer. I am one of the maintainers of Apollo Client, Redux Toolkit and RTK Query. My job (in the case of Apollo) and hobby (in the case of the other two) is to make these libraries as easy & productive to use for their consumers as possible. I love to do that.

Helping users has gotten harder

But it has suddenly gotten a lot harder. People come to me with strange problems, and I can’t solve all of those for them.

People on StackOverflow are facing error messages they don’t understand. Turns out they created a new React project with the first recommendation on the React homepage and then just applied default settings.
They don’t know what a Server Component is, but they are writing Server Components now.
None of the three libraries works in Server Components as it did before. Apollo needs an extra library; the Redux-based libraries don’t really have RSC support at this point in time. I’ll get to the “why” on that later.
I can’t give them a 3-hour lesson on StackOverflow, and honestly, I also don’t really know where to point them.
There is not a lot of documentation that really explains why what they are doing doesn’t work, or how to do it better.
So I just tell them, “please use problematic-library only in Client Components”.
I don’t really feel like I’m helping people with that.
People come to us with bug reproductions that I don’t understand. Right now, I’m finding myself in the weird situation where I have to assume that this bug that people come to me with might not be in my library code, or in their code, but a React bug.
I recently spent two hours debugging an infinite loop. I was already at the point where I mocked out useSyncExternalStore when I remembered that I had seen someone else mention the issue on Twitter.
Turns out their code had an async component. Yes, their bug, but in the past, React would just have errored out with "Objects are not valid as a React child (found: [object Promise])." - but this is Next.js, shipping a canary version of React that allows Client Components to be async.
And that actually worked in an older canary.
But not in the newest one. And since this feature is there, but not documented as stable yet, the warning message has been removed and instead, we see this infinite loop.

Understanding things has gotten harder

Apart from that, of course, I am working actively on making our libraries better for our users - in all three environments that currently seem relevant: in React Server Components, in Client Components rendering on the server and streaming to the browser, and in Client Components on the browser.
Honestly, when I started this, I’ve never felt as lost before.
There was no public guidance on anything beyond basic RSC usage, and the Next.js docs - while they were already very good - were definitely not aimed at someone who would be writing a library.
I had to gather most of my information from Twitter discussions. At one point, Dan Abramov sat down with me on a video call and did a lot of explaining - and then later, he spent hours going over my RFC where I tried to write down what I had learned and corrected my misunderstandings and errors.
I am incredibly grateful for that, but at the same time, I look at all of the other React users out there, and I’m frustrated again.

Not everyone out there has a Dan sitting down with them and guiding them through this.
How frustrating an experience must this be for everyone?

Writing and maintaining a widely used library has gotten harder

The bundler is frustrating me to no end. Files imported from React Server Components are statically analyzed. If they contain any reference to hooks like useState, the bundler errors out.

The solution is that libraries now should ship one more entry point, aimed at React Server Components, that doesn’t contain any APIs referencing those hooks. This is already a big moment of frustration. You don’t just “add a new entry point”. Changing anything about a library’s bundler setup is like open heart surgery. One wrong move, and one of your other artifacts changes and breaks in a bunch of bundlers that worked before. It’s nerve-wracking and, frankly, something I’d want to avoid whenever I can. But okay, let’s assume that the ecosystem needs to go through all of this churn. Let’s also assume that I’m willing to essentially duplicate my whole library with RSC-friendly alternatives to all the exports I had in place before.

Now, this new entry point has to be added to the exports field in your package.json. If you already have an exports field, that’s not a problem. If you don’t have it, you’re back at the “breaking bundlers” stage. You can effectively only do that in a major version. This is a big no-go for all libraries that weren’t already planning a new major. (The Redux ecosystem is already at the stage where we were planning for a major anyways, so I’d say here we are lucky.)
If you can’t add that exports field, there is a workaround: If you don’t import the hooks from React as named imports, but as namespace imports - import * as React from 'react', current bundlers won’t pick up on that.

Let’s just hope we’ll have that workaround going into the future. I really don’t want to release a new major of Apollo Client just to ship a new entrypoint for RSCs, even if our users don’t use any of the Client-Component specific features.
Every major version we release will leave users behind (people are still migrating from Apollo Client v2 to v3, and v3 released in 2019!), and releasing a new version of a multi-platform library just to cater to a change in React feels wrong in that regard.

There’s also another pain point here that would be solved by shipping essentially a second RSC-friendly library as an alternative entrypoint, but that, in the meantime, has cost me enough frustration on it’s own, so I want to mention it: createContext is not available in RSC. So the ReactReduxContext that was a top-level export from react-redux could not be created and importing react-redux in a RSC environment was always a crash. This workaround is horrifying.

It feels like the browser is being ignored, and there is no feedback loop

When React 18 released, it shipped with Concurrent Mode, and Suspense was declared “stable” - with one little exception: Suspense for data fetching in the browser was not. So we were good ecosystem citizens and waited, and from time to time, someone dropped into our issues and asked why the library still had no support, and we pointed them to the React 18 release notes and shrugged.
At some point, the use RFC was released, and things started getting more tangible.
So, at the beginning of 2023, I started poking the React team, and the maintainers of Apollo Client, TanStack React Query, and Redux got a meeting with the React team. The message was essentially “yeah , you can try to write an implementation now”. So we did.
A few weeks later, I tried out suspense hooks in the NextJs app router, because our users had asked for that, and everything broke. We had almost released something that would not work with the future of React, because we had been good ecosystem citizens and had written out code against the latest stable release of React. Nobody had told us that things might get hairy in Server Components. We now have a helper library in place, and Apollo Client works nicely with suspense and React Server Components, so there’s not too much harm done here. But it shows a clear disconnect in communication: we only knew that Suspense for data fetching on the client was delayed because the React team was “working on something” and didn’t want their hands bound by things released in the meantime that would lock them into one direction or the other. But we didn’t know it that “something” was Server Components, the React Forget compiler, or something else entirely.

The use RFC also signals something else to me: The React team is trying to create a “symmetry” between Server and Client where it might not actually exist: The server renders once, and the client lives for a long time. A single promise might not be what you use on the client, because your data source might update repeatedly (in the case of a cache, think about updates from other components, requests, and optimistic updates). We need something more.

What frustrates me most here, though, is that we could have given our userbase some kind of suspense implementation years ago, and made their lives much better - if the React team had communicated more openly what they are working on, and had given us guardrails to stay in-between. Even without use, we could already have designed some interesting APIs. It would just not have been their “final form” yet.

This was “far into the future”, and suddenly became very urgent

I am not joking when I say that one week before the App Router (and with that, React Server Components) were declared “stable”, I sincerely believed that we would have at least six more months, probably more like a year, until RSC would get the “stable” blessing from the React team.
At that point, I was already very familiar with React Server Components, and had implemented most of the Apollo Client RSC glue package - so it was not “under my radar”.
But in the past, these “big changes” like this were announced as “this is coming in about X months” by the React team, and instead of that, we were all playing with some kind of “unstable React build” without any indication that this would become stable anytime soon. Not an alpha, beta, or release candidate.
Then, within two days, Canary releases were declared stable, and the App Router was declared stable as well.
The part of the ecosystem that had been waiting for a bigger “starting sign” that something was getting ready was completely overwhelmed by these announcements. I was only prepared for it by sheer luck - because a bunch of users had asked for it.

I still love React Server Components

Despite all these complaints, I want to repeat this paragraph. I am extemely frustrated. But I also see a ton of promise in React Server Components.
There is just a ton of work to be done for all of us.

I also have some suggestions

And that brings us to the part where I stop ranting and start making suggestions. And before I get to the suggestions: If I suggest a new API here, I would be happy to try and implement one or more of these features if the React of Next.js team communicate that they are interested in actually adopting them in the end!

Hide experimental things in Canaries

This is the most obvious win right now: I know that Canaries contain React code with experimental features. The problem is that these Canaries are shipped as part of “stable” Frameworks. As a result, users get exposed to these experimental features, might accidentally start using them, and have things breaking in the future. This is extra sneaky in the case of async functions: in the past, this would have provoked an error from React, and now in some canaries it just works, and in others you see an infinite loop.
I know it might not always be feasible, but can we get feature flags to hide these features in Canary builds here? Throwing errors if a user accidentally uses an unstable feature would really help a lot!

(Much has been said about documentation what actually is in these Canaries, and I believe it already has been heard loudly at this point, so I’ll skip that suggestion here.)

Trying to get the client and server user experience in symmetry

Right now, a lot of concepts don’t translate well between RSC and CC (Client Components), and as a result, we have to give our users very different APIs for both of these environments.
I don’t think that’s necessary. With a few more primitives/conventions, we can create APIs that (apart from initialization) are used the exact same way between RSC and CC.
I believe this would help both adoption, and users switching between projects that are RSC-capable and those that are not.

Of course, I’m speaking from the point of a “data fetching library” here, but I think a lot of these points also apply to other libraries.

Familiar client patterns on the server

Expected usage on Client and Server:

function MyComponent() {
  const result = useQueryWithSuspense(query);

  return <h2>{result.data.title}</h2>;
}

Theoretically, it should be possible to offer this API in both environments. It would be a nice “symmetrical” API, moving a CC pattern into RSC.

The missing pattern

Unfortunately, there is a missing link for this: in a RSC, useQueryWithSuspense doesn’t have access to Context, and cannot get a user-defined client. This could almost be made to work with something like

let getClient;
function registerClient(makeClient) {
  getClient = React.cache(makeClient);
}

but there is no good way right now to ensure that the user code that calls registerClient is actually called, apart from littering it into all layouts and pages. There is no central entry point file in Server Components. It would be great if frameworks could offer a “bootstrap” entrypoint that would be executed every time before a server component renders. This is probably only a little tweak to Next.js & co, but would allow us to write this kind of symmetrical API.

“Server patterns” on the client.

This is more of a “server pattern” that would be great on the client:

function MyComponent({ maxPage }){
  const { readQuery } = useEndpoint()
  const pages = Array(maxPage).fill(undefined).map((_, pageNr) => readQuery(pageNr))

  return <>
    {pages.map(pagePromise => {
      const page = use(pagePromise)
      // ...
    })}
  <>;
}

This one is possible on the server, and it is kinda possible in the browser, with a lot of workarounds, but one gaping problem: In the browser, our component lives for a long time, and a data source might update externally, at a later point in time. Now, it could be solved as an implementation detail of useEndpoint to, in that case, swap out a promise in local state against a resolved one, and return that instead - but that would always force a rerender of MyComponent. In this example, that’s okay, but these pagePromise instances could also have been passed down to child components and only be used there. Currently, this would always cause an unneccessary rerender of the parent component, because we have to swap out those promises during a rerender.

The missing API

If we could use(observable) instead, we would not have this problem. So this is (not for the first time) my plea to give us this API. The server doesn’t need this - RSCs render once, and then everything is thrown away. But in the browser, components live for a long time, and they won’t need data from a promise only once. There will be updates.

Shipping features that are a pain (or impossible) to solve from a library, or even framework perspective

(in RSC/Streaming SSR) useStream

I’m just going to point at the RFC for useStream here. We really need this, as the current workarounds will differ from framework to framework and, at least with Next.js, also have very unfortunate timing. Only being able to inject data into the stream when a suspense boundary finishes can be far too late and lead to very problematic race conditions between Server and Browser.
This API is most vital in streaming SSR and less important in RSCs, but it might be a good idea to offer it there, too.

(in RSC/Streaming SSR) registerCleanupHandler

This goes hand-in-hand with useStream.
It would be great to register a handler to be called after the last component has finished rendering, shortly before the stream is closed, to execute some cleanup logic and inject one last bunch of data into the stream.
Not having this means that on the server, connections could stay open (e.g. when receiving streamed data), receiving data that will not be accessible on the client anymore, and the client might not be aware that the server already stopped streaming, and still wait for that data instead of making a request on it’s own. This API would be equally useful in RSCs and streaming SSR.

(in Client Components) useComponentIdentifier(teardownFn?)

There was recently a great talk by Robert Balicki (slides video) that shows how much is necessary to get Suspense for data fetching working on the client. Components render, they suspend, they render again without knowing that they rendered before. As a result, there is an absurd dance that every library has to do in userspace to ensure that a (hopefully stable) promise is returned, and that data that is not needed anymore (because a component didn’t render in the end, or changed props in the meantime and requested different data) is disposed of correctly. We are talking reference counting, timers, all that jazz. React knows what the last promise for a component was when it restarts a component render, so it has some concept of component identity, even if a component didn’t commit yet.
It would save a ton of userspace workarounds (and, again, there is no good way to do this at all) if React would allow a component to ask for some kind of unique identifier. That could even just be an empty object to be used as a key in a Map or WeakMap. Bonus points if we could get some kind of “final teardown” callback to do a nice cleanup once a component is discarded.

And now?

Honestly, I don’t know. I could open RFCs for these features that I think are still missing, but I already wrote under the useStream RFC that we really need something like this and even offered to implement it. There was no feedback to it, so I am not too hopeful that opening more RFCs or Issues in the Next.js GitHub Issues (that currently seem to be drowning in confused users and/or bugs) will lead to anything.
So instead, I’m writing this post. And I hope the right person sees it because the Twitter or Reddit algorithm sweeps it their way.
I’m open to talk about these ideas and want to help if I can. Please talk to me!

Talks & Slides for React Summit 2023 - GraphQL in 2023 - Still Relevant?

Tue, 06 Jun 2023 00:00:00 +0000

A remote talk I gave together with my teammate Jerel Miller at React Summit Amsterdam.

GraphQL in 2023 - Still Relevant?

Abstract (click to expand)

With fetching libraries like TanStack Query, swr, or RTK Query becoming more widespread, some of the immediate “selling points” of GraphQL clients seem to be less unique - so it might be a good idea to take a step back and ask the question “is this even still relevant?”.
And to already take the answer away - it is “yes”.
The unique selling points of GraphQL go far beyond having a smooth data fetching experience by solving many inter-team and architectural problems.
While it might not always be immediately evident as a benefit for us as Frontend Developers, GraphQL gives us a lot of freedom and makes us less dependent on backend teams implementing a Backend-for-the-frontend for us.
Also, while data-fetching libraries have made it a lot easier to work with REST nowadays, GraphQL still has properties that are just not present in traditional REST APIs, and on top of that GraphQL has kept evolving.
New directives like @live or @defer enable developers to create a fantastic user experience with very little work - especially when combined with React’s new suspense features.

Slides
Video

Talks & Slides for c't webdev 2022 - Redux im Jahr 2022 — alles anders?

Tue, 08 Nov 2022 00:00:00 +0000

This was a live coding talk I gave at c’t webdev in Cologne in German.

Redux im Jahr 2022 — alles anders?

Abstract (click to expand)

Wenn man an Redux denkt, hat man oft erst Mal sehr viel “rituellen” Code vor dem inneren Auge. ACTION_TYPE Konstanten, immutable Logik in switch..case reducern mit tief verschachtelten Spread-Operatoren, handgeschriebene “Action Creator” Funktionen und arkanes Store-Setup — all das am besten verteilt auf dutzende Dateien in der ganzen Codebasis.

Nichts könnte von moderenem Redux weiter entfernt sein — denn Redux hat sich in den letzten Jahren massiv verändert — die benötigte Boilerplate wurde stark entschlackt und moderner Code ist noch etwa ein Viertel dessen, was man früher geschrieben hätte — und Code für Api-Interaktionen wird sogar mittels RTK Query auf wenige Zeilen je Endpunkt reduziert. Insbesondere zwischen alter und neuer Nutzung mit TypeScript liegen welten.

Leider ist diese Veränderung in weiten Teilen der Community unbemerkt geblieben — zu viele Kurse und Tutorials wurden niemals geupdated und werden immer noch massenweise gelesen.

In diesem Talk stellt ein Maintainer der Bibliothek “legacy Redux” neben “modernes Redux”, zeigt auf, was sich geändert hat, was man heutzutage nicht mehr braucht und welche neuen Apis dazu gekommen sind.

Talk Repository

Talks & Slides for React Advanced London 2022 - Dealing with ADHD as a Developer

Mon, 24 Oct 2022 00:00:00 +0000

This was a remote talk I gave at React Advanced London in 2022.

Dealing with ADHD as a Developer

Abstract (click to expand)

“Hi, my name is Lenz and two years ago I was diagnosed with ADHD (attention deficit hyperactivity disorder).” Well, this is not going to be a self-help-group, but I think it is important to talk about this wildly underrepresented topic.

Since my diagnosis, I have spent a lot of time talking to other developers about it - and many of them also have ADHD, often a late diagnosis. It seems that we are quite the vulnerable population - or rather, it seems like a lot of ADHD people are drawn towards a developer job.

In this talk, I want to tell you about myself, how ADHD affected me and how the late diagnosis changed my life. But it didn’t only change my life - it also affected everyone around me. As colleagues, we have found a new level of understanding with each other that helped us more than any team-building event. And in the end, made us more productive since we now know how to better use our individual strengths, instead of trying to meet social expectations.

I will also talk about general ADHD symptoms and try to give you a rough overview on the topic - what kinds of treatments exist, what kind of coping strategies there are and where the line between “everybody is a bit forgetful” and “ADHD is an illness” lies.

You might recognize yourself in this. Or just a close friend or colleague. Either way, this talk will give you awareness & insights how the mind of a neurodivergent person can work differently - or it may even be an important wake-up-call.

Disclaimer: while I have an interest in the topic and am personally affected, I am not a trained professional on the topic and everything you hear here can only be an inspiration, but never medical advice.

Video

Do not create union types with Redux Action Types. It's most likely an antipattern.

Sat, 28 Nov 2020 00:00:00 +0000

So, there is a long-standing TypeScript & Redux pattern of creating a union RootAction type that contains all your application’s action types. Sometimes, you would also create a lot of reducer-specific sub-unions.
I think that this has always been a crutch - and given the options we have today, it’s most likely an antipattern.
So let’s look at why it was used, where it was used and what you can use instead.

Why was it used? A look at typed Reducers.

Classically, these action union types were created to use the Discriminating Union pattern.

This allowed you to do something like write a reducer like

const actionType1 = "a";
const actionType2 = "b";

type ActionA = { type: typeof actionType1; payload: { value: string } };
type ActionB = { type: typeof actionType2; payload: { value: number } };

type State = {};
type Actions = ActionA | ActionB;
function reducer(state: State, action: Actions): State {
  switch (action.type) {
    case actionType1:
      /* action.payload.value is inferred correctly here */
      return { ...state };
    case actionType2:
      /* action.payload.value is inferred correctly here */
      return { ...state };
  }
  return state;
}

In a world where switch…case reducers were the norm anyways, this seemed like a very handy pattern. It required a little extra work, like collecting all actions together in a central place and defining all those type constants, but those type constants were already defined anyways and due to all that boilerplate, building an extra union type didn’t seem so bad.

It all starts with a lie to the compiler.

There is a point about the discriminated union pattern that was missed though: A discriminated union has to be complete for it to work. Otherwise, you will hide errors.
In this specific case, it starts with a lie to the compiler: we’re telling tsc that this reducer function will only ever be called with an action that is a member of the Actions union.
But is it really? No, this reducer will be called by every action that is ever being dispatched in our application. So if we were only combining the action types we cared about, we’d already be lost. But what if we really went thorougly through the whole app, putting every single action type into that union?
It would still be incomplete.
Your application is not the only source of actions.
There’s also middleware, popular examples being “connected-react-router” which for example dispatched a '@@router/LOCATION_CHANGE'-typed action or redux-persist, which will dispatch a 'persist/REHYDRATE'-typed action.
And even if you went through all middlewares and also added their action types to the union, you’d still be missing the redux-internal 'INIT' action. Well, let’s just add that. Want to know a fun fact about INIT? In development mode, that action name is randomized to prevent developers from relying on that redux internal.
Bottom line? Your Actions type will never be complete, no matter how hard you try.

So having accepted that, we’ll probably do what most people (and, at this time, even the redux documentation on TypeScript) do and just create smaller sub-types, one small union for all actions we want to handle in a specific reducer. So, like in our example above, that type might even only contain two action types. Let’s assume it does.

What bugs are actually hidden by that little oversimplification?

Missing return statement

Let’s take our reducer from above and just remove that last return statement.

function reducer(state: State, action: Actions): State {
  switch (action.type) {
    case actionType1:
      return { ...state, /* action.prop1 is inferred correctly here */ }
    case actionType2:
      return { ...state, /* action.prop2 is inferred correctly here */ }
  }
-  return state;
}

This is definitely a bug. This reducer will now return undefined in case of that INIT action we discussed above. But TypeScript won’t notice. TypeScript assumes that this method will only ever be called with one of two action types - and both of these are handled. Because we are working on what seems (but really is not) a discriminated union here, union exhaustiveness checking kicks in and assumes that there will never any other return path and that this function will always return a State object.

Which it obviously does not.

Action shape might not be what it seems to be.

Also, did you notice that all actions in our union have a action.payload.value property? TypeScript will now allow us to directly access that property without any additional checks - after all, it will always be there - surely this method won’t be called with any other action.
Except for a lot of other actions. And at least that INIT type has no payload property, so we’re just one execution of our app away from the runtime error message

Uncaught TypeError: action.payload is undefined

A lie to the compiler is a lie to your team and your future self

Of course, all that doesn’t seem too bad. You’ll surely remember that you lied there and take all possible precautions that none of those above bugs happen. But will you really, a year or two down the line? Will a new team member that’s just getting onboarded and is not used to your little redux-lies yet?
You’re deliberately disabling TypeScript there, but it is not visible to anyone who doesn’t know the pattern. If you were any-casting, at least that would be visible. Here it’s not. Don’t do that if there are other ways to do the same.

But are there?

What to do instead?

The correct tool for this use case has been around for a long type: Type predicate functions.

A naive variation of a type guard function would look like this:

import { AnyAction } from "redux";

interface SpecificAction extends AnyAction {
  type: "somethingSpecific";
  payload: string;
}

function matchSpecificAction(action: AnyAction): action is SpecificAction {
  return action.type === "somethingSpecific";
}

function doSomething(action: AnyAction) {
  if (matchSpecificAction(action)) {
    action.payload; // this is correctly inferred to `string` here
  }
}

Of course, this does seem to be a lot of code when writing it by hand - but it can be automated. And it can be automated a lot better than manually having to combine action types.

If you are using redux toolkit, all your action creators created by createAction and createSlice will already have such a type guard:

import { createAction } from "@reduxjs/toolkit";
import { AnyAction } from "redux";

const myAction = createAction<{ value: string }>("my/action");

function doSomething(action: AnyAction) {
  if (myAction.match(action)) {
    action.payload.value; // this is correctly inferred to `string` here
  }
}

and if you are not using redux toolkit, you could for example use this helper function that attaches a .match(action) function and a .type property to every action creator you pass into it:

import { AnyAction } from "redux";

type Matchable<AC extends () => AnyAction> = AC & {
  type: ReturnType<AC>["type"];
  match(action: AnyAction): action is ReturnType<AC>;
};

function withMatcher<AC extends () => AnyAction>(
  actionCreator: AC
): Matchable<AC>;
function withMatcher<
  AC extends (...args: any[]) => AnyAction & { type: string }
>(actionCreator: AC): Matchable<AC>;
function withMatcher<AC extends (...args: any[]) => AnyAction>(
  actionCreator: AC,
  type: ReturnType<AC>["type"]
): Matchable<AC>;
function withMatcher(
  actionCreator: Function & { type?: string },
  _type?: string
) {
  const type = _type ?? actionCreator.type ?? actionCreator().type;
  return Object.assign(actionCreator, {
    type,
    match(action: AnyAction) {
      return action.type === type;
    },
  });
}

Now you can just wrap your action creator in withMatcher and use it like in the example above!

const createActionA = withMatcher((payload?: string) => {
  return {
    type: "foo/bar",
    payload,
  };
});

Why the additional type you ask? That might come in handy when we talk about redux-saga later ;)

With all this, your Reducer<MyState, MyActions> lie to the compiler becomes a valid Reducer<State, AnyAction> and will probably look something like this:

function reducer(state: MyState, action: AnyAction): MyState {
  if (specificAction.match(action)) {
    return { ...state /* action is correctly inferred here */ };
  }
  if (anotherAction.match(action)) {
    return { ...state /* action is correctly inferred here */ };
  }
  return state;
}

The bugs from above? Don’t apply any more.

Of course, you can reduce that down quite a bit using createReducer or createSlice from @reduxjs/toolkit, which is the official recommendation and which you really should be using.

With createSlice, it would look like this:

const slice = createSlice({
  name: "counter",
  initialState: { value: 0 },
  reducer: {
    // will result in an action of type `counter/increment`
    increment(state) {
      // state values can be modified mutably thanks to `immer` integration
      state.value++;
    },
    incrementBy(state, { payload }: PayloadAction<number>) {
      state.value += payload;
    },
  },
});
// automatically generated action creators with correct types
export const { increment, incrementBy } = slice.actions;
export default slice.reducer;

No matter what you use, your reducers should be covered now. No more lie to the compiler, no more collection type definitions over multiple files in a central location and creating unwieldy unions.

Where was it used as well/what to use instead?

Of course, that union type was used in several patterns with other libraries & use cases as well. Let’s look at them!

Redux Observables

Before:

export const epic = (actions$: Observable<MyActions>) =>
  actions$.pipe(
    ofType(INCREMENT),
    map((action) => {
      // action is correctly typed here
    })
  );

After

export const epic = (actions$: Observable<AnyAction>) =>
  actions$.pipe(
    filter(increment.match),
    map((action) => {
      // action is correctly typed here
    })
  );

So we are just moving from the special case ofType that tried to pull it’s own “discriminating union” over the observable action type to the more general filter method that just accepts any type guard function.

Redux Saga

Redux saga already works out-of-the box with action creators that have a .type property for effects like take with another saga as the second argument. So using both redux toolkit action creators as well as the withMatcher-created action creators from above will work just fine without any further modifications.

But, generally redux-saga with TypeScript is a bit of a pain: the result of a yield is just never defined, so you still need the types around for manual casting:

import { take } from "redux-saga/effects";

function* exampleSaga() {
  // cannot be inferred and needs to be manually typed
  const action: IncrementActionType = yield take(slice.actions.incrementBy);
}

But… did you know that there is a library called typed-redux-saga?

import { take } from "typed-redux-saga";

function* exampleSaga() {
  // correctly inferred as { payload: number; type: string; }
  const action = yield* take(slice.actions.incrementBy);
}

It slightly changes the semantics of yielding effects: instead of yield, you are now using yield*. But apart from that, everything is the same. And it just works, with type inference at every corner!

Custom Middleware

Custom middleware works just like the reducer example above: switch ... case becomes if ... else with type guards. Nothing to worry about here.

Dispatch

Now, all that said, there is one last valid-ish use for an application-wide MyActions type: Some people want to prevent wrongly typed actions to be passed into dispatch. Yes, I get you. But also: Are you serious? You are going around and hand-writing actions in the first place?
My solution: make it a rule in your team to always use action creators. Those will also be typed correctly and work as an equally good solution. All without going through the work of manually gathering all your action types in one place.

By the way: If someone were to write an eslint rule for that, we’d probably be very happy to ship that with redux toolkit as a recommendation ;)

Talks & Slides for the iJS Munich 2019 - reducing global React state and TypeScript for React developers

Wed, 23 Oct 2019 00:00:00 +0000

This fall, I did two talks on the international JavaScript Conference in Munich. One talk was about avoiding global state in React applications (in German), the other talk was an introduction to TypeScript for React developers.

Warum Global State keine eierlegende Wollmilchsau ist – und was wir wirklich nutzen sollten (German)

Abstract (click to expand)

In vielen React-Applikationen hat sich der Trend etabliert, die Global-State-Managementlösung (meist Redux oder MobX) zu verwenden – als Allheilmittel für alles, was auch nur im entferntesten mit State zu tun hat. Aber während der Gedanke insbesondere angesichts unzähliger Tutorials naheliegt: irgendwie fühlt es sich meist unhandlich an. Außerdem arbeiten wir damit “an React vorbei” und machen oft genug React-interne Performanceoptimierungen kaputt.

Zum Glück gibt es für viele Anwendungsfälle inzwischen bessere Lösungen, mit denen wir den Herausforderungen einer modernen React-Applikation beikommen können – am Ende bleibt ein globaler State, den man auch guten Gewissens so nennen kann.

Der Talk stellt verschiedene Arten von State in einer modernen React-Applikation vor und analysiert, welche Spielweisen besser nicht in den globalen State gehören (natürlich auch: wohin denn dann?). Beispiele, wo der globaler State weiterhin eine wichtige Rolle spielt und wie wir ihn klüger nützen können, runden den Vortrag ab.

TypeScript for React developers

Abstract (click to expand)

TypeScript adds static typing to JavaScript – and you can use it when developing applications with React. I will introduce you to the basic concepts of static typing and will show you how to use TypeScript with React. We are going to discuss not only the benefits but also the downsides of this approach. I will also show you how you can benefit from TypeScript when using state management libraries such as Redux.

Abstract by Hans-Christian Otto, who I filled in for with this talk.

Video

Talks & Slides for the iJS London 2019 - The State of React’s State in 2019

Tue, 14 May 2019 00:00:00 +0000

I was over in London to talk about the state of React’s State handling ecosystem in 2019, comparing plain Context, Redux, MobX, MobX State Tree and local State with Apollo.

The State of React’s State in 2019

Abstract (click to expand)

In the past few years, the approach to application state in React has been constantly shifting. Local component state has been complemented with global state management solutions like ‘react-redux’ or ‘mobx-react’. The introduction of GraphQL libraries like Apollo brought new approaches to API caching (at least for GraphQL). With the release of React 16.3, the reworked Context API has been finally declared stable, adding a viable option for small and simple global states.

As a part of the forthcoming React 16.7, hooks will allow for easier use of local state as well as context in function components. Existing libraries are already discussing new hook-compatible APIs that will change the way we are using them. Furthermore, the upcoming ‘suspense’ mechanism is bound to spawn the birth of at least a few new libraries with focus on “perceived local” data fetching and caching.

Unfortunately, there is no “one size fits all” solution when evaluating these approaches. This talk will highlight the different types of state occurring in modern React applications and give recommendations on how to approach them with the tools currently available, with an outlook on the near future.