query

Great to see this--there are some nice features that encourage using standard web technologies like forms, and some solid quality of life improvements. However, I'm disappointed (but not surprised, this was listed as out of scope for 19) that triggering Suspense is still basically "use a framework that supports it." I have not been able to find any documentation or blog posts about the mechanism. I've tried to figure out how it works by looking at TanStack Query, but I've had limited success so far. I've found they're copying React's twist on Promises [1], but I haven't gotten this to work yet. I know the general idea is you throw Promises, but Suspense explicitly forbids using promises created during rendering. This means you can't just interrupt the component's initial render to load some data, and then restart it when its data is avail

A common convention I've seen is using T at the start of a type parameter, [1] for example. TKey, TData, TError, TSuccessCallback, etc. I always liked T at the end, but I've not seen that as often. [1] https://github.com/TanStack/query/blob/59a6d3df3035d6effeaed...

so cacheTime was really confusing because it seemed like "this is the amount time we cache data for", but that's not what it is. So a rename had to happen. We had some discussion on the public roadmap (https://github.com/TanStack/query/discussions/4252) about what it's gonna be. I'm usually against abbreviations, simply because there's always someone who doesn't understand what it means. But all other suggestions like inactiveCacheTime also had room for interpretation. gc is an abbreviation that is known well enough (think git gc), and it's also not an option that you will customize on a daily basis (usually once, globally).

> When I build libraries for React, ironically, I don't really use hooks like useState, useReducer, etc. One of the best perks (and footguns) of managing your state outside of react is that you get to have full control over when a component should rerender. I don't understand this quote from Tanner. Aren't React hooks, like, the only way to tell a function React component (while inside of it) to re-render? And if you look at the code of, say, the useBaseQuery hook of tanstack-query, you will indeed find React's native hooks being used there [0]. 0 - https://github.com/TanStack/query/blob/main/packages/react-q...

With `useSWR` the return type is export interface SWRResponse<Data = any, Error = any> { /** * The returned data of the fetcher function. */ data: Data | undefined /** * The error object thrown by the fetcher function. */ error: Error | undefined mutate: KeyedMutator<Data> isValidating: boolean isLoading: boolean } https://github.com/vercel/swr/blob/14956a840ac9b75fe321bf846... so if I check `isLoading` in my component then typescript isn't able to narrow/refine the type to something more specific since it isn't a sum type. While with react-query, it's a proper sum type that can be differentiated by checking `isLoading`. The type is actually quite long so here's just a bit export type QueryObserverResult<TData = unknown, TError = unknown> = | Query

I recently created ~25 full-stack example projects using the most recent technologies and frameworks. I believe the following stack is the most productive, yet very scalable (doesn't use "leaky" abstractions). Frontend: - Good, old, Single Page App. I believe that all these SSR/isomorphic rendering frameworks are a lot of times just unnecessary complexity. - Vite.js + your preferred framework (Vite supports React/Vue/Svelte, etc). Backend: - Node.js + Typescript. - Trpc.io - while it's not "automatic generation of REST endpoints", it's very close. It's very easy to write your endpoints, and the added flexiblity/control is definitely worth the time spent writing them. - Trpc also has a built-in support for subscriptions: https://trpc.io/docs/subscriptions - Prisma + Postgres. Good, old, proven, flexible SQL database is always

Perhaps the React-Query source itself is a good example of when "simple" is still not "easy to read/write": I picked out this file pretty arbitrarily: https://github.com/TanStack/query/blob/main/packages/react-q... The author of react-query seems to be very clear at communicating how the library works and the library itself provides a great developer experience, but it's also an example of how much work can go into correct typing in library code.

They're both awesome and I think have borrowed ideas from each-other. I went with React Query because I like the query key format (object instead of a string with SWR). https://github.com/tannerlinsley/react-query#query-keys

If you want a lightweight cache, check out react-query[0]. It's a nice abstraction around fetching data, and it handles caching out of the box, as well as refetching data when the browser regains focus and a lot of other nice things. 0: https://github.com/tannerlinsley/react-query

Repository, https://github.com/tannerlinsley/react-query

What's the motivation behind this hook? Does it do anything better than two of the biggest data fetching hooks swr (https://github.com/zeit/swr) or react-query (https://github.com/tannerlinsley/react-query)?