URL state not available via getters

[tordans]

This ticket is now about #400 (comment) by damian-balas.

(I moved my report to #404.)

[franky47]

Thanks for the detailed report. I'll have a look later, but at first glance, it looks like your initialisation performs side-effects in the render function, which is not recommended by React.

There are a few other things to consider:

• In development, React will always render twice, due to Strict mode.
• Updates to the URL are not synchronous, so they may occur after the second render, which could explain the discrepancies you observe.

[damian-balas]

@franky47 I've found a weird behavior. I won't go into details until you say it's a real issue.

The case:

1. I update in ComponentA the query with setter from

const useMenuQueryState = () =>
  useQueryState('menu', parseAsBoolean.withDefault(false));

like this: setIsMenuOpen(true)
2. In ComponentB I use a hook from next: useSearchParams
3. In ComponentB i use this code on button click / interval / useEffect etc.:

console.log(
  new URLSearchParams(Array.from(searchParams.entries())).toString()
)

The logged query doesn't change even though I see the change being applied by your library in the address bar.

Questions:

1. Am I doing something wrong?
2. Should I give you more info?
3. Is there a possibility to get all query data with your library that would equal this:

new URLSearchParams(Array.from(searchParams.entries())).toString(),

Thanks!

[franky47]

@damian-balas in stock¹ Next.js, useSearchParams is not reactive to shallow URL updates. Since the setters change the URL in a shallow manner by default (ie: without going through the Next.js router to avoid sending network requests), it is not picked up by useSearchParams.

Edit: if you want to be notified of URL updates, you can use the subscribeToQueryUpdates function:

import { subscribeToQueryUpdates } from 'next-usequerystate'

React.useLayoutEffect(
  () => subscribeToQueryUpdates(({ search }) => console.log(search.toString()),
  []
)

Footnotes

1. As of [email protected], the experimental windowHistorySupport flag changes this behaviour and makes useSearchParams reactive to shallow URL changes. However, doing so will still lag behind the state update, because of the internal throttling of URL updates. To get an update in the next render (like you would in useState), use a query getter: useMenuQueryState()[0]. ↩

[damian-balas]

@damian-balas in stock1 Next.js, useSearchParams is not reactive to shallow URL updates. Since the setters change the URL in a shallow manner by default (ie: without going through the Next.js router to avoid sending network requests), it is not picked up by useSearchParams.

Edit: if you want to be notified of URL updates, you can use the subscribeToQueryUpdates function:

import { subscribeToQueryUpdates } from 'next-usequerystate'

React.useLayoutEffect(
  () => subscribeToQueryUpdates(({ search }) => console.log(search.toString()),
  []
)

Footnotes

1. As of [email protected], the experimental windowHistorySupport flag changes this behaviour and makes useSearchParams reactive to shallow URL changes. However, doing so will still lag behind the state update, because of the internal throttling of URL updates. To get an update in the next render (like you would in useState), use a query getter: useMenuQueryState()[0]. ↩

Thanks :)
I've implemented "my own" version of useSearchParams as an substitute.
This is what I came up with:

const useSubscribedSearchParams = () => {
  const _searchParams = useSearchParams();
  const [searchParams, setSearchParams] =
    useState<URLSearchParams>(_searchParams);

  useLayoutEffect(
    () =>
      subscribeToQueryUpdates(({ search }) => {
        setSearchParams(search);
      }),
    // * This returns an unsubscribe function
    [],
  );

  return searchParams;
};

It works well :)

My last question is... how should I actually handle changing dynamic queries?

Example:

1. Get current search query
2. Add dynamic key that comes via props
3. Update the search query

How would you handle that case?

Help much appreciated! :)

[franky47]

I would use a useQueryState to update the URL, that's what it's intended to do. If the key is not known ahead of time, or there can be an arbitrary number of them, you can use useQueryStates to go around the rules of hooks:

function DynamicQuery({ keys }: { keys: string[] }) {
  const [values, update] = useQueryStates(
    // Note: might want to memoize this
    keys.reduce((obj, key) => ({
      ...obj,
      [key]: parseAsString
    }), {})
  )

[oliverstreissi]

I would use a useQueryState to update the URL, that's what it's intended to do. If the key is not known ahead of time, or there can be an arbitrary number of them, you can use useQueryStates to go around the rules of hooks:

function DynamicQuery({ keys }: { keys: string[] }) {
  const [values, update] = useQueryStates(
    // Note: might want to memoize this
    keys.reduce((obj, key) => ({
      ...obj,
      [key]: parseAsString
    }), {})
  )

Thanks for the example, but how can I type this properly, since values in this case is of type {} and using useQueryState<Record<string, string>>(...) gives me Property 'parse' is missing in type 'string' but required in type 'Parser<any>'

[franky47]

@oliverstreissi this should do it (note however that this is a bit of a hack):

import { Parser, parseAsString, useQueryStates } from 'nuqs'

const [values, update] = useQueryStates(
  // Note: might want to memoize this
  keys.reduce(
    (obj, key) => ({
      ...obj,
      [key]: parseAsString
    }),
    {} as Record<string, Parser<string>>
  )
)

If using default values, you'll need to be explicit about the default value existing on the reduce initial object:

const [values, update] = useQueryStates(
  // Note: might want to memoize this
  keys.reduce(
    (obj, key) => ({
      ...obj,
      [key]: parseAsString.withDefault('')
    }),
    {} as Record<string, Parser<string> & { defaultValue: string }>
  )
)

[tordans]

@damian-balas I am under the impression that this is solved so I will close it. I can reopen if needed, of course.