AppendUrlQueryPairs & QueryPairsExtension traits

[oguzkocer]

This PR implements a more structured way to generate the url query for our Params types. This helps avoid duplicating the same logic for these types and makes it less error prone. It's both easier to work with and easier to read.

For the AppendUrlQueryPairs implementation, I've opted for the fn append_query_pairs(&self, query_pairs_mut: &mut QueryPairs) {} function signature. In general, I'd prefer us to return data as oppose to mutating given data. However, in this case, that meant that we had to clone some of the fields. That's probably OK for the gained ergonomics, but I don't feel comfortable with just probably. There is also no practical downside in this case and it sort of works like a unit function because we start with a completely empty query. Another option could be to return a form_urlencoded::Serializer type, then turn that into &str and pass it into url::Url::set_query, but we would still pay an extra cost.

It's also possible I might have missed an approach that can return an IntoIterator, but I don't think it's worth spending too much time on it when we have an acceptable implementation.

[crazytonyli]

Is it possible to implement a #[derive(AsQueryValue)] to do the same? This is not a request for changes though.

[oguzkocer]

It's, but the implementation would be more complicated because if we are going to have a single derive such as AsQueryValue, then we'd need to have options for it, such as from=as_str, from=to_string etc. Handling that is more complicated, so it add maintenance burden. We could add different derives such as AsQueryValueFromAsStr, AsQueryValueFromToString, but that's not any better unfortunately.

We are trying to implement derive macros when there is significant benefit to them compared to other solutions. This is not such a case, because the simple macro_rules! does a good job and it is easier to understand.

Fwiw, for a personal project I'd probably go with the derive macro as I am used to working with them. However, I don't think it's the right choice for this project - at least not at this time.

[crazytonyli]

Thanks for the explanation!