refactor: vue implementation #85
Conversation
|
|
Hi @teleskop150750! Curious as to what's wrong with the current one? I tried to keep it 1:1 with the React implementation (including the use of Happy to know if there's a specific issue or limitation with the current implementation 🫡 |
packages/vue-db/src/useLiveQuery.ts
Outdated
| const unsubDerivedState = derivedState.subscribe(() => { | ||
| const newValue = derivedState.state | ||
| if (shallow(stateRef, newValue)) return | ||
|
|
||
| stateRef = newValue | ||
| state.value = newValue | ||
| }) | ||
|
|
||
| const unsubDerivedArray = derivedArray.subscribe(() => { | ||
| const newValue = derivedArray.state | ||
| if (shallow(dataRef, newValue)) return | ||
|
|
||
| dataRef = newValue | ||
| data.value = newValue | ||
| }) |
There was a problem hiding this comment.
I think @tanstack/store handles this already?
There was a problem hiding this comment.
Vue and tanstack libraries unfortunately have a very difficult fate (((
- the first reason is the reactors of the library @tanstack/store (drop
vue2, refactorunsub) - the current implementation of @tanstack/store uses a deep link, which makes no sense since the entire object gets replaced. Unfortunately, vue primitives are woefully behind solidjs.
Solid js uses reconcile for fine-grained updating. If desired, you can try writing an analogue for vue
packages/vue-db/src/useLiveQuery.ts
Outdated
| const results = shallowRef() as Ref< | ||
| ReturnType<typeof compileQuery<TResultContext>>[`results`] | ||
| > | ||
|
|
||
| const state = shallowRef() as Ref< | ||
| Map<string, ResultsFromContext<TResultContext>> | ||
| > | ||
| const data = shallowRef() as Ref<Array<ResultsFromContext<TResultContext>>> |
There was a problem hiding this comment.
Any reason on why we are not passing the types to the primitive instead?
like
const results = shallowRef<ReturnType<typeof compileQuery<TResultContext>>[`results`]>()There was a problem hiding this comment.
For
const foo = shallowRef<T>()
// foo: Ref<T | undefined>The output will actually be Ref <T | undefined> because we didn't pass a value
My implementation still follows the react code. The only difference is that I don't use vue-store For optimization purposes, 1 effect is used instead of 5 (1-watch and 4 computed) Because of some stereotypes and limitations of Api ref, people are afraid to use getter functions. {
collection: () => compiledQuery.value.results
}Changed input options interface to. deps: () => Array<unknown> = () => []I wrote about it in great detail here It seems to me that deps are not needed at all, because when calling |
Thanks for the detailed explanation and the references! From what I understand, your refactor aims to optimize for certain edge cases and performance, but it seems to come at the cost of clarity and idiomatic Vue code. Is that correct? re: deps array - I think this feature is similar to Nuxt's useAsyncData watch option for cases where you want to refresh the query based on other reactive variables that aren’t directly referenced in |
There is no point in this because the result of the query will be the same |
|
@wobsoriano Unfortunately I couldn't figure out where it came from. db/packages/vue-db/src/useLiveQuery.ts Line 47 in ac560ec db/packages/db/src/query/compiled-query.ts Line 153 in ac560ec |
Example vueuse |
|
I can agree with you that computed can be useful for lazy invocation. |
|
look at the experimental implementation with computed, I return the entire |
refactor: vue implementation