Vue-router: Array in query is not correct while pushed

[KingMario]

Vue.js / vue-router versions

2.3

Reproduction Link

https://jsfiddle.net/KingMario/gnk3a044/

Steps to reproduce

Click the "Push Url" button, then click any link.

What is Expected?

The url should be https://fiddle.jshell.net/KingMario/gnk3a044/show/#/foo?x[]=1&x[]=2

What is actually happening?

Get https://fiddle.jshell.net/KingMario/gnk3a044/show/#/foo?x=1&x=2

[any86]

同问

[posva]

This is actually an expected behaviour. You can actually get the array back with $route.query.x

[any86]

expected: $route.query.x = [1] ,but: $route.query.x = 1 ，this is the key @posva

[posva]

no, you actually have [1]: https://jsfiddle.net/posva/gnk3a044/1/

[any86]

step:

1. url: /list

1. js: router.push({query: {a:[1]}}) // url: /list?a=1

2. refresh chrome

3. js: console.log(route.query.a) // 1, expected: [1]

On address bar not didn't do the difference between new Array(1) and string

@posva

[posva]

That's the downside of the used syntax vs the [] way. There's no way to tell if that's a single argument or a list just from the url. I don't think having both is a good idea because you could expect to override when using the same parameter in query multiple times: ?x=1&x=2 -> x == 2 if you have a specific array syntax. I believe that we should use the [] syntax in the future because it explicitly tells a query is an array but introducing it now will mean a breaking change

[KingMario]

For front-end routing, the setting and getting of query are all under control. So JSON.stringify(x) could be used if needed while pushing with an array in the query.

Another approach is that add a watcher for the array in query:

'$route.query.x': {
  handler(val) {
    this.$route.query.x = Array.isArray(val) ? val : [val]
  },
  immediate: true
}

So, in my opinion, [] syntax is not urgently in need of.

Since for vue-router 1, [] syntax is used, the _JSON.stringify_ approach should be written in the guide of Migration from Vue Router 0.7.x.

[dobromir-hristov]

Soo if I want to access the parameter from php, for example after a page refresh, it will not act as an array of items?
Edit: Yeah, it just overrides all with the last parameter.

[dobromir-hristov]

OK so workaround I thought of is to send a comma separated list of values and explode that on the server. To still be able to use the value with v-model and a checkbox for example I did a computed property with a setter and getter as follows:

// Use this because Array.split() on empty string returns [''] which is not what we need atm.
function split (string, sep) {
  const a = string.split(sep)
  if (a[0] === '' && a.length === 1) return []
  return a
}
// the computed prop
arrayItem: {
      get () {
        return split(this.query.arrayItem, ',')
      },
      set (value) {
        this.query.arrayItem = value.toString() // Convert the Array to comma sep. string
      }
    }

Now we can just use arrayItem with v-model in our templates.

[posva]

In the future, we will provide a way of overwriting the query parser with a custom one like qs

[ispal]

In the future, we will provide a way of overwriting the query parser with a custom one like qs

That's actually what I would need currently because of my custom query string needs so that would be great if we get to use qs parser! I have to create a workaround for now.

[thatandyrose]

@posva hey there! Just a question... I've come up with this issue too.

Just wondering... couldn't find it anywhere....why have you guys taken this approach vs the &something[]=n& approach?

[thatandyrose]

@posva ah, I think you answered here:

I believe that we should use the [] syntax in the future because it explicitly tells a query is an array but introducing it now will mean a breaking change

gotcha. Why was that not the initial approach? I'm just curious.

In the migration docs it seems you guys moved away from the val[] approach for v2, is that right or have I misread the situation?

[posva]

it's just a valid choice. You can use a different syntax by plugging in qs
(check queryParser at https://router.vuejs.org/en/api/options.html )

On Mon, Nov 6, 2017 at 11:51 AM Andy [e-mail] wrote:

@posva https://github.com/posva hey there! Just a question... I've come
up with this issue too.

Just wondering... couldn't find it anywhere....why have you guys taken
this approach vs the &something[]=n& approach?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vuejs/vue-router/issues/1232#issuecomment-342113455,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAoicTmuyvKghqRCZsqPQbn2_K8xyplQks5szuS9gaJpZM4MWj18
.

>

Eduardo San Martin Morote

[thatandyrose]

Great! Didn't know about the hook, that's perfect, cheers!

On Mon, 6 Nov 2017 at 10:58 Eduardo San Martin Morote <
[email protected]> wrote:

it's just a valid choice. You can use a different syntax by plugging in qs
(check queryParser at https://router.vuejs.org/en/api/options.html )

On Mon, Nov 6, 2017 at 11:51 AM Andy [e-mail] wrote:

@posva https://github.com/posva hey there! Just a question... I've
come
up with this issue too.

Just wondering... couldn't find it anywhere....why have you guys taken
this approach vs the &something[]=n& approach?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/vuejs/vue-router/issues/1232#issuecomment-342113455
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAoicTmuyvKghqRCZsqPQbn2_K8xyplQks5szuS9gaJpZM4MWj18

.

>

Eduardo San Martin Morote

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/vuejs/vue-router/issues/1232#issuecomment-342115166,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAvfWjs_9MY-qiL_vkvIyEqaWLOMEiTOks5szuZVgaJpZM4MWj18
.