Add query string params to the end of URI

[gansbrest]

I have ecommerce store with bunch of facets ( filters ). It's important for me to preserve the order in which user clicks facets.

If user clicks Brand -> Size -> Brand, it should be brandId=1&sizeId=234&brandId=34.

It seems like URI.js is grouping query string attributes, so I get brandId=1&brandId=34&sizeId=234, so I'm loosing correct clicks order.

Here is how to reproduce problem in code:

var uri = new URI("http://192.168.1.10:3000/search?company=1&height=182").addQuery("company", 9);

gives me

http://192.168.1.10:3000/search?company=1&company=9&height=182

( on click I was hoping to execute addQuery to append new query string to the end ).

Is there a way to remove attributes grouping with URI.js and always add to the end?

[rodneyrehm]

currently there is no way to make that happen - it's parseQuery() that groups the values. I'm afraid I cannot provide a quick fix to that problem at the moment.

[barneycarroll]

Personally, I always try to modify URIs using intermediate objects. Of course it would be more memory efficient and certainly terser to be able to perform the task using a single chained expression, but I find it much easier to have intermediate steps like this so I can mentally separate setup, interaction and outputs in functions – it's also a lifesaver when debugging because you can step through operations one by one and isolate exactly where unexpected behaviour occurs. Here's how I would approach the problem:

// Given that current URL is http://192.168.1.10:3000/search?company=1&height=182
var currentUri  = new URI( location );
// Keep two URIs for the sake of comparison
var newUri      = new URI( currentUri );
// Get the query as an object for less ambiguous manipulation
var queryObject = currentUri.query( true );

// Replace the 'company' entry
queryObject[ 'company' ] = '9';

// Assign the modified query object to the new URI
newUri.query( queryObject );

// Assign the modified URI to the document location
location = newUri;

[rodneyrehm]

you might be interested in .clone() and .query(callback) (although I don't see why you'd need to clone the URI). Your example can be done much simpler:

// Given that current URL is http://192.168.1.10:3000/search?company=1&height=182
window.location = URI(window.location).query(function(data) {
  data.company = 9;
});

(I like to access globals via window to make absolutely clear what is going on…)

[gansbrest]

Well, in that case you will override initial company attribute and will get this:

http://192.168.1.10:3000/search?company=9&height=182

where I need this:

http://192.168.1.10:3000/search?company=1&height=182&company=9

[barneycarroll]

Completely misunderstood your original query, @gansbrest – that's what I thought you wanted. So all you actually care about is the position of the attribute. Why do you need the second company param to come after height? What bad behaviour is this producing that you're trying to avoid? There may be other ways around this…

[gansbrest]

We use query string to visualize user path through ecommerce facets and filters (as described in the original question), so if user chooses Compay ( A ), then Height ( 182 ), then second selection of Company (B), url should be company=a&height=182&company=b and based on that I can render ecommerce nav so user can visually see which filters were applied and undo them if required.

[rodneyrehm]

I'm not sure if this still is (or ever was) a thing, but I vaguely remember proxy servers (and the like) re-ordering query string content. That's why when I did something like the path you're describing, I had a dedicated property history, that would contain the trail. When it got more complex, I switched to JSON.

I'm not sure how much work this change would be, but I have the same desire as gansbrest for essentially the same use case.

[rodneyrehm]

This would require a rewrite of how query strings are handled. This is a use case URI.js does not cover for the time being. I'm sorry. We will have a look at this for version 2.0 - whenever that'll be.