api: FromConn for serde_json::Value and querystrong::QueryStrong

[jbr]

No description provided.

[codecov]

Codecov Report

Merging #359 (8884f1f) into main (b98e4ca) will decrease coverage by 0.05%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #359      +/-   ##
==========================================
- Coverage   45.25%   45.20%   -0.05%     
==========================================
  Files         156      156              
  Lines        6057     6063       +6     
==========================================
  Hits         2741     2741              
- Misses       3316     3322       +6     

Files Changed	Coverage Δ
api/src/from_conn.rs	15.38% <0.00%> (-9.62%)	⬇️

... and 1 file with indirect coverage changes

[joshtriplett]

I just encountered a case where it would have been nice to have support for QueryStrong.

[jbr]

I just encountered a case where it would have been nice to have support for QueryStrong.

The reason I haven't moved more decisively on this is until there can be a const generic str, the FromConn will really just be QueryStrong::from_str(conn.querystring()).unwrap_or_default() which isn't a lot of saved characters for adding a dependency. When/if const str is a thing, we could have:

fn api_handler(conn: &mut Conn, query: Query<Path = "name[first]">) {…}

or whatever that syntax eventually looks like, where Path is the string representation of a querystrong::Indexer

Convince me it's worth the dependency and cargo feature to make QueryStrong::from_str(conn.querystring()).unwrap_or_default() easier? I've also made similar initial steps towards adding this to trillium itself, but some people may prefer to use serde_qs or serde_querystring. Should trillium itself have a querystrong feature? Or just trillium-api? If either, should the feature be enabled by default?

[joshtriplett]

@jbr I don't think it's worth the slight brevity in getting the entire query string. However, I think it'd be worth it if you could write something like Query<SomeStruct> to deserialize a struct from the query string.

Separate from that, I'd also love to have simple support for cases like xyz?value=:value that feels more-or-less integrated with routing, making it possible to extract :value in the same manner as path components. Ideally, that'd work in any order, and provide a way to declare them optional or required. (Much like current routing, trillium-api can't currently extract those parameters by name because of the lack of const generic strings, but I built a local mechanism to extract parameters whose name is a number, using const generic numbers. :) )