[router] support URL Query string

[bit-app-3000]

Hi !
thanks for the great tool !

not found support for URL query string

When used it redirects to location, truncating query parameters

[postspectacular]

Hi @bit-app-3000 — sorry for the delay, can you please still provide a small example to illustrate the issue? Thank you!

[bit-app-3000]

Hi @postspectacular
small example of use

/cars/bmw -> is Handled
/cars/bmw?sort=price -> redirect to /cars/bmw

expected route processing
with query strings and no redirect

import { EVENT_ROUTE_CHANGED, HTMLRouter } from '@thi.ng/router'
import { route } from 'state'

let routerInstance = null

const config = {
  useFragment: false,
  prefix: '/',
  default: 'home',
  trim: true,
  routes: [
    {
      id: 'home',
      match: []
    },
    {
      id: 'category',
      match: ['?category']
    },
    {
      id: 'category-item',
      match: ['?category', '?item']
    }
  ]
}

const change = ev => {

  const { id, params } = ev.value
  const queryParams = window.location.search

  route({ id, params, queryParams })

}

const init = () => {

  console.log('ROUTE:INIT')
  
  routerInstance = new HTMLRouter(config)
  routerInstance.addListener(EVENT_ROUTE_CHANGED, change)
  routerInstance.start()
}

export const router = { init }

[postspectacular]

Hi @bit-app-3000 — sorry for the delay. I've just released a new version of this package (i.e. v4.1.28) which should keep the existing query string when navigating to a new route... This should only have been an issue if you're not using the hash fragment for storing the route. Please let me know if that works for you. I've tested it with router-basics example and it seems to be all in order...

[bit-app-3000]

works correctly!

@thi.ng ecosystem is powerful

thank you.

[postspectacular]

Hah! Thank you! Again, sorry it took so long... good thi.ngs come to those who wait! 😅

[bit-app-3000]

good day I see cases that it does not process normally with SearchParams

paths: /page?k=v

it simply does not find a valid path in the matching

matchRoutes(src, ctx) {
...
const curr = src.split(this.opts.separator);
const route = this.routes.get(curr);
}

maybe it's time to add the use of
searchParam as a first class citizen

[postspectacular]

After re-inspecting the RFC for URL syntax, putting search params AFTER the hash fragment is actually NOT a valid query string at all, and technically part of the hash fragment itself. The correct order (also the way the browser & JS interprets an URL) always is: path → search → hash

Also see the difference here:

let a = new URL("http://localhost:5173/?foo=1#/home");
a.search
// "?foo=1"
a.hash
// "#/home"

let b = new URL("http://localhost:5173/#/home?foo=1");
b.search
// ""
b.hash
// "#/home?foo=1"

As you can see b produces wrong results and the problems with the router only arise because of this wrong order. I've just pushed a new update to ensure the correct order of URL parts is used when switching routes, depending on setting of useFragment, but it's still your responsibility to ensure the correct order of querystring -> hash elsewhere in your app.

The new version is 4.1.47:
https://github.com/thi-ng/umbrella/blob/develop/packages/router/CHANGELOG.md#4147-2025-11-08

Hope that really fixes it now! :)