Skip to content

Conversation

@Gerbuuun
Copy link
Contributor

In zero-solid, the query status error was added which forwarded the zero error to where the query is used.

I've tried to implement it here to reflect how other composables provide error values (specifically Nuxt's useFetch)
I decided to provide the refetch function only within the error just like zero-solid because in zero the concept of manually refetching should not really be a thing.

With this I changed some of the internals of the View class to reflect how useQuery provides the data.

Copy link
Collaborator

@maxstevens-nl maxstevens-nl left a comment

Choose a reason for hiding this comment

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

Solid change. If you can add a test which asserts the error state we're good to merge IMO. Something along the lines of the test in the solid diff would be great.

@Gerbuuun
Copy link
Contributor Author

What do you think about how this presents the error object?

export interface QueryError {
  refetch: () => void
  details: QueryErrorDetails
}

We now do not have a flat object like the solid implementation

return toValue(options)?.ttl ?? DEFAULT_TTL_MS
})
const view = shallowRef<VueView<HumanReadable<TReturn>> | null>(null)
const refetchKey = ref(0)
Copy link
Owner

Choose a reason for hiding this comment

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

I think we could use shallowRef

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.

3 participants