#Data manipulation before useFetch

1 messages ยท Page 1 of 1 (latest)

timber scaffold
#

Hi ๐Ÿ‘‹๐Ÿผ

const slug = useState('/');
const page = useState(3);

const { data, pending, error } = await useFetch('/api/something', {
  query: {
    slug,
    page,
  }
})

Let's say I have the code above. When either slug or page changes, it will trigger a new request.

And what I want to do is, when slug changes, I want to reset page to 1. Then I could think of something like:

const slug = useState('/');
const page = useState(3);

const { data, pending, error } = await useFetch('/api/something', {
  query: {
    slug,
    page,
  }
})

watch(slug, () => {
  page.value = 1
})

However this page.value = 1 happens after a new request. So, for example, if slug changes to /a, then...

1. request ({ slug: '/a', page: 3}) - canceled
2. request ({ slug: '/a', page: 1})

How can I prevent this? I couldn't find a way to change page before another request, without changing too much code here.

Thank you for reading!

candid pollen
timber scaffold
#

@candid pollen thanks for the reply. Although the variable is named slug, it's not connected to the nuxt's router. Anyway, I decided to accept having canceled requests ๐Ÿ˜… I could avoid it, but I'd prefer having cleaner declaractive code at this point.

obtuse drum
timber scaffold
obtuse drum
#

though that is mainly related to the dom ๐Ÿค”

timber scaffold
#

yeah I read that doc already, but I also thought that it was about when to run watchers (before updating the dom, or after)

#

So my question would be more about how vue's reactivity system works in which order ๐Ÿค”

obtuse drum