Conversation

Disclaimer: This is just personal preference, I'm not saying one is better than the other: I would start out with react-query, url state (really looking forward to 's new router) and local state. You can totally get away w/o global client state.
Quote Tweet
Hey @tannerlinsley or @TkDodo if you had to start a production project what would you use? Zustand/reactquery. Or rtk/redux? Just wondering about options and why? I’m leaning towards z/rq because of it’s modularity
5
57
If there comes a time where I need it, I would (and did in the past) go with zustand. It's the easiest to pick up for new team members. I also like jotai but it comes with a bit of bigger learning curve. Zustand is "more manual" but the good kind imo.
1
9
If you decide to go with redux, I would go all-in. Reasons for me would be: - you like "one tool to rule them all" - you prefer a single place to declare your queries upfront
1
5
Second point is probably one of the biggest differences between RQ and RTK-Q. I just don't like to define one big api slice, but to each their own. We also don't do one big zustand store, but multiple, smaller ones.
1
4
We still use rtk on one project (since before it had rtk-q). It works fine, but we don't do much fancy stuff in there (no async at all). The devtools are great!
1
3
It has opinions (like including immer), and if you don't care or don't have different opinions, that's perfect. Especially if you're a young team starting out and need guidance - the docs are great (lengthy, but worth the read)
1
3
the url in nextjs is a bit weird, especially if you do ssr. You can't read query params on the first render. I haven't gotten into it in detail as of yet.
1
1
Show replies
I’ve been having a look at trpc and the examples Ive seen tend to be nextjs/trpc. It hasn’t clicked for me yet because the nextjs repo hosts the api and frontend. This means they can also share the same models and be typesafe anyway? I’m looking for my next ZOD moment.
1
1
With nextjs, it allows you to write api endpoints on the server and consume them in a typesafe way with react-query, but without needing to manage keys. There's also runtime input validation with zod and types are inferred from that.
Show replies