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.
The video talk explores how to effectively use React Suspense and Apollo Client to enhance user experiences in web applications. It introduces the UseSuspenseQuery hook as a suspenseful version of UseQuery, which simplifies code by removing the need for loading booleans and states, allowing React Suspense to manage loading states. This talk highlights the importance of managing suspense boundaries to optimize the loading experience, suggesting that a single suspense boundary might not always be ideal. Instead, adding multiple boundaries can provide more granular control over loading transitions. The defer directive in GraphQL is discussed as a tool to improve performance by streaming slower data parts later. Additionally, the video touches on the integration of Apollo Client 3.8 features, like UseBackgroundQuery and UseReadQuery hooks, which enhance the React 18 transitions. Testing tools like Testing Library are recommended for testing suspense functionality. The video provides practical insights into reorganizing suspense boundaries and using suspense hooks, making it a valuable resource for developers looking to leverage Apollo Suspense and Apollo UseSuspenseQuery in their projects.
The talk focuses on using suspense and GraphQL with Apollo Client to build great end user experiences.
Apollo Client 3.8 includes new suspense hooks such as UseSuspenseQuery and features integrated with React 18 transitions.
Testing tools like Testing Library are recommended for testing components that use suspense to render fallbacks.
Suspense boundaries can be reorganized to control the loading experience, allowing for more granular control over which parts of the UI are rendered and when.
In addition to UseSuspenseQuery, Apollo Client 3.8 also introduced UseBackgroundQuery and UseReadQuery hooks.
You can check the Apollo GraphQL GitHub repository, specifically the Spotify Showcase project, for the code and more details about the demo.
The talk does not cover React server components, streaming SSR, or implementing support for suspense in a data fetching library.
The defer directive in GraphQL allows marking part of a query to be streamed in later, which helps load some data faster while deferring slower parts.
The speakers are Gerald Miller, a principal software engineer at Apollo, and Alessia Balissario, a staff software engineer at Apollo.
The UseSuspenseQuery hook is a suspenseful version of the UseQuery hook, designed to fetch data while integrating with React 18 suspense features.
We're excited to be here in London to talk about using suspense and GraphQL with Apollo client. We'll also discuss building great end user experiences. Let's quickly introduce ourselves. I'm Gerald Miller, a principal software engineer at Apollo, and you can find me online at Gerald Miller. I'm Alessia Balissario, a staff software engineer at Apollo, and I'm at AlessBell.
2. Introduction to React Suspense and Apollo Client#
This talk is about reintroducing core React suspense concepts in the context of client rendered web apps and focusing on how to fetch data in suspense with Apollo clients new suspense hooks. We won't cover React server components or streaming SSR. Check out the experimental Next.js package for more information.
Let's go back to 2018 when Andrew Clark highlighted the difference in loading states between native platforms like iOS and the web. React suspense goes beyond rendering loading states and provides a composable way of managing transitions. We'll be discussing suspense in the context of Apollo Client and the UseSuspenseQuery hook. Pay attention to the colored boxes on the screen, which represent areas of our UI with UseQuery hooks. Let's take a look at the loading UX.
Each component renders its own loading fallback and data as soon as the network request returns it. We're transitioning from UseQuery to UseSuspenseQuery. Let's start with the user menu component. We remove the loading Boolean and loading state as Suspense handles it. The query type becomes UserMenu query type in the Suspense enabled application. We see a blank screen briefly before the UserMenu is loaded. We'll need a SuspenseBoundary for a loading fallback.
Let's add suspense to our components one by one. We start with the UserMenu component, wrapping it with the Suspense component and using the UserMenu loading state as the fallback. After refreshing, we see the green highlight around the UserMenu in its loading state. Now we'll add suspense boundaries and use suspense query to the sidebar and Play bar components. We replace the imports with useSuspenseQuery, remove the loading boolean and state, and make the necessary changes in the layout.
I'm just going to copy this a bunch of times. And then let's make sure each of these use the right loading states here. This one is the play bar. Thank goodness for prettier, otherwise my code would look horrendous. Suspense is not a magic wand that we can wave at our code and have the UX improve. But now that all of our components are using suspense to show those fallbacks, we have a superpower here because we can reorganize these suspense boundaries. Let's make the first real substantive change here to the loading experience by wrapping our entire app in a single suspense boundary instead of those four granular boundaries for each component. So we have a single update to the screen now, just by virtue of being able to move that suspense boundary to the outermost level of our app. But now let's say we're starting to interact with our Spotify clone here. We want to listen to a different playlist. We see something interesting, which is that I see that suspense fallback show up when I navigate to another route here. We've gone a bit too extreme in one direction of having a single suspense boundary for our whole app. By transitioning the route, that transition and that network requests to fetch a new playlist is triggering that single suspense fallback for our entire application. Obviously, that's not the user experience we want here.
We add a second suspense component around our route to maintain the persistent layout while the inner route component suspends. When we refresh and navigate back to our react advanced playlist, the outer shell of our application unsuspends first, followed by a slight delay while fetching the route component. If the inner suspense boundary is ready to render before the outer suspense boundary, React coordinates the timings. We use the at synthetics directive in our queries to understand the timings. Deleting the synthetics directive and refreshing the page shows the effects of faster playlist route loading.
8. Optimizing Loading Experience with Defer Directive#
If our inner route component is ready to render before the outer shell, React can coordinate that for us. In the worst case, we'll have two updates to the screen, but in the best case, we'll have a single update. We can improve the loading experience by using the defer directive in GraphQL. This allows us to load some data faster and stream in slower parts later. When our route component is slower, we still see two updates to the screen.
9. Optimizing Loading Experience with Transitions#
Adding additional layers of suspense boundaries and loading fallbacks gives you more granular control over loading UX state transitions. We integrated suspense hooks with React 18 transitions to improve the loading experience. By using transitions and removing synthetic directives, we can avoid suspense fallbacks and keep the existing UI on the screen. Today, we learned how to migrate data fetching hooks to use suspense query, optimize the loading experience by moving suspense boundaries, use defer to add additional fallbacks, and mark network requests as transitions in React.
We didn't get to talk about the whole suspense story. We released two other hooks in Apollo client 3.8, use background query and use read query. In the future, we're working on Apollo client 3.9 with new APIs like suspenseful use fragment and lazy use background query. The code for this application is available in the Spotify showcase repo. Thank you for having us.
To test suspense in a component, use popular React testing tools like testing library. The philosophy is to test the app as users would expect, so the loading state remains the same. Using a single suspense boundary at the top level may negatively impact perceived performance, but additional boundaries can be added. Each component doesn't necessarily need a loading state, and the user menu loading state pattern is a syntactic sugar for non-suspense.
It's up to you. However that works in your app. In this application, we have different loading states, but in your case, it may only be one component. It depends. Thank you for your talk.
React Suspense is a feature designed to simplify and improve the process of handling asynchronous data fetching in React applications. It allows developers to manage the loading states of components seamlessly, enhancing the user experience by minimizing unnecessary loading indicators and providing a smoother transition between different states of the application.
The concept of Suspense in React revolves around the idea of deferring the rendering of a component until its data is fully loaded. This approach is particularly beneficial in complex applications with multiple data-fetching components, as it allows for better control over the user interface during data retrieval operations.
Testing Components with Suspense
Testing components that utilize Suspense involves using widely adopted tools from the React ecosystem, such as the React Testing Library. The primary goal is to simulate the user experience by testing the loading states and fallbacks of Suspense-enabled components. This ensures that the application behaves as expected when rendering placeholders, spinners, or loading text while waiting for data to load.
To effectively test a Suspense-enabled component, it's important to treat it as a black box from the user's perspective. This means focusing on the component's output and behavior rather than its internal implementation details. By doing so, developers can verify that the user interface remains consistent and intuitive across different loading scenarios.
Benefits of Multiple Suspense Boundaries
Using multiple Suspense boundaries within an application can significantly impact the perceived performance and user experience. A single Suspense boundary at the top level may cause delays in rendering content, especially if multiple network requests need to be resolved before displaying any data to the user. This approach can lead to a suboptimal user experience with prolonged loading times.
By strategically placing multiple Suspense boundaries throughout the application, developers can optimize the loading experience. This allows for more granular control over the display of content, enabling certain components to render independently and more quickly. As a result, users experience a more responsive interface with fewer delays between data retrieval and rendering.
Implementing Suspense in Apollo Client
The Apollo Client, a popular data-fetching library for GraphQL, has introduced new Suspense-enabled hooks that integrate seamlessly with React 18 features. The useSuspenseQuery hook is a suspenseful version of the traditional useQuery hook, allowing developers to fetch data while leveraging React's Suspense capabilities.
To implement Suspense in an Apollo Client application, developers need to replace the existing useQuery hooks with useSuspenseQuery. This involves removing the loading booleans and letting Suspense handle the loading state. By doing so, developers can eliminate unnecessary boilerplate code and rely on React's built-in mechanisms for managing asynchronous data fetching.
Enhancing User Experience with Defer and Transitions
GraphQL's defer directive is a powerful tool that can further enhance the user experience in Suspense-enabled applications. By marking parts of a GraphQL query as deferrable, developers can prioritize certain data over others, allowing for faster initial render times. This technique is especially useful for complex queries where specific fields may take longer to load.
In conjunction with React 18 transitions, developers can improve the loading experience by marking network requests as transitions. This tells React to maintain the existing UI while fetching additional data in the background, reducing the likelihood of disruptive loading states. By carefully managing suspense boundaries and transitions, developers can achieve a smoother and more fluid user experience.
Practical Application and Best Practices
When integrating Suspense into an application, it's crucial to consider the overall structure and layout. Placing Suspense boundaries at strategic points can help create a more cohesive and efficient user interface. Additionally, developers should focus on optimizing the initial render by prioritizing critical data and deferring less important information.
For applications with dynamic routes or complex data-fetching patterns, leveraging Suspense and transitions can make a significant difference in user satisfaction. By allowing components to render as soon as their data is ready, developers can minimize perceived loading times and deliver a more interactive experience to users.
Conclusion
React Suspense, combined with Apollo Client's new hooks, provides a robust solution for managing asynchronous data fetching in modern web applications. By understanding and implementing Suspense boundaries, defer directives, and transitions, developers can enhance the user experience and create more responsive interfaces.
The key to success lies in carefully planning the structure of the application and optimizing the data-fetching process. By doing so, developers can achieve a seamless and efficient user experience that keeps users engaged and satisfied with their interactions.
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.
This talk has been presented at React Advanced 2023, check out the latest edition of this React Conference.
The talk focuses on using suspense and GraphQL with Apollo Client to build great end user experiences.
Apollo Client 3.8 includes new suspense hooks such as UseSuspenseQuery and features integrated with React 18 transitions.
Testing tools like Testing Library are recommended for testing components that use suspense to render fallbacks.
Suspense boundaries can be reorganized to control the loading experience, allowing for more granular control over which parts of the UI are rendered and when.
In addition to UseSuspenseQuery, Apollo Client 3.8 also introduced UseBackgroundQuery and UseReadQuery hooks.
You can check the Apollo GraphQL GitHub repository, specifically the Spotify Showcase project, for the code and more details about the demo.
The talk does not cover React server components, streaming SSR, or implementing support for suspense in a data fetching library.
The defer directive in GraphQL allows marking part of a query to be streamed in later, which helps load some data faster while deferring slower parts.
The speakers are Gerald Miller, a principal software engineer at Apollo, and Alessia Balissario, a staff software engineer at Apollo.
The UseSuspenseQuery hook is a suspenseful version of the UseQuery hook, designed to fetch data while integrating with React 18 suspense features.
The video talk explores how to effectively use React Suspense and Apollo Client to enhance user experiences in web applications. It introduces the UseSuspenseQuery hook as a suspenseful version of UseQuery, which simplifies code by removing the need for loading booleans and states, allowing React Suspense to manage loading states. This talk highlights the importance of managing suspense boundaries to optimize the loading experience, suggesting that a single suspense boundary might not always be ideal. Instead, adding multiple boundaries can provide more granular control over loading transitions. The defer directive in GraphQL is discussed as a tool to improve performance by streaming slower data parts later. Additionally, the video touches on the integration of Apollo Client 3.8 features, like UseBackgroundQuery and UseReadQuery hooks, which enhance the React 18 transitions. Testing tools like Testing Library are recommended for testing suspense functionality. The video provides practical insights into reorganizing suspense boundaries and using suspense hooks, making it a valuable resource for developers looking to leverage Apollo Suspense and Apollo UseSuspenseQuery in their projects.
We're excited to be here in London to talk about using suspense and GraphQL with Apollo client. We'll also discuss building great end user experiences. Let's quickly introduce ourselves. I'm Gerald Miller, a principal software engineer at Apollo, and you can find me online at Gerald Miller. I'm Alessia Balissario, a staff software engineer at Apollo, and I'm at AlessBell.
2. Introduction to React Suspense and Apollo Client#
This talk is about reintroducing core React suspense concepts in the context of client rendered web apps and focusing on how to fetch data in suspense with Apollo clients new suspense hooks. We won't cover React server components or streaming SSR. Check out the experimental Next.js package for more information.
Let's go back to 2018 when Andrew Clark highlighted the difference in loading states between native platforms like iOS and the web. React suspense goes beyond rendering loading states and provides a composable way of managing transitions. We'll be discussing suspense in the context of Apollo Client and the UseSuspenseQuery hook. Pay attention to the colored boxes on the screen, which represent areas of our UI with UseQuery hooks. Let's take a look at the loading UX.
Each component renders its own loading fallback and data as soon as the network request returns it. We're transitioning from UseQuery to UseSuspenseQuery. Let's start with the user menu component. We remove the loading Boolean and loading state as Suspense handles it. The query type becomes UserMenu query type in the Suspense enabled application. We see a blank screen briefly before the UserMenu is loaded. We'll need a SuspenseBoundary for a loading fallback.
Let's add suspense to our components one by one. We start with the UserMenu component, wrapping it with the Suspense component and using the UserMenu loading state as the fallback. After refreshing, we see the green highlight around the UserMenu in its loading state. Now we'll add suspense boundaries and use suspense query to the sidebar and Play bar components. We replace the imports with useSuspenseQuery, remove the loading boolean and state, and make the necessary changes in the layout.
I'm just going to copy this a bunch of times. And then let's make sure each of these use the right loading states here. This one is the play bar. Thank goodness for prettier, otherwise my code would look horrendous. Suspense is not a magic wand that we can wave at our code and have the UX improve. But now that all of our components are using suspense to show those fallbacks, we have a superpower here because we can reorganize these suspense boundaries. Let's make the first real substantive change here to the loading experience by wrapping our entire app in a single suspense boundary instead of those four granular boundaries for each component. So we have a single update to the screen now, just by virtue of being able to move that suspense boundary to the outermost level of our app. But now let's say we're starting to interact with our Spotify clone here. We want to listen to a different playlist. We see something interesting, which is that I see that suspense fallback show up when I navigate to another route here. We've gone a bit too extreme in one direction of having a single suspense boundary for our whole app. By transitioning the route, that transition and that network requests to fetch a new playlist is triggering that single suspense fallback for our entire application. Obviously, that's not the user experience we want here.
We add a second suspense component around our route to maintain the persistent layout while the inner route component suspends. When we refresh and navigate back to our react advanced playlist, the outer shell of our application unsuspends first, followed by a slight delay while fetching the route component. If the inner suspense boundary is ready to render before the outer suspense boundary, React coordinates the timings. We use the at synthetics directive in our queries to understand the timings. Deleting the synthetics directive and refreshing the page shows the effects of faster playlist route loading.
8. Optimizing Loading Experience with Defer Directive#
If our inner route component is ready to render before the outer shell, React can coordinate that for us. In the worst case, we'll have two updates to the screen, but in the best case, we'll have a single update. We can improve the loading experience by using the defer directive in GraphQL. This allows us to load some data faster and stream in slower parts later. When our route component is slower, we still see two updates to the screen.
9. Optimizing Loading Experience with Transitions#
Adding additional layers of suspense boundaries and loading fallbacks gives you more granular control over loading UX state transitions. We integrated suspense hooks with React 18 transitions to improve the loading experience. By using transitions and removing synthetic directives, we can avoid suspense fallbacks and keep the existing UI on the screen. Today, we learned how to migrate data fetching hooks to use suspense query, optimize the loading experience by moving suspense boundaries, use defer to add additional fallbacks, and mark network requests as transitions in React.
We didn't get to talk about the whole suspense story. We released two other hooks in Apollo client 3.8, use background query and use read query. In the future, we're working on Apollo client 3.9 with new APIs like suspenseful use fragment and lazy use background query. The code for this application is available in the Spotify showcase repo. Thank you for having us.
To test suspense in a component, use popular React testing tools like testing library. The philosophy is to test the app as users would expect, so the loading state remains the same. Using a single suspense boundary at the top level may negatively impact perceived performance, but additional boundaries can be added. Each component doesn't necessarily need a loading state, and the user menu loading state pattern is a syntactic sugar for non-suspense.
It's up to you. However that works in your app. In this application, we have different loading states, but in your case, it may only be one component. It depends. Thank you for your talk.
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
This Talk is about interactive data visualization in React using the Plot library. Plot is a high-level library that simplifies the process of visualizing data by providing key concepts and defaults for layout decisions. It can be integrated with React using hooks like useRef and useEffect. Plot allows for customization and supports features like sorting and adding additional marks. The Talk also discusses accessibility concerns, SSR support, and compares Plot to other libraries like D3 and Vega-Lite.
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up). Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too. Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step. (Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?
There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.
Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.
The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.
React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning? In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests. Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Summit 2023
Comments