Feature(Devtools): make data of queries editable

[bastibuck]

It would be nice if one could edit data of queries directly inside the devtools without changing the actual return values of a potential mock or real backend running during development.

For example if I wanted to test and develop my UI with an empty list I could just remove all entries from a already fetched list instead of changing the server code to return an empty list, restart that thing and refetch my queries.

I therefor created this very early (visual) draft of making data editable inside devtools.

Will potentially need some guidance on how to best get the activeQuery into the right places to set the data from there onChange/onClick.

Open for suggestions and ideas :)

PS: focusing on string fields first, other types like numbers can follow once the functionality is in place.

[vercel]

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

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
query	⬜️ Ignored (Inspect)	Visit Preview		Oct 9, 2023 7:34am

[vossmalte]

Hi @bastibuck, I really like your proposal. I will check it out later. I was wondering if another form of manipulation would be better:
Serialize data as a (nicely formatted) string and display it in a textarea. This would allow any manipulation. On save unserialize and save the data if parsable.

What do you think?

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit c0244a6. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 1 target

• nx affected --targets=test:eslint,test:lib,test:types,test:build,test:bundle

---

Sent with 💌 from NxCloud.

[codesandbox-ci]

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 c0244a6:

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

[bastibuck]

That would make updating way easier. I'll take a look on Sunday.

Was currently struggling to identify the exact position in the objects and/arrays to update with my approach.

I bet it can be done. But as a first take I'd follow your idea. This would also allow for resetting the manually edited data back to what the cache originally had if we treat the manual edits as overrides.

[bastibuck]

I've updated the code to use a JSON editor as an initial draft. The previos approach with the input fields and delete buttons is still in the PR but would be removed upon a descion on what path to follow.

Concept and reasoning

It uses https://jsoneditoronline.org/ to make data editable and sets the activeQuery's data onChange.

• following @vossmalte 's idea of making the whole JSON editable as text instead of single fields and entries this PR now does exactly that. This allows for very easy updates to the cached data.
• I've hidden the editor inside a modal because it might take up a low of space and is not as really useable inside the small panel where also the Data Explorer lives
• I've hidden all controls of the original JSON editor package to keep the interface simple and chosen mode: "text" for the easiest editing experience
• I've tested and only minimally adjusted colors to match the theme as a proof of concept for theming

Open issues

Right now the editor doesn't have the greatest UX but it works.

The onChange event fires fairly quick and the editor then loses focus because it is re-initialized which makes changing content kind of hard and not a joy.
This could be avoided when using a stable editor instance and updating the content onChanges as well.

But before grinding out the edges I'd like to get feedback if this is a path we should continue. @TkDodo @vossmalte what's you opinion on this approach?

Next steps

• avoid re-initialization onChange
  • if successful check if UX is still as bad due to onChange triggering too quickly. If so use another event or a submit button or something
• will data always be somehow editable in JSONEditor?
• error handling on query-base (only enable modal on successful queries?)
• error handling for JSON content (show validation result somehow)
• handle refetches and new data coming in (keep override? replace with new data?)
• align styling with tanstack-query
• use betters icons for open/close buttons
• do we need a "reset"? We could trigger a refetch or store the original data somewhere
• clean-up ts-ignore and casting of content

[ardeora]

Hey there! Great work! Taking a look at this. One thing to keep in mind also is that TanStack Query is not opinionated on what the query data should be. So it's not necessary that all query data will always be JSON serializable. A query function could also return a Map, Set, Iterable, etc.

@TkDodo in such cases should the editor be disabled?

[TkDodo]

we're serializing those values with superjson, not sure if it makes sense to allow editing them or how hard it would be

[TkDodo]

Serialize data as a (nicely formatted) string and display it in a textarea.

I think I liked the inline editing better 🤔

[bastibuck]

I think I liked the inline editing better 🤔

Me too!

I just pushed a new version where it's possible to update string and number values. How do you like this approach?

The types for the new util function are still wonky and @ts-ignored for the first draft.

Additionally coming back to the original idea of this PR I made arrays clearable and single array items deletable. Don't think it makes a lot of sense to add something similar to other types than array. What do you think?

[codecov-commenter]

Codecov Report

Attention: 9 lines in your changes are missing coverage. Please review.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Files	Coverage Δ
packages/query-devtools/src/utils.tsx	52.58% <85.24%> (ø)

... and 80 files with indirect coverage changes

📢 Thoughts on this report? Let us know!.

[bastibuck]

@TkDodo @ardeora Added the missing handling for Maps and Sets.

Now the handling (deleting and updating) of text and number values inside Arrays, Objects (plain), Sets and Maps is done explicitly and per case. Very happy with how this turned out.

Anything else to address?

The remaining @ts-expect-error cases are somewhat hard to get rid off. If you have any idea let me know.

[TkDodo]

Thank you so much @bastibuck - great work ❤️