first-reduction

[pateketrueke]

It would be interesting see the % of reduction of this change. 🤔

[frederikhors]

Very small, but why not?

[pateketrueke]

I would like it works as follows:

import { Router } from 'yrv';
import queryString from 'query-string';
Router.qs = queryString;

By default we should export a mock for qs that simply does nothing on parse() and stringify() to keep the rest of code without changes.

I think we could reduce more if we drop query-string from the built-ins as you said. 👍

[frederikhors]

By default we should export a mock for qs that simply does nothing on parse() and stringify() to keep the rest of code without changes.

I do not agree.

Just remove it like svelte-spa-router does: https://github.com/ItalyPaleAle/svelte-spa-router#querystring-parameters:

Querystring parameters

You can also extract "querystring" parameters from the hash of the page. This isn't the real querystring, as it's located after the # character in the URL, but it can be used in a similar way. For example: #/books?show=authors,titles&order=1.

When svelte-spa-router finds a "querystring" in the hash, it separates that from the location and returns it as a string in the Svelte store $querystring. For example:

The current page is: {$location}

The querystring is: {$querystring}

With the example above, this would print:

The current page is: /books The querystring is: show=authors,titles&order=1 It's important to note that, to keep this component lightweight, svelte-spa-router does not parse the "querystring". If you want to parse the value of $querystring, you can use third-party modules such as qs in your application.

[pateketrueke]

If we remove it, how deal with the current tests that are using it without having to parse/stringify back? 🤔

I mean, lets say we remove query-string — the only change I want to do on our tests is adding the code from above, to register the qs module only.

[frederikhors]

You can merge this one because it's safe.

After we can decide what to do with query-string.