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: (breaking) api overhaul #45

Merged
merged 22 commits into from
Dec 7, 2023
Merged

feat: (breaking) api overhaul #45

merged 22 commits into from
Dec 7, 2023

Conversation

kalijonn
Copy link
Collaborator

I wanted to get your feedback on some of the changes. some tests are still breaking here.

My idea was to use as much from tanstack query as possible with very little implementation in jotai. With this, I've setup conditions which make suspense work only if suspense is true. tanstack query wants users to be explicit about suspense. Even in v5, they're creating new hooks (useSuspenseQuery) rather than making suspense default. This goes against jotai's default implementation? useAtom throws promise be default if it receives a promise.

Another one is refetch. some of the tests indicate that refetch triggers suspense but that's different from tanstack query. tanstack query does not trigger suspense when a query is refetching.

})

return resultAtom
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the implementation mostly similar to atomsWithQuery? Any fundamental difference?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation would be very close to atomsWithQuery with some differences in how we handle features like suspense, keepPreviousData (I've been working on this locally not in the PR yet). I'll update this PR soon.

I didn't have an opinion on how to handle those but having tested things out quite a bit more in the past week, I think we should keep things consistent with what users expect from tanstack. Refetch shouldn't trigger suspense. Suspense should be opt-in, probably with atomWithSuspenseQuery (for v5) like you mentioned. Let me know what you think.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should keep things consistent with what users expect from tanstack.

I agree with it. That's the major goal of the overhaul #42.

@dai-shi
Copy link
Member

dai-shi commented Sep 27, 2023

Even in v5, they're creating new hooks (useSuspenseQuery) rather than making suspense default.

In that case, the better abstraction might be separating atomWithQuery and atomWithSuspenseQuery.

@dai-shi
Copy link
Member

dai-shi commented Sep 27, 2023

And, it feels like the new jotai-tanstanck-query version should use v5, no?

@kalijonn
Copy link
Collaborator Author

Even in v5, they're creating new hooks (useSuspenseQuery) rather than making suspense default.

In that case, the better abstraction might be separating atomWithQuery and atomWithSuspenseQuery.

I agree.

And, it feels like the new jotai-tanstanck-query version should use v5, no?

they released a release candidate 2 days ago. I think the work I'm doing can work for both v4 and v5 with very little changes.

@dai-shi
Copy link
Member

dai-shi commented Sep 27, 2023

In that case, the better abstraction might be separating atomWithQuery and atomWithSuspenseQuery.

I agree.

Let's try that then.

they released a release candidate 2 days ago. I think the work I'm doing can work for both v4 and v5 with very little changes.

Do you want to continue supporting v4 for your new api? I think it can only be for v5.

@codesandbox-ci
Copy link

codesandbox-ci bot commented Oct 1, 2023

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 2da7b56:

Sandbox Source
React Configuration
React TypeScript Configuration

Comment on lines 37 to 42
// feels hacky.
// Right after the reset is set, we need to set it back to clear so that when we refetch, it doesn't think it's in a reset state
store.sub(isResetAtom, () => {
Promise.resolve().then(() => store.set(valueAtom, 'clear'))
})

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to replicate QueryErrorResetBoundary which is implemented in @tanstack/react-query and not core.

This bit feels hacky. I'm not sure if there's a cleaner way to do it in jotai

@kalijonn
Copy link
Collaborator Author

kalijonn commented Oct 1, 2023

I'm going the route of separating creating atomWithQuery and atomWithSuspenseQuery. will do the same for other *WithQueries as well.

atomWithQuery passes all tests. I've adjusted the tests to keep them inline with tanstack/query functionality.

created a new component QueryAtomErrorResetBoundary, to use in the place of QueryErrorResetBoundary from tanstack. tanstack's boundary uses context. I don't think we can use that directly within jotai atoms. tanstack-reference

@@ -0,0 +1,48 @@
import React from 'react'
import { Provider, atom, createStore } from 'jotai'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels very strange.
Basically, jotai-tanstack-query is a package for Jotai, but it should be independent from React. Jotai atoms is framework-agnostic, like tanstack-query/core.
Please consider making QueryErrorResetBoundary a recipe in docs, instead of providing it as a library function.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we could do something specific for react (jotai-tanstack-query/react), but I agree with you. It's probably better off as a recipe.

Also, I think I can come up with some framework agnostic solution to reset error boundaries.

Will take a look.

@kalijonn kalijonn changed the title feat: atomWithQuery feat: (breaking) api overhaul Dec 4, 2023
@kalijonn
Copy link
Collaborator Author

kalijonn commented Dec 4, 2023

@dai-shi everything except resetting error boundary support is done.

main changes:

  1. moved to v5
  2. separated suspense vs non-suspense

let me know what you think

@dai-shi
Copy link
Member

dai-shi commented Dec 6, 2023

Hi, thanks for working on this.
I can't review everything, but looking at atomWithQuery and its related code, it generally looks good. Great work!

I would like to discuss one fundamental idea. Sorry, if I raise it too late.
I don't remember which issues/discussions/chats we discussed,
but someone suggested to use query cache as the source of truth.
So, instead of creating query observer in each atom, we directly subscribe to query cache.
How does that sound? We would like to consider if it's a viable solution.

@kalijonn
Copy link
Collaborator Author

kalijonn commented Dec 7, 2023

I've looked into QueryCache and realized there's a lot of functionality that QueryObserver implements in terms of returing promises, conditionally fetching/pausing which we'll have to implement. We'd have to build our own QueryObserver.

While refactoring, I have tried to replicate the logic that tanstack hooks perform, in atoms. And in this process, I'm questioning that statement that 'query observer might not be a reliable source of truth'. I've been trying to add tests as issues come up. (most recent "on reset, atom wasn't suspending" - raised in discord)

For now, I haven't seen anything that points towards queryobserver not being reliable.

@dai-shi
Copy link
Member

dai-shi commented Dec 7, 2023

@kalijonn Can you join my Discord server and DM me? https://discord.gg/MrQdmzd

@dai-shi
Copy link
Member

dai-shi commented Dec 7, 2023

For now, I haven't seen anything that points towards queryobserver not being reliable.

Sounds good. If you considered it and the current conclusion is so, it's perfect.

@dai-shi dai-shi linked an issue Dec 7, 2023 that may be closed by this pull request
Copy link
Member

@dai-shi dai-shi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great contribution!

I don't think I can understand it fully, but it looks good from the jotai usage perspective. We should release it and collect feedbacks including bug reports.

We also need to update docs and add a migration guide.

},
"peerDependencies": {
"@tanstack/query-core": "*",
"jotai": ">=1.11.0"
"jotai": ">=1.11.0",
"wonka": "^6.3.4"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have a new depenency.

@dai-shi dai-shi merged commit e6f6cb7 into jotaijs:main Dec 7, 2023
2 checks passed
@kalijonn kalijonn deleted the kj/atomWithQuery branch December 7, 2023 14:18
@cyrilchapon
Copy link

cyrilchapon commented Dec 7, 2023

@dai-shi I might install this on my side project; give it a shot and feedback.
Any preferred channel ?

@dai-shi
Copy link
Member

dai-shi commented Dec 7, 2023

@dai-shi I might install this on my side project; give it a shot and feedback. Any preferred channel ?

That would be great! Please open a new issue in this repo for the feedback.
You can install from the csb build. See "Local Install Instructions" in: https://ci.codesandbox.io/status/jotaijs/jotai-tanstack-query/pr/45

BTW, from now on, @kalijonn will be a new maintainer of this package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Idea for overhaul
3 participants