Populating multiple selects from comma delimited query params

Hey guys,

I’m on 1.4.0-beta.1+canary.189fdcbc. I’ve enabled the query-params feature and am using it to filter results from our API to display as markers on a Google map.

If I transition to a route with an array as one of the query params, the array is translated into a comma delimited string. I.e.

@transitionTo("route", queryParams: { foo: "bar", test: [1,2] }) # => http://domain.com/route?foo=bar&test=1%2C2
# as opposed to, say, /route?foo=bar&test[]=1&test[]=2

In order to make sure the comma delimited string is translated back into an array, I’m passing the queryParams into the controller as an Ember object:

  setupController: (controller, context, queryParams) ->
    queryParamsObject = Ember.Object.create(queryParams)
    controller.set("queryParamsObject", queryParamsObject)

Then, I’m observing this query params object, parsing the comma-delimited string and setting a selection attribute on the controller:

# Simplified for clarity...
setupArrays: (->
  Ember.run.once =>
    queryParamsObject = @get("queryParamsObject")
    test = queryParamsObject.get("test") # => "1,2"
    testSelection = test.split(",") # => [1,2]
    @set("testSelection", testSelection)
).observes("queryParamsObject")

This attribute populates the multiple select:

{{view Ember.Select selection=testSelection content=App.TestOptions multiple=true}}

On the flip side, I’m observing the selection attribute and updating the query params object when appropriate:

# Simplified for clarity...
updateTestQueryParam: (->
  Ember.run.once =>
    queryParamsObject = @get("queryParamsObject")
    newCommaDelimitedValue = @get("testSelection").join(",")
    queryParamsObject.set("test", newCommaDelimitedValue)
).observes("testSelection.@each")

I can then turn the query params object into a hash to pass to transitionTo. Whew.

So: this is all mostly working, but it feels like a TON of code. I’m wondering if there’s perhaps a more idiomatic way to do this without observers?

@machty I also know you’re actively working on improving the query-params implementation so let me know if this’ll be a moot point soon… I can handle some verbose code in the short term. :smile:

Hopefully it’ll be moot :smile:

It’s exactly this reason that we’re rethinking the API (which I’m working on right now)

:thumbsup: That’s all I needed to hear. Looking forward to the new API. Ping me if you need some code review.

Here’s the latest https://gist.github.com/machty/7923797

1 Like

Well, these changes would pretty much obliterate the hoops I’m currently jumping through. Not sure what the best course of action is on the link-to stuff. The “smart” version seems at odds with namespacing the parameters per controller (which is very :thumbsup:) , but we may have no choice if the charset is that restrictive. Transition flow feels right, but I’d definitely want to be able to configure replace vs. push state. I’m not even sure if replace should be the default but that kinda depends on what the default action handlers are and how things bubble/refresh by default.

Also, I saw you want to punt on promises for now. Are you thinking you could set a QP to a promise and update the querystring once it resolves? Or is there another use of promises + QP that I’m missing?