Typescript, React Query, and Startups!
By Alec Johnson
About this collection
3 Months ago I started working at my first _real_ startup. At the time the company was 4 people, and there were zero full time frontend engineers. I've never had so much control over the direction of a codebase before, and it was difficult, at first, to weigh the pros and cons of learning the existing libraries the team had been using vs moving to ones I was more comfortable with. One of the most impactful decisions I made was that we were going to move to Tanstack (React) Query, leaving behind the existing fetching implementation in Vercel's SWR. This is a collection of some of the most useful blog posts and guides that I used in order to orchestrate a complete migration from SWR to React Query in a week, the kind of thing that would take months (or not even be possible) at a large company. From stronger types on the errors and return values, to a much simpler configuration on cache invalidation, I have zero regrets!
Curated Sources
You Might Not Need React Query | TkDodo's blog
The article discusses whether React Query remains necessary with the advent of React Server Components. React Query is a library for managing asynchronous state on the client, but Server Components allow data fetching on the server. The author concludes that for new applications using mature frameworks like Next.js or Remix, React Query might not be needed if they have good data fetching and mutation support. However, React Query remains useful for complex use cases like infinite scrolling, offline support, and interval fetching. The author also notes that not all applications will adopt Server Components due to various reasons like non-Node.js backends or mobile app development. React Query can still be used for non-data-fetching purposes and in hybrid approaches combining Server Components and client-side data fetching.
Key Takeaways
- For new applications with mature frameworks like Next.js, React Query may not be necessary if they have robust data fetching and mutation support.
- React Query remains valuable for complex use cases such as infinite scrolling, offline support, and interval fetching that aren't well-supported by Server Components.
- A hybrid approach combining Server Components for initial data fetching and React Query for client-side fetching can be beneficial for certain applications.
- Not all applications will adopt Server Components, and React Query will continue to be useful for those with non-Node.js backends, mobile app development, or non-data-fetching use cases.
Type-safe React Query | TkDodo's blog
The article discusses the importance of type safety in React Query applications using TypeScript. It highlights the challenges of achieving type safety, particularly when using libraries like axios for data fetching. The author emphasizes the need to trust type definitions and avoid manual type assertions. The article introduces zod, a validation library that allows defining schemas for runtime validation and type inference. It demonstrates how to use zod to validate network responses and ensure type safety in React Query applications. The author also discusses tradeoffs, such as performance overhead, and mentions tools like tRPC and zodios for end-to-end type safety.
Key Takeaways
- Using zod for schema validation can ensure type safety in React Query applications by validating network responses at runtime.
- Manual type assertions can be avoided by typing the data fetching functions or using zod for schema validation.
- End-to-end type safety can be achieved with tools like tRPC and zodios, which provide upfront API definitions and schema validation.
- Schema parsing comes with a performance overhead and should be used judiciously based on the application's requirements.
React Query - The Bad Parts | TkDodo's blog
The document is a transcript of a talk about React Query, a popular data fetching and state management library for React applications. The speaker, Dominik, discusses the tradeoffs and misconceptions surrounding React Query, addressing common criticisms such as its bundle size, lack of normalized caching, and complexity. He presents data showing React Query's growing adoption and positive sentiment among developers. Dominik also explains how React Query's declarative approach to data fetching works and why it's designed to handle async state, not client state. He concludes by discussing the limitations of React Query and when it might not be the best choice, such as when normalized caching is required or when managing client state.
Key Takeaways
- React Query's bundle size is often misreported, with the actual minzipped size being around 9-12 kB, which is relatively small considering the features it provides.
- React Query is designed for async state management and is not suitable for managing client state, for which other libraries like zustand or xstate/store are more appropriate.
- The library's declarative approach to data fetching can be misunderstood as being unable to handle imperative data fetching, but it's actually designed to handle it in a way that avoids common pitfalls like race conditions.