Order Insensitive Way To Process Query Parameters

[mergesort]

I'm currently implementing a router where people will be able to use x-callback-url to communicate with my app.

The code I have looks approximately like this, where if a user provides the x-source, x-success, x-cancel, and x-error parameters a user will be prompted to share their ID with the app which calls into this deeplink.

static let router = OneOf {
    Route(.case(AppRoute.XCallbackRoute.lookupPlinkyID)) {
        Path { "actions"; "lookup" }

        Query {
            Field("value") { "id" }
            Field("x-source", default: String.Routing.null) { Parse(.string) }
            Field("x-success", default: String.Routing.null) { Parse(.string) }
            Field("x-cancel", default: String.Routing.null) { Parse(.string) }
            Field("x-error", default: String.Routing.null) { Parse(.string) }
        }
    }
}

Those parameters will be matched into this case, providing all of the parameters as a string. (Side question: Is there a parser that directly validates a String to put it into a URL?)

case lookupID(source: String, success: String, cancel: String, error: String)

I noticed that if I change the order of the parameters either in the router or the URL itself, such as by putting x-error first, then x-error will be parsed into lookupIDs source parameter. This is a bit unexpected, generally URLs don't their query parameters to be in order, so I figure I must be missing something.

Would love to know if there's a way to accomplish this, and thank you so much for all of the help so far!

[mbrandonw]

Hi @mergesort, it's not that the query params in your URL are ordered, it's that your lookupID case is ordered:

case lookupID(source: String, success: String, cancel: String, error: String)

This is a static Swift symbol and it forces you to parse x-source first from the query, then x-success, etc. There is no way to statically tie the argument name source to the string "x-source" so that you could order your Field parsers however you want.

However, the order of the query params in the URL does not matter. Under the hood we just use URLComponents to parse that information and put it into an array. Are you 100% certain that the order of the URL query params was significant? If so, can you come up with a reproducible example that demonstrates that behavior?

[mergesort]

Hey @mbrandonw, this appears to have been my own misunderstanding of how the Shortcuts app assembles parameters in it's X-Callback-result.

Normally when you use it the order is x-source x-success, x-error, x-cancel, but when you use the "custom callback" option the order of the query parameters is x-source x-success, x-cancel, x-error, and so I was getting a cancel where I expected an error (and vice versa). As a result I misunderstood how the value was being parsed, not an issue with your library.

Thanks for the gut check, and good to know this information going forward!