Skip to content

Not able to update query parameter from navigation guard #2624

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nirmalraghavan opened this issue Feb 22, 2019 · 6 comments
Open

Not able to update query parameter from navigation guard #2624

nirmalraghavan opened this issue Feb 22, 2019 · 6 comments
Labels
bug fixed on 4.x This issue has been already fixed on the v4 but exists in v3 has workaround

Comments

@nirmalraghavan
Copy link

nirmalraghavan commented Feb 22, 2019

Version

3.0.2

Reproduction link

jsfiddle.net/bqaxhgkc

Steps to reproduce

Inside beforeEnter try to modify query parameters by passing next({ query: {'my-param': 'new-value'} })

What is expected?

Query parameter will be updated with the new value and the URL will also update.

What is actually happening?

URL still having the same old value for my-param.


Even though the query parameter value is not updated in the URL, this.$route.query['my-param'] value is updated with the new value.

@posva
Copy link
Member

posva commented Jul 4, 2019

I'm realizing that calling next like the fiddle should create an infinite redirect, the same as doing

next({ name: 'foo', query: {'my-param': 5} })

which does create an infinite redirect. So I think this is technically a bug and I don't know why I didn't comment the workaround back then, but you can do this:

beforeEnter: (to, from, next) => {
  // avoid an infinite redirection
  if (String(to.query['my-param']) === '5') return next()
  // make sure to include `name`
  next({ name: 'foo', query: {'my-param': 5} })
    }

Edit: proper version: https://jsfiddle.net/bqaxhgkc/
bug: clicking a second time the link should not change the location

@JohnBernardsson
Copy link

Hello, I am trying to do something similar... but not quite. Basically I have a situation where I do have query parameters not tied to any route in particular, but that I would like to carry over through routes if they are present.

I am trying this, but is not working:

router.beforeEach((to, from, next) => {
			
	const query = { ...to.query, ...configurationService.getURLCarryOverParams()};

	// Replace the query params adding the non-route related query params that
	// we want to carry over from page to page
	next({
		query: query
	});
});

There is any workaround for this situation? I also tried to assign the "query" of the "to" route but it is read only.

@posva
Copy link
Member

posva commented May 18, 2020

@JohnBernardsson I would override the router's push method to implicitly pass the previous query so you don't have to write this everywhere:

router.push({ name: 'thing', query: { ...$route.query }})

@JohnBernardsson
Copy link

@posva you mean overriding the library push method itself? Interesting... ok, I'll give it a go, see how that works.

Thanks!

@JohnBernardsson
Copy link

JohnBernardsson commented Jun 30, 2020

Just in case someone reaches this, and have the same problem (or something similar), I easily solved overriding the push method as @posva mentioned.

Code uses ES6 classes:

import VueRouter from 'vue-router';

/**
 * @class
 * Extends Vue Router, to add specific push logic
 */
class CustomVueRouter extends VueRouter {
	
	/**
	 * Overrides the Vue Router push method, to allow carrying over to all our pages
	 * some queryparams, if they were present in first load
	 * @param {RawLocation} location 
	 * @param {Function} [onComplete] 
	 * @param {ErrorHandler} [onAbort] 
	 */
	push(location, onComplete, onAbort) {

		const 
		staticQueryParams = {
			// Logic to get the params to carry over
		},
		newLocation = {...location, 
			query: {
				...(location.query || {}), ...staticQueryParams
			}
		};

		// Calls the VueRouter push method
		super.push(newLocation, onComplete, onAbort);
	}
}

@posva posva added the fixed on 4.x This issue has been already fixed on the v4 but exists in v3 label Mar 11, 2021
@Drumsin

This comment was marked as spam.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug fixed on 4.x This issue has been already fixed on the v4 but exists in v3 has workaround
Projects
None yet
Development

No branches or pull requests

4 participants