Open kevinresol opened 7 years ago
Yeah, this one bit me already. Workaround: define a Client
that will split each entry in the query string by .
and wrap all but the first part in brackets. But yeah, we should properly support this ^^
We also need to support Map/DynamicAccess here.
If I am into it, where should I start with?
I am choosing between a compile-time solution or a runtime solution:
tink.QueryString.build(obj, {fieldAccess: 'bracket'})
where the 2nd param is a config which is a compile-time expression and the macro will build the writer/reader accordingly.tink.QueryString.build(obj, codec)
where codec is an instance of an runtime interface. Pros: less macro, more flexible. Cons: dynamic dispatch maybe slower@back2dos any suggestions?
Mhh, I think the performance difference will probably be negligible.
But in the context of tink_web you can't really access the query string builder or parser. So I would assume that typedefs would be annotated to recursively use one style or another, no?
Yeah, on the other hand I actually want to introduce something more flexible to tink_web in contrast to the current hardcoded approach on the reader/writers. A really rough illustration:
@:put
@:queryBuilder((obj:QueryObj) -> tink.QueryString.build(obj))
@:queryParser((query:tink.url.Query) -> tink.QueryString.parse(query))
@:bodyBuilder('application/json' => (obj:BodyObj) -> tink.Json.stringify(obj))
@:bodyParser('application/json' => (body:Chunk) -> tink.Json.parse(obj))
function foo(query:QueryObj, body:BodyObj):Noise;
I like that idea.
OTOH, let's not lose sight of the use case that prompted this: picking a specific object syntax flavor. When that's all you want, this level of configuration induces quite a bit of noise. Basically, these two accomplish the same:
@:queryFormat({ fieldAccess: 'bracket' }) typedef QueryObj) = ...
@:queryBuilder((obj:QueryObj) -> tink.QueryString.build(obj, { fieldAccess: 'bracket' })) @:queryParser((query:tink.url.Query) -> tink.QueryString.parse(query, { fieldAccess: 'bracket' }))
The former also allows to consistently apply the same flavor for something like a set of search params available across a whole API or to use the information in something like a macro based form builder.
In any case, the two approaches are in no way mutually exclusive. The former (type based) can definitely be implemented via the latter (adhoc config based).
I am working with some API that expects key value pair to be expressed by brackets:
i.e.
{obj:{key:'value'}}
would beobj[key]=value
Should there be an option for that?