Upgrade from 2.1.2 to 3.0.0, the Luxon object stopped working properly as the defaultValue

[Jahoda]

Describe the bug

This code was working normally in the previous version:

import { DateTime } from 'luxon'

const to = queryParam(
  'to',
  {
    decode: (value) => DateTime.fromISO(value),
    encode: (value) => value.toISO(),
    defaultValue: DateTime.now(),
  },
  { showDefaults: false },
)

In version 3.0.0, the Luxon object has somehow been transformed, causing basic methods to become unavailable. For example, $to.startOf('month') no longer works.

I'm afraid that this is a side effect of the recent changes.

#89
#87

Is there a workaround, or should I use it in a different way?

Thank you!

Reproduction

See the result in the console:

3.0.0 (error): https://stackblitz.com/edit/sveltejs-kit-template-default-nu1tgv?file=src%2Froutes%2F%2Bpage.svelte
2.1.2 (working): https://stackblitz.com/edit/sveltejs-kit-template-default-uy9ugg?file=src%2Froutes%2F%2Bpage.svelte

Logs

No response

[paoloricciuti]

Uhm, i see what the problem is...in #89 i had to structuredClone the value of the store because otherwise whenever you would've write to a property it would've overwrote the original default value creating a bug. But structured clone doesn't properly work on classes (which i guess luxon is using) so every method on the prototype get's removed.

This is a tricky one to solve.

[paoloricciuti]

I'm thinking if adding an immutable option could be the solution...in that case it would avoid structuredClone-ing at the cost of not being able to assign to properties of the object and see the property reflect in the URL....but i would need to check the feasibility.

Also i'm kinda planning a rewrite for svelte 5 and runes so i queryParam would be discontinued and immutable doesn't really make sense for queryParameters so very very tricky indeed.

[Jahoda]

Thanks for the response. It's alright, I can manage with version 2.1.2 for now, but it would be great to consider this behavior in future versions. It's extremely convenient to have the luxon DateTime directly there.

[paoloricciuti]

Thanks for the response. It's alright, I can manage with version 2.1.2 for now, but it would be great to consider this behavior in future versions. It's extremely convenient to have the luxon DateTime directly there.

Yeah i think having the param decoded to a class should be supported...i just don't know how to do it 😄

[Jahoda]

@paoloricciuti Hi, do you have any new information for me, please? I’m still using version 2 with Svelte 5, and it’s starting to be problematic :-)

[paoloricciuti]

As i've said i the version i removed queryParam and immutable doesn't really make sense with queryParameters...did you try with the new version?

[Jahoda]

Unfortunately, I’m very unhappy with v4—or perhaps I just don’t fully understand it.

The queryParam function was much more useful than queryParameters for my use cases. It was perfectly elegant to have simple, reusable stores like this:

export const limit = queryParam('limit', ssp.number(25), { showDefaults: false })

I could import it wherever I wanted and easily update it via limit.set(). It also allowed me to keep the URL parameter name independent from the variable name. This setup let me do neat things, like:

const visible = queryParam('changeLanguage', ssp.boolean(null))

<Modal visible={$visible}>

Or create functions for namespaced parameters in data grids:

import { queryParam, ssp } from 'sveltekit-search-params'

export function getLimitQueryParamKey(namespace: string = '') {
  return namespace ? `${namespace}:limit` : 'limit'
}

export function createLimit(namespace: string = '') {
  return queryParam(getLimitQueryParamKey(namespace), ssp.number(25), {
    showDefaults: false,
  })
}

And then simply use it like: const limit = createLimit(namespace).

However, after starting to migrate to v4, I found that the code has become significantly less readable and more difficult to use. I have about 60 usages of queryParam in my project, and I’d really like to preserve the elegance of version 2 so I don’t have to spend a lot of time rewriting everything.

Is there a way to use the new version so it better fits my use case?

Thank you!

[Jahoda]

@paoloricciuti

Last but not least, I am also missing the feature to bulk update parameters. For example, I want to click “Apply filters” and change multiple query parameters at once.

In V2, it was simply filterParams.set(params). Is there an equivalent for this in V4, please?

[paoloricciuti]

I could import it wherever I wanted and easily update it via limit.set(). It also allowed me to keep the URL parameter name independent from the variable name. This setup let me do neat things, like:

Uhm this is actually something i didn't think of...i guess i could add an option to specify the name of the parameter different from the key so you could do something like

const params = queryParameters({
    visible: {
        name: "changeLanguage",
    }
});

for example.

Last but not least, I am also missing the feature to bulk update parameters. For example, I want to click “Apply filters” and change multiple query parameters at once.

This shouldn't be a problem at all...you can just do

params.valid = true;
params.name = "John";

and the url will change once