RTK Query 2.x / 3.x roadmap planning #4107
Replies: 1 comment 1 reply
-
TriageAwesome ideas! The triage and internal documentation are things I am heavily interested in, am happy to just get started with the google doc, the task isn't so large as to think we need a specific collaboration strategy for the google doc. So with that in mind I am happy to just do this step highlighted in the doc as a jumping off point.
As a general thought of things I encountered as someone who only recently came across the project. CONTRIBUTING.md could expand to be more inviting, although maybe conciseness is important in there. I'll list what I thought may be a worthy addition:
|
Beta Was this translation helpful? Give feedback.
-
|
Just to have it in the thread, this is the sheet with the initial issues passover |
Beta Was this translation helpful? Give feedback.
-
My big RTK-related objective for the year is to ship multiple improvements to RTK Query. I intentionally deferred all RTKQ-related work until after RTK 2.0 was out. We shipped 2.0, so now we can start focusing on RTKQ changes.
Here's my initial thoughts on where we're headed.
RTKQ Feature / Update Planning
There's a lot of prep work that will need to be done.
We currently have 240 open issues, and I estimate that maybe half of those are related to RTK Query feature requests and bug reports in some way. In particular, there's the "RTK Query API Pain Points" thread, which has a lot of comments, as well as the "RTKQ Infinite Query API design" thread, but lots more besides that.
The first problem is that we don't even have a good grasp of what all has been requested. There's probably duplicate feature requests or bug reports. We don't know what updates might need breaking changes, vs what's doable in minor versions.
My assumption is that we'll need to spend a lot of time planning out the work:
So, the first step is to collect that large list of requested features.
Ideally, I think I'd like a Google Docs spreadsheet, with the following info:
There's probably a few more columns we'll need to track as we get into actual planning ("breaking / non-breaking", notes on potential interplay with other features, roadmap / timeline targets, etc), but just having a coherent list of what changes we're even talking about would be a critical first step.
I am guessing I will probably have to be the one to make this list, but this would definitely be a thing that someone else could jump in and do for us!
(Also, it might not hurt to go do some comparisons vs Apollo, React Query, SWR, and Urql, and see if there's anything else obvious we would want to
stealtake inspiration from :) )Documenting RTKQ Internal Architecture and Behavior
Right now we have no docs for how RTKQ works internally, either big-picture or at the micro level. This is a problem for a couple reasons. Lenz and I are the only people who have actually worked on the RTKQ code. Lenz wrote it initially. I've gone in and made changes (such as rewriting the custom middleware a couple times to improve perf), but there's still areas I'm not overly familiar with.
Not only does this make it hard for anyone else to jump in, but we don't have any particular "spec" or "requirements" for RTKQ. The implementation and the tests are the only source of truth.
This is particularly a problem because we have a lot of very subtle timing behaviors, especially around things like promise resolution. The current behavior is effectively encoded into our tests, which have a lot of "do A, await promise, do B, await promise, expect result" logic, but there's not anything that specifically spells out in a more readable way that "we expect this promise to only resolve after a certain thing has happened", etc. The lack of docs / spec / requirements here will make it harder for us to make meaningful changes to any of that logic, because we won't know if we're breaking something or if the change was desirable.
RTKQ API Coherency
Lenz whipped up RTKQ's initial API design with some influence from Apollo and SWR (not so much from React Query, ironically), but the API surface has grown organically since then. There hasn't been any real consideration of how the various API options interact with each other. This has led to weird situations like the current intentionally-hacky pseudo-infinite-scroll approach that involves using
serializeQueryParamswith a fixed result, and themergeoption to merge into the cache.We should do some thinking about what possible changes to make the API design more coherent and sensible might look like.
Big Picture Features
Purely off the top of my head, the biggest things I'd like to ship are:
So that's my thoughts atm.
Better Docs
We could definitely use better documentation. A number of our usage guide pages are pretty short and don't have a lot of detail. I think some of the CodeSandbox examples might even date back to the RTKQ alphas. In general, all the docs pages could stand to be reviewed and likely updated.
Challenges
One big problem is that I am not a data fetching domain expert. Lenz is, but he hasn't had as much time to do major RTK work in the last year since joining Apollo. He's still around and can talk and discuss, but likely won't have much time to implement.
My lack of expertise here means that I don't have a good intuition for how possible API changes should behave. That makes it tough for me to decide if we should make a particular change, or what it should look like.
How Can People Help?
Some folks have expressed interest in trying to help out, but aren't sure where to start.
The issue triage is definitely something that someone else could do. It's pure grunt work (reading through issues, writing things down in a spreadsheet, etc), and doesn't really require knowledge of the codebase.
Writing docs about the internal setup of the codebase would both be useful and a good way to learn about how RTKQ actually works right now.
We can definitely use help updating the docs pages!
Beyond that, we're always happy to work with anyone who's genuinely interested in contributing - we can talk through issue priorities, discuss implementation approaches, review PRs, and provide other guidance.
Beta Was this translation helpful? Give feedback.
All reactions