8000 feat: Better structural sharing in tanstack-query · Issue #6306 · trpc/trpc · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Better structural sharing in tanstack-query #6306

Open
1 task
aldebout opened this issue Dec 10, 2024 · 5 comments · May be fixed by #6311
Open
1 task

feat: Better structural sharing in tanstack-query #6306

aldebout opened this issue Dec 10, 2024 · 5 comments · May be fixed by #6311
Labels
✅ accepted-PRs-welcome Feature proposal is accepted and ready to work on

Comments

@aldebout
Copy link
aldebout commented Dec 10, 2024

Describe the feature you'd like to request

TRPC uses superjson by default to provide types beyond json-serializable ones, however this breaks default structural sharing in tanstack-query.
The most obvious impact is that any native Date field in a response object will cause the data object returned by a useQuery hook to have a different identity.

Discussion for context: TanStack/query#6481

Describe the solution you'd like to see

Given that trpc uses superjson by default, I think I'd like to see a default structuralSharing function that handles equality for the types handled by superjson.

Describe alternate solutions

  • Userland functions
  • An external package that provides the functionality and can be easily dropped in. This might already exist but I was not able to find a suitable lib.
  • Lobby popular parsing packages (superjson, I use devalue) to add replaceEqualDeep equivalent functions, since the logic of the two operations are tightly related. Using two different algos could introduce very hard-to-detect bugs.

Additional information

Adding a default function would be a breaking change :)

I don't know what the performance impact of everything would be.

👨‍👧‍👦 Contributing

  • 🙋‍♂️ Yes, I'd be down to file a PR implementing this feature!

Funding

  • You can sponsor this specific effort via a Polar.sh pledge below
  • We receive the pledge once the issue is completed & verified
Fund with Polar
@KATT
Copy link
Member
KATT commented Dec 10, 2024

We only support json serializable values on purpose. If we start to support date, we also need Set / Map and everything else. You can always pass your own function to structuralSharing

Originally posted by TkDodo in TanStack/query#6481 (comment)

Happy to have our react-query package to include a utility function that worked for this, would you be down to making it happen?

@KATT KATT added the ✅ accepted-PRs-welcome Feature proposal is accepted and ready to work on label Dec 10, 2024
@aldebout
Copy link
Author

Happy to take a stab at it!

Two main questions for which direction to go:

  • Do we want this to be an export that people can use or are we ok with introducing a breaking change?
  • What scope should we aim for? Same as superjson or a subset?

@juanrgon happy to get your input on this :)

@juanrgon
Copy link
juanrgon commented Dec 11, 2024

@aldebout

Do we want this to be an export that people can use or are we ok with introducing a breaking change?

Personally, I would prefer this to be built-in behavior of trpc

What scope should we aim for? Same as superjson or a subset?

I don't think it should be specific to supersjson, because other transformers besides superjson are supported by trpc.

I like @gaearon's suggestion of using a subset of Structured Clone Javascript Types: TanStack/query#6481 (comment)

@KATT
Copy link
Member
KATT commented Dec 11, 2024

(please don't @ random people that aren't related to thread or tRPC, it's not nice to their GitHub notifications)

@aldebout
Copy link
Author

@KATT I DMed you on discord :)

@aldebout aldebout linked a pull request Dec 11, 2024 that will close this issue
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✅ accepted-PRs-welcome Feature proposal is accepted and ready to work on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants
0