feat(devtools): enable setting loading/error via devtools

[paul-sachs]

Allows the devtools to toggle loading and errors states (at least until the next fetch is triggered).

Things to do:

• [ ] Make sure onError get's triggered

https://user-images.githubusercontent.com/11449728/197222942-bc22a1ae-0ecf-476f-8ad8-d741267a708d.mov

[codesandbox-ci[bot]]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit a4ff17eb7f27b1c1c05337334a5652a4453b7184:

Sandbox	Source
@tanstack/query-example-react-basic-typescript	Configuration
@tanstack/query-example-solid-basic-typescript	Configuration
@tanstack/query-example-svelte-basic	Configuration
@tanstack/query-example-vue-basic	Configuration

[codecov-commenter]

Codecov Report

Base: 91.84% // Head: 92.16% // Increases project coverage by +0.31% :tada:

Coverage data is based on head (356e26e) compared to base (48e806b). Patch coverage: 97.56% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4352      +/-   ##
==========================================
+ Coverage   91.84%   92.16%   +0.31%     
==========================================
  Files         111      111              
  Lines        4146     4187      +41     
  Branches     1072     1087      +15     
==========================================
+ Hits         3808     3859      +51     
+ Misses        317      307      -10     
  Partials       21       21              

Impacted Files	Coverage Δ
packages/query-core/src/query.ts	99.02% <ø> (ø)
...kages/react-query-devtools/src/styledComponents.ts	92.85% <ø> (ø)
packages/react-query-devtools/src/devtools.tsx	89.09% <97.56%> (+5.16%)	:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[TkDodo]

@paul-sachs thanks for this PR, and sorry that it went unnoticed for a while. I've fixed some issues and did a bit of refactoring.

What would be missing from my perspective would be:

• some tests of the new behaviour
• a way to make the loading state revert back when clicking the button a second time, and maybe some visual feedback that we are now in loading state (similar to what the offline toggle button does)

would you like to continue contributing this?

[paul-sachs]

Hi @TkDodo I'll take a look for sure. I'll need to familiarize myself with the testing setup but that should be fine. Storing the previous state is a little tricky if I remember correctly. I think we can have it retrigger the query to restore behaviour. Either way, I'll look into it.

[TkDodo]

I think we can have it retrigger the query to restore behaviour. Either way, I'll look into it.

That's fine - I like the resetQueries approach that you've already taken for the error state. But the only way to get out of the loading state right now is to click refetch, and I think it would be good if the button behaved like a toggle. Alternatively, we could keep the last state in a ref before overwriting it and then restore it maybe?

[paul-sachs]

I'd worry what would happen if something toggles loading state during loading. I'm not sure how setState works internally, don't know if it will abort the on going promise. Feels a little like reset is our safest bet. Either way really, the toggle behaviour makes sense.

[paul-sachs]

So I've fixed the toggle state, however this approach doesn't seem to work in suspense mode since the setState doesn't trigger a promise... This will need something else to work through that issue.

[paul-sachs]

Was hoping to do something like:

activeQuery.fetch({
  queryFn: () => new Promise((resolve, reject) => {}),
  cacheTime: -1,
})

But i don't think that's replacing the queryFn like I thought it would. It triggers a refetch of the existing queryFn...

[paul-sachs]

Ah no, i was incorrect. It is using the updated queryFn. At least, I think it is. The problem is trying to store the previous queryFn so I can restore it...

[paul-sachs]

Alright, managed to get suspense working. Had to store some query state inside queryMeta so not sure I feel great about that, but it does keep query state all together. Maybe there's a better place to store it?

Next, I'll take a look at the testing infrastructure to figure out how to write some tests.

[paul-sachs]

@TkDodo Tests are up and green. I've represented the current state of the query in the buttons themselves but let me know if you want a totally different direction.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated
query	⬜️ Ignored (Inspect)			Mar 15, 2023 at 8:09AM (UTC)

[paul-sachs]

Alright, finally got to fixing prettier + lint issues.

[TkDodo]

Thanks for this ❤️ there are still some rough edges, like:

• trigger loading
• trigger error
• restore error
• restore loading --> now nothing happens 🤷

I still think this is good enough and we could tackle this in follow-ups. Maybe we shouldn't have two buttons after all, but just one option that puts the query into a certain "state", either loading or error, and one reset that just puts it back to avoid having to tackle multiple states?

[paul-sachs]

@TkDodo My apologies for letting this drop off. I'll submit a follow on PR with the suggested changes. Thanks so much for merging this, it'll make modifying loading states so much easier!