NextJS 13.4 changed the game with the App Router and React Server components. The change to the state management model looks simple to start, but gets complex very quickly as you try to create the practical every-day user experiences that were straightforward in the pages model. We'll talk about the different state management models, how they work in the App Router, and how to decide which you should use.

React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization.

The prevalent advice on how to use React today is to use a framework: either to start with one or to incrementally adopt one. This deep-dive talk will explore why, and how to go about this with live code examples.

Server Components are arguably the biggest change to React since its initial release but many of us in the community have struggled to get a handle on them. In this talk we'll try to break down the different moving parts so that you have a good understanding of what's going on under the hood, and explore the line between React and the frameworks that are built upon it.

Server Components are the hot new thing, but so far much of the discourse around them has been abstract. Let's change that. This talk will focus on the practical side of things, providing a roadmap to navigate the migration journey. Starting from an app using the older Next.js pages router and React Query, we’ll break this journey down into a set of actionable, incremental steps, stopping only when we have something shippable that’s clearly superior to what we began with.

Some weeks ago I made my own implementation of signals, capable of updating 300k times the DOM in circa 600ms. Leveraging the Microtask Queue, I was able to bring that number down to 6ms, effectively improving performances by 100x. I wanna share how the Microtask Queue works and how you can leverage the Event Loop to improve performances.

When working with React it is important that we use the right tool for the right job. If not we will be missing out on the best performance and developer experience. While optimising AG Grid React Table we discovered a number of patterns that made significant improvements to the tables performance.

React's component model and one-way data flow give us a great mental model for building our apps, but debugging React apps can still be confusing. React's internals are a black box, and it's often hard to understand why components rendered or what caused errors.The Replay time-travel debugger makes it easier to debug React apps by letting you inspect what's happening at any point in time. But what if we could go beyond the usual debugger features, and build new debugging features that tell us more about what React is doing? Let's see how Replay's API makes that possible.

You've probably build one of these before: tooltips, date pickers, menus, teaching UI… they're all examples of “popover” content. Good news: it's going to get a whole lot easier to build these, with some proposed web platform features. You might not even need JavaScript. In this talk, you’ll learn all about the upcoming ‘popover’ attribute, when to use modality and access to the top layer.

Users have come to expect real-time collaboration from best-in-class apps like Notion or Figma. But widely available tools and infrastructure for building multiplayer apps are only just emerging. In this talk, we’ll explore the open-source framework Jazz and the two new ideas powering it: Conflict-free Replicated Data Types (CRDTs) and verifiable permissions. By building a whole app with nothing but React and Jazz, we’ll see how this new approach radically simplifies building not only real-time multiplayer apps, but any kind of app in which users interact.

Did you know that approximately 1 in 7 people are neurodivergent? Within that group there is an entire spectrum of people whose brains process information differently. However, as frontend engineers we often forget to take these idiosyncrasies into account, or choose to simply apply industry standards such as WCAG 2.1 AA without digging deeper. In this talk, Steph shares some of the ways you can create better web experiences for the neurodivergent.

At Microsoft, we're committed to providing our teams with the best tools and technologies to build high-quality mobile applications. React Native has long been a preferred choice for its high performance and great user experience, but getting stakeholders on board can be a challenge. In this talk, we will share our journey of making React Native a preferred choice for stakeholders who prioritize ease of integration and developer experience. We'll discuss the specific strategies we used to achieve our goal and the results we achieved.

For many app developers, GraphQL is instrumental in building great user experiences. With the introduction of React Suspense, developers have an ergonomic way to orchestrate loading states to improve upon the status quo. In this talk, the Apollo Client team will show you how we built a non-trivial application using Apollo Client’s new Suspense features, GraphQL features like the @defer directive, and how to combine them to build great user experiences in your own apps.

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.

How many times have you had to wait for your backend team to finish building the API so you can start your tasks? What if all you needed to move that task to in progress was the API contract? What if there was a library that did this for REST and GraphQL APIs and, at the same time, taking your tests to the next level? Join me and prepare to enhance your developer experience while learning all the battle-earned experiences of using one of my favorite libraries: Mock Service Worker.